Tuesday, 15 March 2011

AD DS Operation Failed – directory service is missing mandatory configuration – Event ID 2091 – FSMO Role Broken

We went to run a DCPromo on a temporary DC to remove it from a domain and received the following error:


Active Directory Domain Services Installation Wizard

The operation failed because:

Active Directory Domain Services could not transfer the remaining data in directory partition DC=ForestDNSZones,DC=DOMAIN,DC=LOCAL to Active Directory Domain Controller \\SBS.DOMAIN.LOCAL.

“The directory service is missing mandatory configuration information, and is unable to determine the ownership of floating single-master operation roles.

In the temporary DC’s Event Logs we found the following:


Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          3/12/2011 12:29:37 PM
Event ID:      2091
Task Category: Replication
Level:         Warning
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      TempDC.DOMAIN.LOCAL

Ownership of the following FSMO role is set to a server which is deleted or does not exist.
Operations which require contacting a FSMO operation master will fail until this condition is corrected.
FSMO Role: CN=Infrastructure,DC=ForestDnsZones,DC=DOMAIN,DC=LOCAL
FSMO Server DN: CN=NTDS Settings\0ADEL:b3541fc4-50cc-4c12-96be-e5239b314bea,CN=OLD-DC\0ADEL:da50a8ba-dbc7-4219-8d68-ffa03b38c030,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=DOMAIN,DC=LOCAL
User Action:
1. Determine which server should hold the role in question.
2. Configuration view may be out of date. If the server in question has been promoted recently, verify that the Configuration partition has replicated from the new server recently.  If the server in question has been demoted recently and the role transferred, verify that this server has replicated the partition (containing the latest role ownership) lately.
3. Determine whether the role is set properly on the FSMO role holder server. If the role is not set, utilize NTDSUTIL.EXE to transfer or seize the role. This may be done using the steps provided in KB articles 255504 and 324801 on http://support.microsoft.com.
4. Verify that replication of the FSMO partition between the FSMO role holder server and this server is occurring successfully.
The following operations may be impacted:
Schema: You will no longer be able to modify the schema for this forest.
Domain Naming: You will no longer be able to add or remove domains from this forest.
PDC: You will no longer be able to perform primary domain controller operations, such as Group Policy updates and password resets for non-Active Directory Domain Services accounts.
RID: You will not be able to allocation new security identifiers for new user accounts, computer accounts or security groups.
Infrastructure: Cross-domain name references, such as universal group memberships, will not be updated properly if their target object is moved or renamed.

The referenced OLD-DC was an original Windows Server from eight years ago!

Long story short, make sure to open ADSIEdit _on the affected FSMO Role owner_ and make the necessary changes there. When we tried to change the required settings on TempDC we kept getting errors.

  1. Obtain the correct setting:
    1. On the affected role owner open ADSIEdit.
    2. Click on Default Naming Context [SBS.Domain.Local].
    3. Click on DC=Domain,DC=Local.
    4. Double click on CN=Infrastructure at the bottom of the list of folders.
    5. Locate the fSMORoleOwner attribute and click on it.
    6. Click the Edit button.
    7. CTRL+C to copy the contents of the attribute.
    8. Click CANCEL twice.
  2. Correct the problematic settings:
    1. Right click the ADSI Edit root and click on Connect to…
    2. Use the following connection point:
      1. DC=DomainDNSZones,DC=Domain,DC=Local
      2. image
    3. Click on Default Naming Context [SBS.Domain.Local] to populate it.
    4. Click on DC=DomainDNSZones,DC=Domain,DC=Local folder.
    5. Double click on CN=Infrastructure.
    6. Locate the fSMORoleOwner attribute and click on it.
    7. Click the Edit button.
    8. CTRL+V to paste the correct setting.
    9. Click OK and then Apply.
    10. Repeat steps 2.1-2.9 to correct DC=ForestDNSZones,DC=Domain,DC=Local.

Once the above steps were completed on the FSMO Role owner for Infrastructure we were able to properly demote the temporary DC.


The error we kept receiving when trying to edit the FSMO Role owner setting on TempDC was the following:



Operation failed. Error code: 0x20ae
The role owner attribute could not be read.

000020AE: SvcErr: DSID-03152965, problem 5003 (WILL_NOT_PERFORM), data 0

The above message took a while to decipher that we were being told to move our FSMO editing operations over to the Role Owner!

Further Reading

Philip Elder
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer


Anonymous said...

Thanks Bro, saved me

Anonymous said...

Thanks, from me as well, saved my butt too!!! Great post!

Lars said...

Thanks, the post saved my Day (or better Night)

Anonymous said...

Thanks bro, you save my life!

20thCenturyBoy said...

Fantastic article, got hit by this at 10:30pm, my heart was sinking. Why don't MS publish this?

NotJustOshin said...

Thanks alot, been looking out for a solution to this problem for a while now, glad i came across your blog.
you made my day

Stanislav said...


Dustbin said...

Brilliant, worked first time!

Anonymous said...

Thanks great post and save my day too :)

Anonymous said...

Great post, your resolution worked like a charm and will help in future DC removals. Much better than what other users recommend a force removal!

Unknown said...

I'm not sure I understand how to resolve the error when editing the fSMORoleOwner parameter with ADSIEDIT.

"Operation failed. Error code: 0x20ae
The role owner attribute could not be read."

Can anyone shed some light on it?


Chris Cadge said...

Thanks very much - solved my issue. Very clear instructions.


wRx7M said...

Thanks for this post. Totally solved my problem. Note - I did have to replace the generic DC=Domain with DC=myactualdomain in order to get it to connect properly in ADSI edit.
Most probably know this but just in case... Thanks again!

wRx7M said...

Thanks for this post. Totally solved my problem. Note - I did have to replace the generic DC=Domain with DC=myactualdomain in order to get it to connect properly in ADSI edit.
Most probably know this but just in case... Thanks again!

Anonymous said...

Hi, i have the exact same issue.
I have tried to follow your document and i get to the point that when i try to edit the FSMO Role owner setting on the DC i get the error" Operation failed. Error code: 0x20ae
The role owner attribute could not be read.

000020AE: SvcErr: DSID-03152965, problem 5003 (WILL_NOT_PERFORM), data 0"
How can i edit this?
I went through your links below that and i still don't know how did you manage to edit it.
Can you help?

James said...

Hi. Thanks for the post. Ran into the same problem this week and this helped fix it.

Anonymous said...

Hey, same here thanks for writing this up. Helped me just now as well.

Anonymous said...


Anonymous said...

Thanks - saved me too

Mark M said...


Monkeybutler said...

Thank you!!!

Jeremy said...

Thanks for the link and the clarifying NOTE that made me re-read the article more carefully.

Ben said...

Thanks a lot for this worked first time much appreciated.

Anonymous said...

Thanks!! You save my night!!

Rubarb said...

Saved us. Thank you!

Used ntdsutil to get Infrastructure master value. Used that for value in forest and domain fSMORoleOwner. You should submit a request to have this published to the MSKB.

Anonymous said...

Can't tell you how many untold hours you saved me with this post. If I had a first born son I'd name him after you. Thanks a million!

Jjong said...

I was following a SWING migration and this is the part where i have to decommission the tempdc. the error occured, but i couldn't get to carry out the steps outlined above because i was working on the wrong server.

i think the steps above is applicable on the tempdc, but with the error appearing everytime i click 'apply' i found out the problem is that i have to apply the changes on the main server.

took me about 30min to read through the posts and figure out what's wrong.

after making the change on the main DC, in ForestDNSZones and DomainDNSZones, the problem was resolved. I can decommission the TempDC.

Sorb said...

I had this problem but this did not help unfortunately. The solution in my case was to follow the steps under "Transfer FSMO roles" here:


Anonymous said...

worked for me too as of march 2014. Would be nice to know why this happens. I assume a customer removed a DC improperly, seized the FSMO role for Infrastructure and this issues was silent until now. Any Ideas?

Anonymous said...

Thank you!!!

Anonymous said...

Awesome!! Saved my day..

nExoR said...

helped. thx! (:

Unknown said...

well illustrated, it saved teh day.

Unknown said...

well illustrated, it saved the day.

Anonymous said...

Thanks!!! I really appreciate this and I'm shocked (not really) this isn't a M$ KB.

Unknown said...

I just wanted to add on this date I follow the instructions to the letter and after forcing a replication was able to decommission and DC and remove a subdomain from the forest. ~thank you

Anonymous said...

Awesome post...thank you so much. Just used this to cleanly demote an old Win2003 DC after installing a new Win2012 DC! The FSMO owner in the ForestDNSZones turned out to be the culprit. Saved me a ton of time for sure!

Anonymous said...

Thanks for this awesome detailed documentation. I've used this at two different customer environments now and it has saved me hours of frustration. Nice work and good job giving credit where credit is due.

Henry Overton said...

Thank you! This was really helpful!

Henry Overton said...

Thank you, this was very helpful!

R. Sellis said...

Thanks, it was very helpful!

Unknown said...

It works for me too, thank you very much.

Anonymous said...

Still saving butts in late March 2016, thanks for this!!

Anonymous said...

Just keeps giving. Great post, saved days of work. Thank you!

Anonymous said...

April 2016 - Just saved me a few hours! Nice

Anonymous said...

ThathathathaNK You!!!

Netexpertise said...

Thanks, very helpful!

Anonymous said...

Great article
If you get the error message that the holder can't be read run the Microsoft script and so its set resets the 0ael to the local server name AND THEN copy and paste to all the effected zones

Anonymous said...

Satish Y (India)

Awesome!! You Saved my day...

Andrews said...

Thank you! Saved me a few hours!

Tim Metcalf said...

Excellent step by step - Understood it perfectly
Worked Instantly

Unknown said...

Great Post!! It worked like a charm. Thanks so much!!

Anonymous said...

great help, thanks

N8B said...

Great help, was banging me head against a wall until I followed this post. Thanks!

Anonymous said...

Helped me as well. Thanks!

raj said...

Thanks. It helped.

Anonymous said...

Worked for me as well! Note that it did not take effect immediately, had to wait about 15 minutes before the affected DC was able to demote itself.

Anonymous said...

Thanks !!!

Anonymous said...

Hugely helpful in solving my problem, I can finally get on with my life again :)

Philip Elder Cluster MVP said...

Glad to help folks. :O)

Unknown said...

Life saver, thanks again!

John said...

Man was really banging on this one, worked like a charm. Thanks!

Anonymous said...

Best guide on this subject by a long shot.
Really nicely done.
Thank you so much.

Anonymous said...

Very useful info. Thanks you

Anonymous said...

Very helpful. This information is around but very cryptic. Your post is excellent.