This came up recently at a customer site. I was looking for the script that fixes this (remembering that the site the fix belongs to is attached to an article that has nothing to do with the issue, but it still works great).
What I ran into was a TON of really horrible advice out there on the forums. Please please please – if you get this error don’t follow any of the advice you read unless the article mentions running a script that is lovingly called “fixfsmo.vbs”
What you’re probably seeing in LDP or ADSIEdit in the CN=infrastructure,DC=DomainDNSZones,DC=MyDomainName,DC=Whatever (that or ForestDNSZones) is an entry for FSMO that points to a retired or missing DC. Sorta’ like this:
What has happened is the DC who held the FSMO Role Holder for your DomainDNSZones or your ForestDNSZones (or both) application partition isn’t there anymore. Someone deleted it, decommissioned it, basically it failed somewhere along the line but the DC owned one or more of your AD Integrated DNS Zones. The deleted DC can be seen in the mess above after cn=___ and in most cases this means someone had to do metadata cleanup and forcibly removed the server from AD.
So you might be asking, “uh, Chris? Aren’t there just 5 FSMO role holders?” Well, see for yourself:
Without getting into a huge discussion about naming contexts or application partitions – just know that if your domain uses application partitions (likely) each of these will have a FSMO. Like your other FSMO role holders you may need to seize the role. Sadly, you can’t do this with NTDSUTIL. You can SEE them (see below) but you can’t do anything with them:
In the list of options above, note that there isn’t a Seize or Transfer option for the application partitions. You can select them or view them:
But that’s it. There is a way to change the owner when you’re in this state however, keep reading.
So again, without going into a lot of depth on naming contexts and Application Partitions (I actually have another post that deals with this which will be published early next month dealing with DNS and App Partitions) we will move on for now. The bottom line is, you have a partition in your Active Directory database with no owner. We need to fix this, and we can’t use NTDSUTIL to get there.
The NORMAL way to go about changing FSMO role holders for the applications partitions is to use an editor like ADSIEdit or LDP. As shown in the first image above, you see that this region is editable. BUT as you’ve probably already noticed, this will error out “The role owner attribute could not be read” because there’s nobody to talk to (the value owner is gone).
So you need to force this change to happen. This is described in KB949257, unfortunately this article’s title is talking about issues doing an adprep /rodcprep – and a lot of people miss it or skip over it when in actuality it has exactly the script you need.
What you need to do is go to the DC you want to hold the role (I usually use the PDCE, but not for any particular reason). Now create a new file and call it fixfsmo.vbs:
Then dump this text into it:
|const ADS_NAME_INITTYPE_GC = 3
const ADS_NAME_TYPE_1779 = 1
const ADS_NAME_TYPE_CANONICAL = 2set inArgs = WScript.Arguments
if (inArgs.Count = 1) then
if (NdncDN <> “”) then
‘ Convert the DN form of the NDNC into DNS dotted form.
Wscript.Echo “DNS name: ” & strDomainDNS
‘ Find a domain controller that hosts this NDNC and that is online.
‘ Get the current infrastructure fsmo.
‘ If the current fsmo holder is deleted, set the fsmo holder to this domain controller.
if (InStr(objInfra.fsmoroleowner, “\0ADEL:”) > 0) then
‘ Set the fsmo holder to this domain controller.
‘ Read the fsmo holder back.
And run the script from an elevated command prompt. You should now be able (through NTDSUTIL as shown above or through ADSIEdit) be able to see that the owner has changed to a valid DC.
For clarification, you should only run this script if the DC that is listed is no longer available and you can’t change it manually through ADSIEdit.