| Author | Messages | |
dkkazak
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
| | | |
| dwells
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
| | | |
| matheesha
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
| | | |
| dkkazak
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
| | | |
| ali
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 > > >
| | | |
| dwells
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
| | | |
| dwells
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
| | | |
| dkkazak
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
| | | |
| dkkazak
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
| | | |
| dwells
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
| | | |
| ali
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 > > |
|
|