fSMORoleOwner on the Domain/Forest DNS Application Partition

  • 631 Views
  • Last Post 4 weeks ago
pbbergs posted this 25 June 2014

So I ran across a thread in another forum discussing the attribute fSMORoleOwner on the container CN=Infrastructure,DC=DomainDnsZones,DC=domain,DC=com.  I wasn't familiar with this attribute and decided to try and review it within my own enterprise and the first two domains I looked at I found both the domain and forest dns containers (I think these are the root partitions) are pointing to invalid fsmo holders (In reference to the standard five).  The domain and forest in one domain points to an old retired DC and the other pair point to a DC that is up and available but I don't know if it is correct since it holds none of the five standard.
 
I found a good Blog on this but not sure if it is accurate, I think it is good but wanted to get feedback from others.
http://support.microsoft.com/kb/949257/en-us  (This pertains to an RODC issue but it should be all encompassing and the following link concurs as well)
http://blogs.technet.com/b/the9zbychrisdavis/archive/2011/12/20/forestdnszones-or-domaindnszones-fsmo-says-the-role-owner-attribute-could-not-be-read.aspx
 
First Question, it almost sounds like there are more FSMO roles when it comes to an application partition, does anyone know if that is true?  I don't get why I would have a valid application partition that has never had its roles seized pointing to a DC that doesn't hold any of the five defined fsmo roles.
 
Second Question, This sure seems like a step missing in a defined metadata cleanup.  The newly automated process might handle this I don't know, does anyone know about this possibility?
 
 
Thx
Paul

Order By: Standard | Newest | Votes
chriss3 posted this 25 June 2014

fSMORoleOnwer for NDNCs is NOT used except in scenarios with adprep etc, there are NO IMs for NDNCs – and that is because the following cross NC references limitations are implemented:
A reference can be made between two objects that reside in different naming contexts (this is regardless if the reference is simple or linked) with the following restrictions:

  1. Objects in none domain naming contexts (NDNCs) – can have the following references:
    1. To any object within the configuration naming context (NC).
    2. To any object within the schema naming context (NC).
    3. The naming context head of any none domain naming context (NDNC).
    4. Any object within their own domain naming context (NDC)
All other references than a, b, c and d is disallowed.
  1. Objects in a domain naming context, schema naming context, configuration naming context – can have the following references:
    1. To any objects within any other domain naming context (NC) within the forest.
    2. To any object within the schema naming context (NC).
    3. To any object within the configuration (NC).
    4. To any none domain naming context (NDNC) head.
All other references than a, b, c and d is disallowed except values of non-replicated linked attributes, that can reference any object/row present in the local database (NTDS.dit) at a given DSA.  You can read more at: http://blogs.chrisse.se/2012/11/28/how-the-active-directory-data-store-really-works-inside-ntds.dit-part-4/  Enfo ZipperChristoffer Andersson – Principal Advisor

show

daemonr00t posted this 25 June 2014

Yep, seen that.. a domain with multiple Infra Masters.

 

Check this



http://msmvps.com/blogs/ulfbsimonweidner/archive/2008/07/31/how-many-infrastructure-masters-do-you-have.aspx



 

About your second question I haven’t faced that yet but if I do I’ll let you know.

What I notice is that Exchange’s directory preparation catches that and stops until you fix it.

 

~d

 

show

ThomasVuylsteke posted this 26 June 2014

We had an AD RAP recently and this point also came up. Somewhere in the past we had 4 DC’s (out of 8) that were wiped out and one contained the FSMO roles. Upon metadatacleanup / seizing the DNS NC’s had the old DC referenced. The MS PFE stated that this is not really critical but we fixed it obviously. 

show

ZJORZ posted this 26 June 2014

and the way to fix it is to edit the attribute and specify the DN of the NTDS Settings object representing the DC that is currenty hosting the NC (when multiple, choose one)
Met vriendelijke groeten / Kind regards,
 
Jorge de Almeida Pinto
E-mail: JorgeDeAlmeidaPinto@xxxxxxxxxxxxxxxx
Mobile: +31 (0)6 26.26.62.80

show

pbbergs posted this 26 June 2014

Obviously school was in session for me on this one.
 
Thanks for all the info on this issue.
Paul 
 

show

Close