Failure during demotion of domain controller

/, Guides, Technical, Work/Failure during demotion of domain controller

Failure during demotion of domain controller


During the demotion of a domain controller, when we run dcpromo to start the process we quickly encountered an error “The directory service is missing mandatory configuration information, and is unable to determine the ownership of floating single-master operation roles.” which interrupts the demotion process.

Further Diagnosis:

This occurred for us on some Windows Server 2008 R2 servers as we were in the lengthy progress of upgrading Active Directory from 2003 and 2008 R2 to 2012 R2 now Novell eDirectory is phased out.

So far, the error message implies an issue with with operational masters or flexible single master operation (FSMO) which is two names for the same thing. Confusingly the F in FSMO is also sometimes called floating rather than flexible and in much documentation for Server 2008 onward you see just operational masters used instead as that is the official name now.

In command prompt or PowerShell, the command netdom query fsmo says the operational masters are where they should be so its not immediately clear where the issue lies. However the event log shows an error and warning and in the detail of those logs there was mention of the Infrastructure Master through the mention of “Dn: CN=Infrastructure,DC=DomainDnsZones,DC=domain,DC=ac,DC=uk” in the logs.

At this point, to verify that something is wrong with the location of the Infrastructure Master we look at the records held in Active Directory using ADSIEdit to check that the location of the Infrastructure Master in the fSMORoleOwner attributes is correct. You need to do this from the domain controller that has the Infrastructure Master role.

  1. Launch ADSI Edit (search for ASDIEdit).
  2. Right click on the ADSI Edit in the side bar and choose Connect to…
  3. Change connection point to CN=Configuration,DC=domain,DC=ac,DC=uk
  4. Leave Computer as Default if your currently logged into the Domain Controller with Infrastructure Master role, else change this as needed.
  5. Click Okay.

This should add a new section in the side bar. You should now also add additional connections for connection points below.

  • DC=ForestDnsZones,DC=domain,DC=ac,DC=uk
  • DC=DomainDnsZones,DC=domain,DC=ac,DC=uk

Looking at the properties of CN=Infrastructure within both DC=ForestDnsZones and DC=DomainDnsZones shows an attribute called fSMORoleOwner which contains incorrect information referencing a server that no longer exists along with random numbers and letters when it should be fairly clean and readable.


To get the exact string of text for the two fSMORoleOwner attributes in DC=ForestDnsZones and DC=DomainDnsZones, you can look at an attribute in CN=Configuration we added first. The attribute is called distinguishedName in the properties of CN=NTDS Settings of the domain controller from the other connection point added first called CN=Configuration,DC=domain,DC=ac,DC=uk. See screenshot for where this is… (Click to enlarge.)


Copy the string of text in this field and paste it into the fSMORoleOwner mentioned earlier in DC=ForestDnsZones,DC=domain,DC=ac,DC=uk and DC=DomainDnsZones,DC=domain,DC=ac,DC=uk which should then resolve the problem. Shown in below screenshots… (Click to enlarge.)

After making a correction to the two attributes that were wrong, when we next ran dcpromo to demote a domain controller everyone worked as expected. I don’t know the route cause of the issue but since correcting it, it has not occurred again.

By |2017-01-06T16:01:00+00:00January 28th, 2015|Categories: Blog, Guides, Technical, Work|Tags: , , , , , , |1 Comment

About the Author:

Ross Stone is an experienced and passionate IT Professional with exceptional knowledge of various technologies including Active Directory, Application Virtualization, System Centre Configuration Manager, Citrix XenApp and VMware vSphere.

One Comment

  1. Phil 28/01/2015 at 22:38

    I don’t know for sure, but I suspect this is caused by AD not cleaning up after itself when you’ve removed the DC that was incorrectly marked as owning one of the FSMO roles.

    Obviously you should always demote a DC before it is decomissioned but I’ve also found it good practice after demotion to go into ActiveDirectory Sites and Services/NTDS Settings and go through the NTDS settings for the remaining DCs and ensure the demoted DC is no longer listed as a replication partner (either source or destination). Also remove the orphaned entry from the DC list if it is there.

    While dcpromo is supposed to take care of this during demotion it doesn’t always do it properly and aside from the obvious replication errors it can cause I wonder if it may also allow for FSMO roles to be assigned to the server even though it isn’t there.

Leave A Comment