So I've been toying around with this for a while now.
Here's what I've discovered:
Remember I'm on a sogo box that has joined a microsoft domain as another
domain controller.
I had to seize the schema role to get openchange to provision so it's
now the schema server.
I have samba using its internal dns server and really wish that the
samba developers would allow you to completely use external dns instead
of it having to be samba or bind on the same box.
I can create a brand new user activate them with the samba-tool commands
and then use openchange to create and extend them and mapiprofile works
perfectly fine.
Any existing domain user will fail and give the MAPI_E_NOT_FOUND
(0x8004010F) then delete the profile without completing it.
What exactly could be blocking existing user permissions from a kerberos
call or rpc call and not add a profile to the mapiprofile database?
Steve
On 10/30/2013 5:02 AM, Julien Kerihuel wrote:
Hi Steve,
On Fri, 2013-10-25 at 10:32 -0500, Steve Boley wrote:
So my question is during openchange deprovision is it going and set
the disable flags on the schema objects and if it somehow gets in a
midway success midway failure state does the scripting have the logic
to go ahead and fix the errors when run again or does it find the
first failure and exit out of the run? Then it seems to just leave it
all in a horrible state and you can't provision or deprovision either
one. Since it's a real active directory I can't just start over
because once it's extended it's there till the cows come home.
OpenChange deprovision has been initially thought when deploying Samba
as a primary domain controller. It means that the deprovision will not
disable anything but purely remove the OpenChange schema.
So in the meantime can you provide the manual steps or scripts to
reprovision openchange?
http://www.openchange.org/cookbook/configuring.html#configure-openchange
Be nice to have some docs on how to manually clean and remove
openchange both database and schema.
Indeed, there is a path to improvement here.
Br,
Julien.
_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel
