Hello Hongwei, Andrew
I confirm that you can close this case.
For the story we were missing this attributes:
Attribute lockoutduration not present in replication metadata
Attribute lockoutobservationwindow not present in replication metadata
Attribute lockoutthreshold not present in replication metadata
Attribute minpwdlength not present in replication metadata
Attribute modifiedcountatlastprom not present in replication metadata
Attribute pwdproperties not present in replication metadata
Attribute pwdhistorylength not present in replication metadata
Attribute objectsid not present in replication metadata
Attribute uascompat not present in replication metadata
Attribute iscriticalsystemobject not present in replication metadata
Attribute maxpwdage not present in replication metadata
In the DC=domain, DC=tld object, so they weren't transfered to windows,
we can quite easily understand why it had some problem to start.
Of course it would have been better if Windows server would have refused
this object (maybe an idea of improvement for the upcoming Windows
server ?).
Thanks for your support.
Matthieu.
On 06/07/2011 20:30, Matthieu Patou wrote:
Hi Hongwei,
So we had a couple of issues that I'm sure had an impact:
* schemaguid on some attribute were duplicated
* ntmixed was not coherent among the different NC and not coherent
with the MsDS-Beahvior-version
* replicated metadata for the root NC was incomplete
All of this have its roots in using a quite old provision of Samba4.
The first 2 points were quite easy to identify (the first one resulted
as an error in the event log, the second one was spotted by an
analysis of differences in attributes). The third one has been more
complicated has I had to find which partition was causing the problem,
and then narrow the search.
I was suspecting a problem in the metadata but as most objects (all
but one ?) have a correct metadata it took me tries to transplant
objects and metadata from the problematic partition to a known OK.
I have a couple of more tests to do but I'm now confident that this
issue could be closed soon.
Thanks.
Matthieu.
On 30/06/2011 20:31, Hongwei Sun wrote:
Matthieu,
When the process being trace exits , the trace file will be
saved. So in your case, when you see the error message and you fail
to login, do a reboot so the lsass process will exit during reboot.
Once rebooted, you can then get the trace file generated from the
machine.
Hongwei
-----Original Message-----
From: Matthieu Patou [mailto:[email protected]]
Sent: Thursday, June 30, 2011 11:13 AM
To: Hongwei Sun
Cc: [email protected]; [email protected]; tridge
Subject: Re: [REG:111063044753520] [cifs-protocol] Unable to dcpromo
windows with a Samba4 DC
Hi Hongwei,
Moving dochelp to bcc
Hi, Matthieu,
The following is the instruction:
1. Run "TTTracer -persistent lsass.exe".
This will trace lsass.exe each time it starts until you
run "TTTracer -delete lsass.exe".
2. Reboot machine, lsass trace will start automatically.
3. Run "TTTracer -stop all" to stop all tracing on my
system. Trace files are written to the disk.
Will tttracer put trace on disk on reboot in anycase ? because the
issue is that the windows server can't really boot in normal mode. On
2003 I've got a popup saying that the lsass.exe had a problem but
then no more information and also I'm unable to log in.
Matthieu.
--
Matthieu Patou
Samba Team http://samba.org
Private repo http://git.samba.org/?p=mat/samba.git;a=summary
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
