Got some errors when I tried to run adprep /rodcprep stating that the adprep could not contact a replica for the NDNC DomainDNSZones and ForestDNSZones.
Adprep could not contact a replica for partition DC=DomainDnsZones,DC=corp,DC=secid,DC=se
Adprep failed the operation on partition DC=DomainDnsZones,DC=corp,DC=secid,DC=se Skipping to next partition.
Adprep failed the operation on partition DC=ForestDnsZones,DC=corp,DC=secid,DC=se Skipping to next partition.
Adprep completed with errors. Not all partitions are updated.
In my case it was because a Domain Controller recently had crashed and they were forced to do a metadata cleanup and seize the FSMO roles to a new DC.
Some background information:
In Active Directory there are 5 known FSMO role holders, two forest wide and 3 domain wide.
- Domain Naming Master – Forest wide
- Schema Master – Forest wide
- PDC Emulator – Domain wide
- Infrastructure Master – Domain wide
- RID Master – Domain wide
So, why do I mention there are 5 known role holders? It’s because in Windows 2003 Server Application Partitions was introduced in Active Directory.
Application Directory Partitions:
In the Active Directory database there are 3 directory partitions also known as Naming Contexts (NCs). The Application Directory Partitions also known as Non-Domain Naming Contexts (NDNCs) was introduced in Windows 2003 Server.
In short the characteristics of NDNCs is that is can store any type of objects except Security Principals. The replication partner can be configured to specified DCs in the whole forest, it is not a requirement that all DCs in a domain host that replica. It also supports Dynamic Objects that can have a Time To Live (TTL) value.
There are two default NDNCs that’s created on 2003 DCs and newer.
It’s where the Active Directory DNS Zones are stored default when you create a new domain on Windows 2003 Servers and newer, if you have upgraded from a 2000 Domain you would have to change it.
You can see in the dnsmgmt snap-in that the _msdcs.corp.secid.se is default stored in ForestDNSZone and is replicated to all DCs in the AD forest.
And if we look in the properties in the domain corp.secid.se it is stored in the DomainDNSZones partition and replicate to all DCs in its local AD domain.
There are tons of more I could write about this subject and other tools that can be used. But now we will go back and focus a little more about the adprep problem.
(If you want to know more about storing the DNS and NDNCs you could check out this great blog: http://blogs.chrisse.se/2011/04/10/are-you-storing-your-ad-integrated-dns-zones-in-the-dns-application-partitions-ncs/)
So what does all this mean, well in the Application Partitions that is created you also have the Infrastructure Master Object which in this case is a pointer to a DC.
If we run ADSI Edit and connect to the DC=ForestDNSZones,DC=corp,DC=secid,DC=se Naming Context we can take a look.
Browse to the Infrastructure Object and open its properties:
Here you will see which DC is in the fSMORoleOwner attribute, you will have a value like this: Settings,CN=2K3DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=secid,DC=se
In my case with the adprep error the DC which was FSMO Role Owner of that NDNC Infrastructure Master no longer existed in their domain. The problem with this is that you cant use NTDSUTIL or any other tool that I know of to seize this role. But luckily Microsoft has a published KB article with a script that will fix this:
Follow the guide and run the fixfsmo.vbs script and you will be able to rerun your adprep /rodcprep. One other thing to keep in mind is that this script can save you in other situations like when your demoting a DC similar errors can occur and by running the script is the best way to solve these kinds of problems. Don’t forget to verify that it’s actually the FSMO Role Owner problem your facing.