Location: List Archives

List Archives

This forum is an archive of all posts to our mailing list over the past few years.  The forum is set read only therefore to contribute you will need to join our list community.  See more info about this here.

List Archives

Subject: [ActiveDir] FFL Upgrade Problem
Prev Next
You are not authorized to post a reply.

AuthorMessages
dkkazakUser is Offline

Posts:8

07/18/2008 8:36 AM  
I have run into a curious situation and am wondering if anyone else has seen
this or has any suggestions for resolving this. We are a large
multi-national organization that designed our AD structure back in the
Windows 2000 days. Because of that, we have 20+ domains with an empty root.
We are trying to raise our Forest Functional Level to Windows 2003. In
doing so, we found a problem with two child domains.



When attempting to upgrade the forest, we have found two child domains are
being reported as Windows 2000 Mixed mode (even though they were never 2000
Mixed). In investigating this further using adsiedit, I have found that the
domain partition has the correct properties for both msDS-Behavior-Version
(2) and ntMixedDomain (0). When I look at the configuration partition
cn=partitions for these domains, it is showing <not set> for both of these
properties. I have tried to manually update these values with the correct
values, but it gives me the following error message:

Illegal modify operation. Some aspect of the modification is not permitted.



It would appear that when these two domains were upgraded to a domain
functional level of 2003, that the crossref was not also updated. I have
tried modifying the values on the domain partition, as well, with the same
error message.



Does anyone have suggestions on how to force the crossref to happen or
otherwise update those values?



Thanks,

Doug




dwellsUser is Offline

Posts:39

07/18/2008 8:40 AM  
Where are you reading the crossRef from (which DC)? Trying changing focus
and see if the results differ across instances of the config. NC.

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Friday, July 11, 2008 3:21 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FFL Upgrade Problem



I have run into a curious situation and am wondering if anyone else has seen
this or has any suggestions for resolving this. We are a large
multi-national organization that designed our AD structure back in the
Windows 2000 days. Because of that, we have 20+ domains with an empty root.
We are trying to raise our Forest Functional Level to Windows 2003. In
doing so, we found a problem with two child domains.



When attempting to upgrade the forest, we have found two child domains are
being reported as Windows 2000 Mixed mode (even though they were never 2000
Mixed). In investigating this further using adsiedit, I have found that the
domain partition has the correct properties for both msDS-Behavior-Version
(2) and ntMixedDomain (0). When I look at the configuration partition
cn=partitions for these domains, it is showing <not set> for both of these
properties. I have tried to manually update these values with the correct
values, but it gives me the following error message:

Illegal modify operation. Some aspect of the modification is not permitted.



It would appear that when these two domains were upgraded to a domain
functional level of 2003, that the crossref was not also updated. I have
tried modifying the values on the domain partition, as well, with the same
error message.



Does anyone have suggestions on how to force the crossref to happen or
otherwise update those values?



Thanks,

Doug




matheeshaUser is Offline

Posts:14

07/18/2008 8:52 AM  
do you have any objects in the lost and found container of the config partition?

2008/7/12 Doug Neely <dkactivedir@kazakinfo.com>:
> I have checked all of the DCs in both domains and all of them show the
> inconsistencies between the domain partition and configuration partition.
>
>
>
> Anything else I should check?
>
>
>
> Thanks,
> Doug
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
> Sent: Friday, July 11, 2008 3:24 PM
>
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FFL Upgrade Problem
>
>
>
> Where are you reading the crossRef from (which DC)? Trying changing focus
> and see if the results differ across instances of the config. NC.
>
> --
> Dean Wells
> * Email: limeypride@gmail.com
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
> Sent: Friday, July 11, 2008 3:21 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] FFL Upgrade Problem
>
>
>
> I have run into a curious situation and am wondering if anyone else has seen
> this or has any suggestions for resolving this. We are a large
> multi-national organization that designed our AD structure back in the
> Windows 2000 days. Because of that, we have 20+ domains with an empty
> root. We are trying to raise our Forest Functional Level to Windows 2003.
> In doing so, we found a problem with two child domains.
>
>
>
> When attempting to upgrade the forest, we have found two child domains are
> being reported as Windows 2000 Mixed mode (even though they were never 2000
> Mixed). In investigating this further using adsiedit, I have found that the
> domain partition has the correct properties for both msDS-Behavior-Version
> (2) and ntMixedDomain (0). When I look at the configuration partition
> cn=partitions for these domains, it is showing <not set> for both of these
> properties. I have tried to manually update these values with the correct
> values, but it gives me the following error message:
>
> Illegal modify operation. Some aspect of the modification is not permitted.
>
>
>
> It would appear that when these two domains were upgraded to a domain
> functional level of 2003, that the crossref was not also updated. I have
> tried modifying the values on the domain partition, as well, with the same
> error message.
>
>
>
> Does anyone have suggestions on how to force the crossref to happen or
> otherwise update those values?
>
>
>
> Thanks,
>
> Doug
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
dkkazakUser is Offline

Posts:8

07/18/2008 8:52 AM  
No, all of those objects have been removed (although I did have a number at the beginning of the process).

Thanks,
Doug

-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Matheesha Weerasinghe
Sent: Monday, July 14, 2008 8:57 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] FFL Upgrade Problem

do you have any objects in the lost and found container of the config partition?

2008/7/12 Doug Neely <dkactivedir@kazakinfo.com>:
> I have checked all of the DCs in both domains and all of them show the
> inconsistencies between the domain partition and configuration partition.
>
>
>
> Anything else I should check?
>
>
>
> Thanks,
> Doug
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
> Sent: Friday, July 11, 2008 3:24 PM
>
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FFL Upgrade Problem
>
>
>
> Where are you reading the crossRef from (which DC)? Trying changing focus
> and see if the results differ across instances of the config. NC.
>
> --
> Dean Wells
> * Email: limeypride@gmail.com
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
> Sent: Friday, July 11, 2008 3:21 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] FFL Upgrade Problem
>
>
>
> I have run into a curious situation and am wondering if anyone else has seen
> this or has any suggestions for resolving this. We are a large
> multi-national organization that designed our AD structure back in the
> Windows 2000 days. Because of that, we have 20+ domains with an empty
> root. We are trying to raise our Forest Functional Level to Windows 2003.
> In doing so, we found a problem with two child domains.
>
>
>
> When attempting to upgrade the forest, we have found two child domains are
> being reported as Windows 2000 Mixed mode (even though they were never 2000
> Mixed). In investigating this further using adsiedit, I have found that the
> domain partition has the correct properties for both msDS-Behavior-Version
> (2) and ntMixedDomain (0). When I look at the configuration partition
> cn=partitions for these domains, it is showing <not set> for both of these
> properties. I have tried to manually update these values with the correct
> values, but it gives me the following error message:
>
> Illegal modify operation. Some aspect of the modification is not permitted.
>
>
>
> It would appear that when these two domains were upgraded to a domain
> functional level of 2003, that the crossref was not also updated. I have
> tried modifying the values on the domain partition, as well, with the same
> error message.
>
>
>
> Does anyone have suggestions on how to force the crossref to happen or
> otherwise update those values?
>
>
>
> Thanks,
>
> Doug
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx


List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
aliUser is Offline

Posts:3

07/18/2008 8:52 AM  
Have you checked if there are any replication issues anywhere?

Have you seen http://support.microsoft.com/kb/322692/ which discusses the
error you mentioned?

This one has got me interested - it's the first time I've seen anyone report
problems raising functionality levels.

Alastair.

2008/7/11 Doug Neely <dkactivedir@kazakinfo.com>:

> I have run into a curious situation and am wondering if anyone else has
> seen this or has any suggestions for resolving this. We are a large
> multi-national organization that designed our AD structure back in the
> Windows 2000 days. Because of that, we have 20+ domains with an empty
> root. We are trying to raise our Forest Functional Level to Windows 2003.
> In doing so, we found a problem with two child domains.
>
>
>
> When attempting to upgrade the forest, we have found two child domains are
> being reported as Windows 2000 Mixed mode (even though they were never 2000
> Mixed). In investigating this further using adsiedit, I have found that the
> domain partition has the correct properties for both msDS-Behavior-Version
> (2) and ntMixedDomain (0). When I look at the configuration partition
> cn=partitions for these domains, it is showing <not set> for both of these
> properties. I have tried to manually update these values with the correct
> values, but it gives me the following error message:
>
> *Illegal modify operation. Some aspect of the modification is not
> permitted.*
>
>
>
> It would appear that when these two domains were upgraded to a domain
> functional level of 2003, that the crossref was not also updated. I have
> tried modifying the values on the domain partition, as well, with the same
> error message.
>
>
>
> Does anyone have suggestions on how to force the crossref to happen or
> otherwise update those values?
>
>
>
> Thanks,
>
> Doug
>
>
>

dwellsUser is Offline

Posts:39

07/18/2008 8:52 AM  
Inline ...

--
Dean Wells
Email: limeypride@gmail.com


-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Monday, July 14, 2008 6:24 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem

That is the odd part. The ntdsdsa setting is correct in the domain partition, but is incorrect in the configuration partition.

[Dean Wells] Not following you here Doug. The behavior-version on a DC's NTDSDSA instance doesn't represent the current functional level of that particular DC's domain, rather, it represents that DC's _best_ functional level. Are you saying that certain DC's 'NTDS Settings' objects differ in value depending upon where you read them?

It appears that when I attempt to raise the FFL level, it is actually only checking what the configuration partition
[Dean Wells] Nod, that's by design and is the reason that the crossRef's maintain the func. level themselves; they provide a forest-wide snapshot of each of the forest's domains functional-levels.

setting for msDS-Behavior-Version. Since this does not match up with the domain setting, it fails. It is also unusual because neither of these domains were ever at Windows 2000 mixed mode, but that is what the configuration partition is showing.

[Dean Wells] What is the value of the crossRef behavior-version property for the offending domain(s) ... 0 or <not set>?

[Dean Wells] The mixed-mode thing makes sense too. It's maintained by the property you originally mentioned (nTMixedDomain or thereabouts) which is a treated as a Boolean (INTEGER syntax though for who knows what historical reason) and is only set to a value (i.e. not '<not set>') on the crossRef when the represented domain is promoted to (or through) Win2k native mode ... my guess is that this is an indication of a replication issue ... which is, of course, the reason for the repadmin syntax I requested earlier.

I have also run checks between the specific domains and the root DCs to check for any replication problems. Running a repadmin /showrep = domainname cn=3Dconfiguration.... command shows that replication has been successful between the problem domains and the root domain controllers.

[Dean Wells] Nod, that's usually a fair indication but doesn't reveal mishaps like USN rollbacks. Let's review the metadata per the command I posted.

Is there a way to force the domain partition to update the configuration partition with the correct settings? We have rebooted all of the affected DCs, and this does not seem to update it.

[Dean Wells] Sort of ... moving the domain naming master to those that believe the DFL has been promoted will likely do the trick (assuming their crossRefs are peachy) but it's nothing more than a band-aid since the real problem lies in the 'why' isn't it replicating question/answer?

<snip>

List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
dwellsUser is Offline

Posts:39

07/18/2008 9:00 AM  
What is the crossRef’s msDS-behavior-version value that represents the offending child domain when read from –



1. any DC within that domain

2. the Schema FSMO

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Tuesday, July 15, 2008 12:14 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FFL Upgrade Problem



Well, I did run that command from the schema master. Here is the command I ran so we can make sure I have the right command:

repadmin /showobjmeta rbldc04.rbl.ad…. cn=partitions,cn=configuration,dc=<your forest DN goes here>

Is that right?



As for the Lost and Found Issue, when I took the first step to upgrade to FFL 2003, it reported multiple errors of ntds connections in the Lost and Found config container that were not allowing it to upgrade. In looking over these, they belonged to servers that no longer exist (we had/have an excess of DCs and I have been doing some cleanup work on them). Some of those ntds connections were servers that I was forced to do a metadata cleanup on.



I will send along the Fll in just a bit.



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Tuesday, July 15, 2008 6:34 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



Thanks.



First off, let me make a correction -- l posted that comment last night after a scotch or four and apparently decided that AD should work the way _I_ always thought it should … nice of them to change it so quickly and on the QC for me ... hehe. Anyway, clearly they didn’t J so my point here is that I asked you to run that syntax against the wrong DC; I wanted to review the msDS-Behavior-Version property’s metadata (on the partitions container) on the DC that arbiters write operations against it when, in fact, that’s the role of the schema FSMO for forest functional level increases (PDC for domain.) This lets me determine if we’re in any kind of a half-way house. Could you run that one more time against the schema FSMO … sorry, I’m sure this time, honest guv! In addition, and this may require a email off-list again if you prefer, go and grab my FLL script from here –



ftp://falcon.msetechnology.com/scripts/fll.cmd.txt



… and run that from any domain member/controller supplying your forest root’s FQDN as the only argument. Paste back the results please.



In addition, and spinning off of the ‘Lost and Found’ issues you’ve encountered, can you elaborate as to what was lost and then deleted?

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Monday, July 14, 2008 9:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



OK. Here is the showobj as run from the domain naming master:

This is the root DC





11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute



======= =============== ========= ============= === =========



2314 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11 18:36:23 1 objectClass



4445789 London\ADDC02 4445789 2002-12-02 22:25:39 5 cn



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 instanceType



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 whenCreated



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600000 isDeleted



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 showInAdvancedViewOnly



20543389 London\ADDC02 20543389 2004-11-05 15:10:554600003 nTSecurityDescriptor



4445789 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 name



37209883 USW-THQ\ADDC03 64480865 2008-07-11 05:50:054600026 fSMORoleOwner



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 systemFlags



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver



======= ============ ============= ================= ======= ======= ===



Distinguished Name



=============================





This is from the only domain controller on one of the domains:





repadmin running command /showobjmeta against server usndc01.usn.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute



======= =============== ========= ============= === =========



2348 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11 18:36:23 1 objectClass



2348 USN\USNDC01 2348 2003-02-27 16:57:27 1 cn



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 instanceType



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 whenCreated



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600000 isDeleted



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 showInAdvancedViewOnly



7071630 London\ADDC02 20543389 2004-11-05 15:10:554600003 nTSecurityDescriptor



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 name



27355595 USW-THQ\ADDC03 64480865 2008-07-11 05:50:054600026 fSMORoleOwner



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 systemFlags



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver



======= ============ ============= ================= ======= ======= ===



Distinguished Name



=============================



And this is from the two DCs in the other domain:





repadmin running command /showobjmeta against server RBLDC02.rbl.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute



======= =============== ========= ============= === =========



5718 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11 18:36:23 1 objectClass



5718 London\RBLDC02 5718 2006-08-01 14:38:05 1 cn



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 instanceType



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 whenCreated



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600000 isDeleted



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 showInAdvancedViewOnly



5718 London\ADDC02 20543389 2004-11-05 15:10:554600003 nTSecurityDescriptor



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 name



2890666 USW-THQ\ADDC03 64480865 2008-07-11 05:50:054600026 fSMORoleOwner



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 systemFlags



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver



======= ============ ============= ================= ======= ======= ===



Distinguished Name



=============================









repadmin running command /showobjmeta against server rbldc04.rbl.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute



======= =============== ========= ============= === =========



5661 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11 18:36:23 1 objectClass



5661 London\RBLDC04 5661 2008-02-27 20:52:44 1 cn



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 instanceType



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 whenCreated



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600000 isDeleted



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 showInAdvancedViewOnly



5661 London\ADDC02 20543389 2004-11-05 15:10:554600003 nTSecurityDescriptor



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 name



1756030 USW-THQ\ADDC03 64480865 2008-07-11 05:50:054600026 fSMORoleOwner



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 systemFlags



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver



======= ============ ============= ================= ======= ======= ===



Distinguished Name



=============================







Thanks for your help!



Doug



-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Monday, July 14, 2008 5:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



Inline ...



--

Dean Wells

Email: limeypride@gmail.com





-----Original Message-----

From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely

Sent: Monday, July 14, 2008 6:24 PM

To: ActiveDir@mail.activedir.org

Subject: RE: [ActiveDir] FFL Upgrade Problem



That is the odd part. The ntdsdsa setting is correct in the domain partition, but is incorrect in the configuration partition.



[Dean Wells] Not following you here Doug. The behavior-version on a DC's NTDSDSA instance doesn't represent the current functional level of that particular DC's domain, rather, it represents that DC's _best_ functional level. Are you saying that certain DC's 'NTDS Settings' objects differ in value depending upon where you read them?



It appears that when I attempt to raise the FFL level, it is actually only checking what the configuration partition

[Dean Wells] Nod, that's by design and is the reason that the crossRef's maintain the func. level themselves; they provide a forest-wide snapshot of each of the forest's domains functional-levels.



setting for msDS-Behavior-Version. Since this does not match up with the domain setting, it fails. It is also unusual because neither of these domains were ever at Windows 2000 mixed mode, but that is what the configuration partition is showing.



[Dean Wells] What is the value of the crossRef behavior-version property for the offending domain(s) ... 0 or <not set>?



[Dean Wells] The mixed-mode thing makes sense too. It's maintained by the property you originally mentioned (nTMixedDomain or thereabouts) which is a treated as a Boolean (INTEGER syntax though for who knows what historical reason) and is only set to a value (i.e. not '<not set>') on the crossRef when the represented domain is promoted to (or through) Win2k native mode ... my guess is that this is an indication of a replication issue ... which is, of course, the reason for the repadmin syntax I requested earlier.



I have also run checks between the specific domains and the root DCs to check for any replication problems. Running a repadmin /showrep = domainname cn=3Dconfiguration.... command shows that replication has been successful between the problem domains and the root domain controllers.



[Dean Wells] Nod, that's usually a fair indication but doesn't reveal mishaps like USN rollbacks. Let's review the metadata per the command I posted.



Is there a way to force the domain partition to update the configuration partition with the correct settings? We have rebooted all of the affected DCs, and this does not seem to update it.



[Dean Wells] Sort of ... moving the domain naming master to those that believe the DFL has been promoted will likely do the trick (assuming their crossRefs are peachy) but it's nothing more than a band-aid since the real problem lies in the 'why' isn't it replicating question/answer?



<snip>



List info : http://www.activedir.org/List.aspx

List FAQ : http://www.activedir.org/ListFAQ.aspx

List archive: http://www.activedir.org/ma/default.aspx


dkkazakUser is Offline

Posts:8

07/18/2008 9:02 AM  
I’m not sure how to check that. What is the best method to do so?



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Wednesday, July 16, 2008 12:04 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



What is the crossRef’s msDS-behavior-version value that represents the offending child domain when read from –



1. any DC within that domain

2. the Schema FSMO

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Tuesday, July 15, 2008 12:14 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FFL Upgrade Problem



Well, I did run that command from the schema master. Here is the command I ran so we can make sure I have the right command:

repadmin /showobjmeta rbldc04.rbl.ad…. cn=partitions,cn=configuration,dc=<your forest DN goes here>

Is that right?



As for the Lost and Found Issue, when I took the first step to upgrade to FFL 2003, it reported multiple errors of ntds connections in the Lost and Found config container that were not allowing it to upgrade. In looking over these, they belonged to servers that no longer exist (we had/have an excess of DCs and I have been doing some cleanup work on them). Some of those ntds connections were servers that I was forced to do a metadata cleanup on.



I will send along the Fll in just a bit.



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Tuesday, July 15, 2008 6:34 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



Thanks.



First off, let me make a correction -- l posted that comment last night after a scotch or four and apparently decided that AD should work the way _I_ always thought it should … nice of them to change it so quickly and on the QC for me ... hehe. Anyway, clearly they didn’t J so my point here is that I asked you to run that syntax against the wrong DC; I wanted to review the msDS-Behavior-Version property’s metadata (on the partitions container) on the DC that arbiters write operations against it when, in fact, that’s the role of the schema FSMO for forest functional level increases (PDC for domain.) This lets me determine if we’re in any kind of a half-way house. Could you run that one more time against the schema FSMO … sorry, I’m sure this time, honest guv! In addition, and this may require a email off-list again if you prefer, go and grab my FLL script from here –



ftp://falcon.msetechnology.com/scripts/fll.cmd.txt



… and run that from any domain member/controller supplying your forest root’s FQDN as the only argument. Paste back the results please.



In addition, and spinning off of the ‘Lost and Found’ issues you’ve encountered, can you elaborate as to what was lost and then deleted?

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Monday, July 14, 2008 9:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



OK. Here is the showobj as run from the domain naming master:

This is the root DC





11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute



======= =============== ========= ============= === =========



2314 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11 18:36:23 1 objectClass



4445789 London\ADDC02 4445789 2002-12-02 22:25:39 5 cn



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 instanceType



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 whenCreated



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600000 isDeleted



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 showInAdvancedViewOnly



20543389 London\ADDC02 20543389 2004-11-05 15:10:554600003 nTSecurityDescriptor



4445789 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 name



37209883 USW-THQ\ADDC03 64480865 2008-07-11 05:50:054600026 fSMORoleOwner



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 systemFlags



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver



======= ============ ============= ================= ======= ======= ===



Distinguished Name



=============================





This is from the only domain controller on one of the domains:





repadmin running command /showobjmeta against server usndc01.usn.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute



======= =============== ========= ============= === =========



2348 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11 18:36:23 1 objectClass



2348 USN\USNDC01 2348 2003-02-27 16:57:27 1 cn



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 instanceType



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 whenCreated



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600000 isDeleted



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 showInAdvancedViewOnly



7071630 London\ADDC02 20543389 2004-11-05 15:10:554600003 nTSecurityDescriptor



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 name



27355595 USW-THQ\ADDC03 64480865 2008-07-11 05:50:054600026 fSMORoleOwner



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 systemFlags



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver



======= ============ ============= ================= ======= ======= ===



Distinguished Name



=============================



And this is from the two DCs in the other domain:





repadmin running command /showobjmeta against server RBLDC02.rbl.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute



======= =============== ========= ============= === =========



5718 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11 18:36:23 1 objectClass



5718 London\RBLDC02 5718 2006-08-01 14:38:05 1 cn



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 instanceType



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 whenCreated



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600000 isDeleted



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 showInAdvancedViewOnly



5718 London\ADDC02 20543389 2004-11-05 15:10:554600003 nTSecurityDescriptor



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 name



2890666 USW-THQ\ADDC03 64480865 2008-07-11 05:50:054600026 fSMORoleOwner



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 systemFlags



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver



======= ============ ============= ================= ======= ======= ===



Distinguished Name



=============================









repadmin running command /showobjmeta against server rbldc04.rbl.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute



======= =============== ========= ============= === =========



5661 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11 18:36:23 1 objectClass



5661 London\RBLDC04 5661 2008-02-27 20:52:44 1 cn



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 instanceType



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 whenCreated



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600000 isDeleted



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 showInAdvancedViewOnly



5661 London\ADDC02 20543389 2004-11-05 15:10:554600003 nTSecurityDescriptor



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 name



1756030 USW-THQ\ADDC03 64480865 2008-07-11 05:50:054600026 fSMORoleOwner



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 systemFlags



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21 18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver



======= ============ ============= ================= ======= ======= ===



Distinguished Name



=============================







Thanks for your help!



Doug



-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Monday, July 14, 2008 5:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



Inline ...



--

Dean Wells

Email: limeypride@gmail.com





-----Original Message-----

From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely

Sent: Monday, July 14, 2008 6:24 PM

To: ActiveDir@mail.activedir.org

Subject: RE: [ActiveDir] FFL Upgrade Problem



That is the odd part. The ntdsdsa setting is correct in the domain partition, but is incorrect in the configuration partition.



[Dean Wells] Not following you here Doug. The behavior-version on a DC's NTDSDSA instance doesn't represent the current functional level of that particular DC's domain, rather, it represents that DC's _best_ functional level. Are you saying that certain DC's 'NTDS Settings' objects differ in value depending upon where you read them?



It appears that when I attempt to raise the FFL level, it is actually only checking what the configuration partition

[Dean Wells] Nod, that's by design and is the reason that the crossRef's maintain the func. level themselves; they provide a forest-wide snapshot of each of the forest's domains functional-levels.



setting for msDS-Behavior-Version. Since this does not match up with the domain setting, it fails. It is also unusual because neither of these domains were ever at Windows 2000 mixed mode, but that is what the configuration partition is showing.



[Dean Wells] What is the value of the crossRef behavior-version property for the offending domain(s) ... 0 or <not set>?



[Dean Wells] The mixed-mode thing makes sense too. It's maintained by the property you originally mentioned (nTMixedDomain or thereabouts) which is a treated as a Boolean (INTEGER syntax though for who knows what historical reason) and is only set to a value (i.e. not '<not set>') on the crossRef when the represented domain is promoted to (or through) Win2k native mode ... my guess is that this is an indication of a replication issue ... which is, of course, the reason for the repadmin syntax I requested earlier.



I have also run checks between the specific domains and the root DCs to check for any replication problems. Running a repadmin /showrep = domainname cn=3Dconfiguration.... command shows that replication has been successful between the problem domains and the root domain controllers.



[Dean Wells] Nod, that's usually a fair indication but doesn't reveal mishaps like USN rollbacks. Let's review the metadata per the command I posted.



Is there a way to force the domain partition to update the configuration partition with the correct settings? We have rebooted all of the affected DCs, and this does not seem to update it.



[Dean Wells] Sort of ... moving the domain naming master to those that believe the DFL has been promoted will likely do the trick (assuming their crossRefs are peachy) but it's nothing more than a band-aid since the real problem lies in the 'why' isn't it replicating question/answer?



<snip>



List info : http://www.activedir.org/List.aspx

List FAQ : http://www.activedir.org/ListFAQ.aspx

List archive: http://www.activedir.org/ma/default.aspx


dkkazakUser is Offline

Posts:8

07/18/2008 9:10 AM  
I'm sorry, I probably wasn't clear on what I'm not sure how to find. I have
used ADSIedit to find the msDS-Behavior value, but is there also a crossref
value that should match up between the domain and configuration partition?
If so, I have been unable to find it. I have opened up the properties for
the domain in both the domain partition (same place where I found the
msDS-Behavior value) and the domain name in the cn=partition of the config
partition (again where the msDS-Behavior value was found). It would seem
like there should be some crossref value to keep these in sync, but I am not
seeing a specific value for this.



Is this what I should be looking for or should I just report back below?



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Wednesday, July 16, 2008 1:40 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



This will dump the info the fastest for you probably



adfind -h DCNAME -partitions msDS-behavior-version



You will get some extra info for the other partitions but that is fine I
expect.





G:\>adfind -h test-dc1 -partitions msDS-behavior-version



AdFind V01.37.00cpp Joe Richards ( <mailto:joe@joeware.net> joe@joeware.net)
June 2007



Using server: TEST-DC1.test.loc:389
Directory: Windows Server 2003
Base DN: CN=Partitions,CN=Configuration,DC=test,DC=loc



dn:CN=Partitions,CN=Configuration,DC=test,DC=loc
>msDS-Behavior-Version: 2



dn:CN=Enterprise Schema,CN=Partitions,CN=Configuration,DC=test,DC=loc



dn:CN=347ec069-e522-49df-9a31-df355b933475,CN=Partitions,CN=Configuration,DC
=test,DC=loc



dn:CN=d45f9fa6-daca-4de3-b172-1b51fb8e8d23,CN=Partitions,CN=Configuration,DC
=test,DC=loc



dn:CN=TEST,CN=Partitions,CN=Configuration,DC=test,DC=loc
>msDS-Behavior-Version: 2



dn:CN=Enterprise Configuration,CN=Partitions,CN=Configuration,DC=test,DC=loc




6 Objects returned







--

O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm







_____

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Wednesday, July 16, 2008 2:55 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem

I'm not sure how to check that. What is the best method to do so?



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Wednesday, July 16, 2008 12:04 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



What is the crossRef's msDS-behavior-version value that represents the
offending child domain when read from -



1. any DC within that domain

2. the Schema FSMO

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Tuesday, July 15, 2008 12:14 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FFL Upgrade Problem



Well, I did run that command from the schema master. Here is the command I
ran so we can make sure I have the right command:

repadmin /showobjmeta rbldc04.rbl.ad..
cn=partitions,cn=configuration,dc=<your forest DN goes here>

Is that right?



As for the Lost and Found Issue, when I took the first step to upgrade to
FFL 2003, it reported multiple errors of ntds connections in the Lost and
Found config container that were not allowing it to upgrade. In looking
over these, they belonged to servers that no longer exist (we had/have an
excess of DCs and I have been doing some cleanup work on them). Some of
those ntds connections were servers that I was forced to do a metadata
cleanup on.



I will send along the Fll in just a bit.



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Tuesday, July 15, 2008 6:34 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



Thanks.



First off, let me make a correction -- l posted that comment last night
after a scotch or four and apparently decided that AD should work the way
_I_ always thought it should . nice of them to change it so quickly and on
the QC for me ... hehe. Anyway, clearly they didn't J so my point here is
that I asked you to run that syntax against the wrong DC; I wanted to review
the msDS-Behavior-Version property's metadata (on the partitions container)
on the DC that arbiters write operations against it when, in fact, that's
the role of the schema FSMO for forest functional level increases (PDC for
domain.) This lets me determine if we're in any kind of a half-way house.
Could you run that one more time against the schema FSMO . sorry, I'm sure
this time, honest guv! In addition, and this may require a email off-list
again if you prefer, go and grab my FLL script from here -



ftp://falcon.msetechnology.com/scripts/fll.cmd.txt



. and run that from any domain member/controller supplying your forest
root's FQDN as the only argument. Paste back the results please.



In addition, and spinning off of the 'Lost and Found' issues you've
encountered, can you elaborate as to what was lost and then deleted?

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Monday, July 14, 2008 9:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



OK. Here is the showobj as run from the domain naming master:

This is the root DC





11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute



======= =============== ========= =============
=== =========



2314 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
18:36:23 1 objectClass



4445789 London\ADDC02 4445789 2002-12-02
22:25:39 5 cn



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 instanceType



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 whenCreated



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600000 isDeleted



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 showInAdvancedViewOnly



20543389 London\ADDC02 20543389 2004-11-05
15:10:554600003 nTSecurityDescriptor



4445789 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 name



37209883 USW-THQ\ADDC03 64480865 2008-07-11
05:50:054600026 fSMORoleOwner



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 systemFlags



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating
DC Loc.USN Org.USN Ver



======= ============ =============
================= ======= ======= ===



Distinguished Name



=============================





This is from the only domain controller on one of the domains:





repadmin running command /showobjmeta against server
usndc01.usn.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute



======= =============== ========= =============
=== =========



2348 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
18:36:23 1 objectClass



2348 USN\USNDC01 2348 2003-02-27
16:57:27 1 cn



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 instanceType



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 whenCreated



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600000 isDeleted



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 showInAdvancedViewOnly



7071630 London\ADDC02 20543389 2004-11-05
15:10:554600003 nTSecurityDescriptor



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 name



27355595 USW-THQ\ADDC03 64480865 2008-07-11
05:50:054600026 fSMORoleOwner



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 systemFlags



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating
DC Loc.USN Org.USN Ver



======= ============ =============
================= ======= ======= ===



Distinguished Name



=============================



And this is from the two DCs in the other domain:





repadmin running command /showobjmeta against server
RBLDC02.rbl.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute



======= =============== ========= =============
=== =========



5718 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
18:36:23 1 objectClass



5718 London\RBLDC02 5718 2006-08-01
14:38:05 1 cn



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 instanceType



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 whenCreated



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600000 isDeleted



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 showInAdvancedViewOnly



5718 London\ADDC02 20543389 2004-11-05
15:10:554600003 nTSecurityDescriptor



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 name



2890666 USW-THQ\ADDC03 64480865 2008-07-11
05:50:054600026 fSMORoleOwner



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 systemFlags



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating
DC Loc.USN Org.USN Ver



======= ============ =============
================= ======= ======= ===



Distinguished Name



=============================









repadmin running command /showobjmeta against server
rbldc04.rbl.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute



======= =============== ========= =============
=== =========



5661 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
18:36:23 1 objectClass



5661 London\RBLDC04 5661 2008-02-27
20:52:44 1 cn



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 instanceType



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 whenCreated



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600000 isDeleted



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 showInAdvancedViewOnly



5661 London\ADDC02 20543389 2004-11-05
15:10:554600003 nTSecurityDescriptor



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 name



1756030 USW-THQ\ADDC03 64480865 2008-07-11
05:50:054600026 fSMORoleOwner



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 systemFlags



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating
DC Loc.USN Org.USN Ver



======= ============ =============
================= ======= ======= ===



Distinguished Name



=============================







Thanks for your help!



Doug



-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Monday, July 14, 2008 5:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



Inline ...



--

Dean Wells

Email: limeypride@gmail.com





-----Original Message-----

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely

Sent: Monday, July 14, 2008 6:24 PM

To: ActiveDir@mail.activedir.org

Subject: RE: [ActiveDir] FFL Upgrade Problem



That is the odd part. The ntdsdsa setting is correct in the domain
partition, but is incorrect in the configuration partition.



[Dean Wells] Not following you here Doug. The behavior-version on a DC's
NTDSDSA instance doesn't represent the current functional level of that
particular DC's domain, rather, it represents that DC's _best_ functional
level. Are you saying that certain DC's 'NTDS Settings' objects differ in
value depending upon where you read them?



It appears that when I attempt to raise the FFL level, it is actually only
checking what the configuration partition

[Dean Wells] Nod, that's by design and is the reason that the crossRef's
maintain the func. level themselves; they provide a forest-wide snapshot of
each of the forest's domains functional-levels.



setting for msDS-Behavior-Version. Since this does not match up with the
domain setting, it fails. It is also unusual because neither of these
domains were ever at Windows 2000 mixed mode, but that is what the
configuration partition is showing.



[Dean Wells] What is the value of the crossRef behavior-version property for
the offending domain(s) ... 0 or <not set>?



[Dean Wells] The mixed-mode thing makes sense too. It's maintained by the
property you originally mentioned (nTMixedDomain or thereabouts) which is a
treated as a Boolean (INTEGER syntax though for who knows what historical
reason) and is only set to a value (i.e. not '<not set>') on the crossRef
when the represented domain is promoted to (or through) Win2k native mode
... my guess is that this is an indication of a replication issue ... which
is, of course, the reason for the repadmin syntax I requested earlier.



I have also run checks between the specific domains and the root DCs to
check for any replication problems. Running a repadmin /showrep =
domainname cn=3Dconfiguration.... command shows that replication has been
successful between the problem domains and the root domain controllers.



[Dean Wells] Nod, that's usually a fair indication but doesn't reveal
mishaps like USN rollbacks. Let's review the metadata per the command I
posted.



Is there a way to force the domain partition to update the configuration
partition with the correct settings? We have rebooted all of the affected
DCs, and this does not seem to update it.



[Dean Wells] Sort of ... moving the domain naming master to those that
believe the DFL has been promoted will likely do the trick (assuming their
crossRefs are peachy) but it's nothing more than a band-aid since the real
problem lies in the 'why' isn't it replicating question/answer?



<snip>



List info : http://www.activedir.org/List.aspx

List FAQ : http://www.activedir.org/ListFAQ.aspx

List archive: http://www.activedir.org/ma/default.aspx


dwellsUser is Offline

Posts:39

07/19/2008 12:04 PM  
joe's syntax will give us what we need.

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Wednesday, July 16, 2008 7:42 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



I'm sorry, I probably wasn't clear on what I'm not sure how to find. I have
used ADSIedit to find the msDS-Behavior value, but is there also a crossref
value that should match up between the domain and configuration partition?
If so, I have been unable to find it. I have opened up the properties for
the domain in both the domain partition (same place where I found the
msDS-Behavior value) and the domain name in the cn=partition of the config
partition (again where the msDS-Behavior value was found). It would seem
like there should be some crossref value to keep these in sync, but I am not
seeing a specific value for this.



Is this what I should be looking for or should I just report back below?



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Wednesday, July 16, 2008 1:40 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



This will dump the info the fastest for you probably



adfind -h DCNAME -partitions msDS-behavior-version



You will get some extra info for the other partitions but that is fine I
expect.





G:\>adfind -h test-dc1 -partitions msDS-behavior-version



AdFind V01.37.00cpp Joe Richards ( <mailto:joe@joeware.net> joe@joeware.net)
June 2007



Using server: TEST-DC1.test.loc:389
Directory: Windows Server 2003
Base DN: CN=Partitions,CN=Configuration,DC=test,DC=loc



dn:CN=Partitions,CN=Configuration,DC=test,DC=loc
>msDS-Behavior-Version: 2



dn:CN=Enterprise Schema,CN=Partitions,CN=Configuration,DC=test,DC=loc



dn:CN=347ec069-e522-49df-9a31-df355b933475,CN=Partitions,CN=Configuration,DC
=test,DC=loc



dn:CN=d45f9fa6-daca-4de3-b172-1b51fb8e8d23,CN=Partitions,CN=Configuration,DC
=test,DC=loc



dn:CN=TEST,CN=Partitions,CN=Configuration,DC=test,DC=loc
>msDS-Behavior-Version: 2



dn:CN=Enterprise Configuration,CN=Partitions,CN=Configuration,DC=test,DC=loc




6 Objects returned







--

O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm







_____

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Wednesday, July 16, 2008 2:55 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem

I'm not sure how to check that. What is the best method to do so?



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Wednesday, July 16, 2008 12:04 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



What is the crossRef's msDS-behavior-version value that represents the
offending child domain when read from -



1. any DC within that domain

2. the Schema FSMO

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Tuesday, July 15, 2008 12:14 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] FFL Upgrade Problem



Well, I did run that command from the schema master. Here is the command I
ran so we can make sure I have the right command:

repadmin /showobjmeta rbldc04.rbl.ad..
cn=partitions,cn=configuration,dc=<your forest DN goes here>

Is that right?



As for the Lost and Found Issue, when I took the first step to upgrade to
FFL 2003, it reported multiple errors of ntds connections in the Lost and
Found config container that were not allowing it to upgrade. In looking
over these, they belonged to servers that no longer exist (we had/have an
excess of DCs and I have been doing some cleanup work on them). Some of
those ntds connections were servers that I was forced to do a metadata
cleanup on.



I will send along the Fll in just a bit.



Thanks,

Doug



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Tuesday, July 15, 2008 6:34 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



Thanks.



First off, let me make a correction -- l posted that comment last night
after a scotch or four and apparently decided that AD should work the way
_I_ always thought it should . nice of them to change it so quickly and on
the QC for me ... hehe. Anyway, clearly they didn't J so my point here is
that I asked you to run that syntax against the wrong DC; I wanted to review
the msDS-Behavior-Version property's metadata (on the partitions container)
on the DC that arbiters write operations against it when, in fact, that's
the role of the schema FSMO for forest functional level increases (PDC for
domain.) This lets me determine if we're in any kind of a half-way house.
Could you run that one more time against the schema FSMO . sorry, I'm sure
this time, honest guv! In addition, and this may require a email off-list
again if you prefer, go and grab my FLL script from here -



ftp://falcon.msetechnology.com/scripts/fll.cmd.txt



. and run that from any domain member/controller supplying your forest
root's FQDN as the only argument. Paste back the results please.



In addition, and spinning off of the 'Lost and Found' issues you've
encountered, can you elaborate as to what was lost and then deleted?

--
Dean Wells
* Email: limeypride@gmail.com



From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
Sent: Monday, July 14, 2008 9:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



OK. Here is the showobj as run from the domain naming master:

This is the root DC





11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute



======= =============== ========= =============
=== =========



2314 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
18:36:23 1 objectClass



4445789 London\ADDC02 4445789 2002-12-02
22:25:39 5 cn



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 instanceType



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 whenCreated



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600000 isDeleted



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 showInAdvancedViewOnly



20543389 London\ADDC02 20543389 2004-11-05
15:10:554600003 nTSecurityDescriptor



4445789 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 name



37209883 USW-THQ\ADDC03 64480865 2008-07-11
05:50:054600026 fSMORoleOwner



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 systemFlags



4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating
DC Loc.USN Org.USN Ver



======= ============ =============
================= ======= ======= ===



Distinguished Name



=============================





This is from the only domain controller on one of the domains:





repadmin running command /showobjmeta against server
usndc01.usn.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute



======= =============== ========= =============
=== =========



2348 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
18:36:23 1 objectClass



2348 USN\USNDC01 2348 2003-02-27
16:57:27 1 cn



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 instanceType



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 whenCreated



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600000 isDeleted



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 showInAdvancedViewOnly



7071630 London\ADDC02 20543389 2004-11-05
15:10:554600003 nTSecurityDescriptor



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 name



27355595 USW-THQ\ADDC03 64480865 2008-07-11
05:50:054600026 fSMORoleOwner



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 systemFlags



2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating
DC Loc.USN Org.USN Ver



======= ============ =============
================= ======= ======= ===



Distinguished Name



=============================



And this is from the two DCs in the other domain:





repadmin running command /showobjmeta against server
RBLDC02.rbl.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute



======= =============== ========= =============
=== =========



5718 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
18:36:23 1 objectClass



5718 London\RBLDC02 5718 2006-08-01
14:38:05 1 cn



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 instanceType



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 whenCreated



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600000 isDeleted



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 showInAdvancedViewOnly



5718 London\ADDC02 20543389 2004-11-05
15:10:554600003 nTSecurityDescriptor



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 name



2890666 USW-THQ\ADDC03 64480865 2008-07-11
05:50:054600026 fSMORoleOwner



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 systemFlags



5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating
DC Loc.USN Org.USN Ver



======= ============ =============
================= ======= ======= ===



Distinguished Name



=============================









repadmin running command /showobjmeta against server
rbldc04.rbl.ad.contoso.com











11 entries.



Loc.USN Originating DC Org.USN Org.Time/Date
Ver Attribute



======= =============== ========= =============
=== =========



5661 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
18:36:23 1 objectClass



5661 London\RBLDC04 5661 2008-02-27
20:52:44 1 cn



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 instanceType



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 whenCreated



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600000 isDeleted



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 showInAdvancedViewOnly



5661 London\ADDC02 20543389 2004-11-05
15:10:554600003 nTSecurityDescriptor



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 name



1756030 USW-THQ\ADDC03 64480865 2008-07-11
05:50:054600026 fSMORoleOwner



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 systemFlags



5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
18:21:004600001 objectCategory



0 entries.



Type Attribute Last Mod Time Originating
DC Loc.USN Org.USN Ver



======= ============ =============
================= ======= ======= ===



Distinguished Name



=============================







Thanks for your help!



Doug



-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Monday, July 14, 2008 5:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] FFL Upgrade Problem



Inline ...



--

Dean Wells

Email: limeypride@gmail.com





-----Original Message-----

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely

Sent: Monday, July 14, 2008 6:24 PM

To: ActiveDir@mail.activedir.org

Subject: RE: [ActiveDir] FFL Upgrade Problem



That is the odd part. The ntdsdsa setting is correct in the domain
partition, but is incorrect in the configuration partition.



[Dean Wells] Not following you here Doug. The behavior-version on a DC's
NTDSDSA instance doesn't represent the current functional level of that
particular DC's domain, rather, it represents that DC's _best_ functional
level. Are you saying that certain DC's 'NTDS Settings' objects differ in
value depending upon where you read them?



It appears that when I attempt to raise the FFL level, it is actually only
checking what the configuration partition

[Dean Wells] Nod, that's by design and is the reason that the crossRef's
maintain the func. level themselves; they provide a forest-wide snapshot of
each of the forest's domains functional-levels.



setting for msDS-Behavior-Version. Since this does not match up with the
domain setting, it fails. It is also unusual because neither of these
domains were ever at Windows 2000 mixed mode, but that is what the
configuration partition is showing.



[Dean Wells] What is the value of the crossRef behavior-version property for
the offending domain(s) ... 0 or <not set>?



[Dean Wells] The mixed-mode thing makes sense too. It's maintained by the
property you originally mentioned (nTMixedDomain or thereabouts) which is a
treated as a Boolean (INTEGER syntax though for who knows what historical
reason) and is only set to a value (i.e. not '<not set>') on the crossRef
when the represented domain is promoted to (or through) Win2k native mode
... my guess is that this is an indication of a replication issue ... which
is, of course, the reason for the repadmin syntax I requested earlier.



I have also run checks between the specific domains and the root DCs to
check for any replication problems. Running a repadmin /showrep =
domainname cn=3Dconfiguration.... command shows that replication has been
successful between the problem domains and the root domain controllers.



[Dean Wells] Nod, that's usually a fair indication but doesn't reveal
mishaps like USN rollbacks. Let's review the metadata per the command I
posted.



Is there a way to force the domain partition to update the configuration
partition with the correct settings? We have rebooted all of the affected
DCs, and this does not seem to update it.



[Dean Wells] Sort of ... moving the domain naming master to those that
believe the DFL has been promoted will likely do the trick (assuming their
crossRefs are peachy) but it's nothing more than a band-aid since the real
problem lies in the 'why' isn't it replicating question/answer?



<snip>



List info : http://www.activedir.org/List.aspx

List FAQ : http://www.activedir.org/ListFAQ.aspx

List archive: http://www.activedir.org/ma/default.aspx


aliUser is Offline

Posts:3

08/03/2008 5:17 PM  
Hi,

This thread seemed to peter out, was the root cause ever found?

Alastair.

On 19/07/2008, Dean Wells <limeypride@gmail.com> wrote:
> joe's syntax will give us what we need.
>
> --
> Dean Wells
> * Email: limeypride@gmail.com
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
> Sent: Wednesday, July 16, 2008 7:42 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FFL Upgrade Problem
>
>
>
> I'm sorry, I probably wasn't clear on what I'm not sure how to find. I have
> used ADSIedit to find the msDS-Behavior value, but is there also a crossref
> value that should match up between the domain and configuration partition?
> If so, I have been unable to find it. I have opened up the properties for
> the domain in both the domain partition (same place where I found the
> msDS-Behavior value) and the domain name in the cn=partition of the config
> partition (again where the msDS-Behavior value was found). It would seem
> like there should be some crossref value to keep these in sync, but I am not
> seeing a specific value for this.
>
>
>
> Is this what I should be looking for or should I just report back below?
>
>
>
> Thanks,
>
> Doug
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
> Sent: Wednesday, July 16, 2008 1:40 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FFL Upgrade Problem
>
>
>
> This will dump the info the fastest for you probably
>
>
>
> adfind -h DCNAME -partitions msDS-behavior-version
>
>
>
> You will get some extra info for the other partitions but that is fine I
> expect.
>
>
>
>
>
> G:\>adfind -h test-dc1 -partitions msDS-behavior-version
>
>
>
> AdFind V01.37.00cpp Joe Richards ( <mailto:joe@joeware.net> joe@joeware.net)
> June 2007
>
>
>
> Using server: TEST-DC1.test.loc:389
> Directory: Windows Server 2003
> Base DN: CN=Partitions,CN=Configuration,DC=test,DC=loc
>
>
>
> dn:CN=Partitions,CN=Configuration,DC=test,DC=loc
>>msDS-Behavior-Version: 2
>
>
>
> dn:CN=Enterprise Schema,CN=Partitions,CN=Configuration,DC=test,DC=loc
>
>
>
> dn:CN=347ec069-e522-49df-9a31-df355b933475,CN=Partitions,CN=Configuration,DC
> =test,DC=loc
>
>
>
> dn:CN=d45f9fa6-daca-4de3-b172-1b51fb8e8d23,CN=Partitions,CN=Configuration,DC
> =test,DC=loc
>
>
>
> dn:CN=TEST,CN=Partitions,CN=Configuration,DC=test,DC=loc
>>msDS-Behavior-Version: 2
>
>
>
> dn:CN=Enterprise Configuration,CN=Partitions,CN=Configuration,DC=test,DC=loc
>
>
>
>
> 6 Objects returned
>
>
>
>
>
>
>
> --
>
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
> Sent: Wednesday, July 16, 2008 2:55 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FFL Upgrade Problem
>
> I'm not sure how to check that. What is the best method to do so?
>
>
>
> Thanks,
>
> Doug
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
> Sent: Wednesday, July 16, 2008 12:04 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FFL Upgrade Problem
>
>
>
> What is the crossRef's msDS-behavior-version value that represents the
> offending child domain when read from -
>
>
>
> 1. any DC within that domain
>
> 2. the Schema FSMO
>
> --
> Dean Wells
> * Email: limeypride@gmail.com
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
> Sent: Tuesday, July 15, 2008 12:14 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] FFL Upgrade Problem
>
>
>
> Well, I did run that command from the schema master. Here is the command I
> ran so we can make sure I have the right command:
>
> repadmin /showobjmeta rbldc04.rbl.ad..
> cn=partitions,cn=configuration,dc=<your forest DN goes here>
>
> Is that right?
>
>
>
> As for the Lost and Found Issue, when I took the first step to upgrade to
> FFL 2003, it reported multiple errors of ntds connections in the Lost and
> Found config container that were not allowing it to upgrade. In looking
> over these, they belonged to servers that no longer exist (we had/have an
> excess of DCs and I have been doing some cleanup work on them). Some of
> those ntds connections were servers that I was forced to do a metadata
> cleanup on.
>
>
>
> I will send along the Fll in just a bit.
>
>
>
> Thanks,
>
> Doug
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
> Sent: Tuesday, July 15, 2008 6:34 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FFL Upgrade Problem
>
>
>
> Thanks.
>
>
>
> First off, let me make a correction -- l posted that comment last night
> after a scotch or four and apparently decided that AD should work the way
> _I_ always thought it should . nice of them to change it so quickly and on
> the QC for me ... hehe. Anyway, clearly they didn't J so my point here is
> that I asked you to run that syntax against the wrong DC; I wanted to review
> the msDS-Behavior-Version property's metadata (on the partitions container)
> on the DC that arbiters write operations against it when, in fact, that's
> the role of the schema FSMO for forest functional level increases (PDC for
> domain.) This lets me determine if we're in any kind of a half-way house.
> Could you run that one more time against the schema FSMO . sorry, I'm sure
> this time, honest guv! In addition, and this may require a email off-list
> again if you prefer, go and grab my FLL script from here -
>
>
>
> ftp://falcon.msetechnology.com/scripts/fll.cmd.txt
>
>
>
> . and run that from any domain member/controller supplying your forest
> root's FQDN as the only argument. Paste back the results please.
>
>
>
> In addition, and spinning off of the 'Lost and Found' issues you've
> encountered, can you elaborate as to what was lost and then deleted?
>
> --
> Dean Wells
> * Email: limeypride@gmail.com
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Doug Neely
> Sent: Monday, July 14, 2008 9:38 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] FFL Upgrade Problem
>
>
>
> OK. Here is the showobj as run from the domain naming master:
>
> This is the root DC
>
>
>
>
>
> 11 entries.
>
>
>
> Loc.USN Originating DC Org.USN Org.Time/Date
> Ver Attribute
>
>
>
> ======= =============== ========= =============
> === =========
>
>
>
> 2314 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
> 18:36:23 1 objectClass
>
>
>
> 4445789 London\ADDC02 4445789 2002-12-02
> 22:25:39 5 cn
>
>
>
> 4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 instanceType
>
>
>
> 4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 whenCreated
>
>
>
> 4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600000 isDeleted
>
>
>
> 4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 showInAdvancedViewOnly
>
>
>
> 20543389 London\ADDC02 20543389 2004-11-05
> 15:10:554600003 nTSecurityDescriptor
>
>
>
> 4445789 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 name
>
>
>
> 37209883 USW-THQ\ADDC03 64480865 2008-07-11
> 05:50:054600026 fSMORoleOwner
>
>
>
> 4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 systemFlags
>
>
>
> 4445790 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 objectCategory
>
>
>
> 0 entries.
>
>
>
> Type Attribute Last Mod Time Originating
> DC Loc.USN Org.USN Ver
>
>
>
> ======= ============ =============
> ================= ======= ======= ===
>
>
>
> Distinguished Name
>
>
>
> =============================
>
>
>
>
>
> This is from the only domain controller on one of the domains:
>
>
>
>
>
> repadmin running command /showobjmeta against server
> usndc01.usn.ad.contoso.com
>
>
>
>
>
>
>
>
>
>
>
> 11 entries.
>
>
>
> Loc.USN Originating DC Org.USN Org.Time/Date
> Ver Attribute
>
>
>
> ======= =============== ========= =============
> === =========
>
>
>
> 2348 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
> 18:36:23 1 objectClass
>
>
>
> 2348 USN\USNDC01 2348 2003-02-27
> 16:57:27 1 cn
>
>
>
> 2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 instanceType
>
>
>
> 2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 whenCreated
>
>
>
> 2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600000 isDeleted
>
>
>
> 2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 showInAdvancedViewOnly
>
>
>
> 7071630 London\ADDC02 20543389 2004-11-05
> 15:10:554600003 nTSecurityDescriptor
>
>
>
> 2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 name
>
>
>
> 27355595 USW-THQ\ADDC03 64480865 2008-07-11
> 05:50:054600026 fSMORoleOwner
>
>
>
> 2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 systemFlags
>
>
>
> 2348 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 objectCategory
>
>
>
> 0 entries.
>
>
>
> Type Attribute Last Mod Time Originating
> DC Loc.USN Org.USN Ver
>
>
>
> ======= ============ =============
> ================= ======= ======= ===
>
>
>
> Distinguished Name
>
>
>
> =============================
>
>
>
> And this is from the two DCs in the other domain:
>
>
>
>
>
> repadmin running command /showobjmeta against server
> RBLDC02.rbl.ad.contoso.com
>
>
>
>
>
>
>
>
>
>
>
> 11 entries.
>
>
>
> Loc.USN Originating DC Org.USN Org.Time/Date
> Ver Attribute
>
>
>
> ======= =============== ========= =============
> === =========
>
>
>
> 5718 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
> 18:36:23 1 objectClass
>
>
>
> 5718 London\RBLDC02 5718 2006-08-01
> 14:38:05 1 cn
>
>
>
> 5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 instanceType
>
>
>
> 5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 whenCreated
>
>
>
> 5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600000 isDeleted
>
>
>
> 5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 showInAdvancedViewOnly
>
>
>
> 5718 London\ADDC02 20543389 2004-11-05
> 15:10:554600003 nTSecurityDescriptor
>
>
>
> 5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 name
>
>
>
> 2890666 USW-THQ\ADDC03 64480865 2008-07-11
> 05:50:054600026 fSMORoleOwner
>
>
>
> 5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 systemFlags
>
>
>
> 5718 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 objectCategory
>
>
>
> 0 entries.
>
>
>
> Type Attribute Last Mod Time Originating
> DC Loc.USN Org.USN Ver
>
>
>
> ======= ============ =============
> ================= ======= ======= ===
>
>
>
> Distinguished Name
>
>
>
> =============================
>
>
>
>
>
>
>
>
>
> repadmin running command /showobjmeta against server
> rbldc04.rbl.ad.contoso.com
>
>
>
>
>
>
>
>
>
>
>
> 11 entries.
>
>
>
> Loc.USN Originating DC Org.USN Org.Time/Date
> Ver Attribute
>
>
>
> ======= =============== ========= =============
> === =========
>
>
>
> 5661 dcf403c8-799d-4430-80b2-7ce45cf7dc0f 1175 2001-12-11
> 18:36:23 1 objectClass
>
>
>
> 5661 London\RBLDC04 5661 2008-02-27
> 20:52:44 1 cn
>
>
>
> 5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 instanceType
>
>
>
> 5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 whenCreated
>
>
>
> 5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600000 isDeleted
>
>
>
> 5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 showInAdvancedViewOnly
>
>
>
> 5661 London\ADDC02 20543389 2004-11-05
> 15:10:554600003 nTSecurityDescriptor
>
>
>
> 5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 name
>
>
>
> 1756030 USW-THQ\ADDC03 64480865 2008-07-11
> 05:50:054600026 fSMORoleOwner
>
>
>
> 5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 systemFlags
>
>
>
> 5661 90214945-40a6-49a4-950b-9b08998a0d3c 390530 2002-11-21
> 18:21:004600001 objectCategory
>
>