ForestDNSZones or DomainDNSZones FSMO says “The role owner attribute could not be read”

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:

cn=ntds settings\0adel:f655f307-02gb-4923-b7be-fc5e2042b4c8,cn={MyOldDCName}\0adel:88c9073f-6964-4ab3-98f0-d30dcd12a908,cn=servers,cn={SiteName},cn=sites,cn=configuration,dc={MyDomainName},dc={Whatever}

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:

image

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:

image

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:

image

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:

image

Then dump this text into it:

const ADS_NAME_INITTYPE_GC = 3 const ADS_NAME_TYPE_1779 = 1 const ADS_NAME_TYPE_CANONICAL = 2

set inArgs = WScript.Arguments

if (inArgs.Count = 1) then     ' Assume the command line argument is the NDNC (in DN form) to use.     NdncDN = inArgs(0) Else     Wscript.StdOut.Write "usage: cscript fixfsmo.vbs NdncDN" End if

if (NdncDN <> "") then

    ' Convert the DN form of the NDNC into DNS dotted form.     Set objTranslator = CreateObject("NameTranslate")     objTranslator.Init ADS_NAME_INITTYPE_GC, ""     objTranslator.Set ADS_NAME_TYPE_1779, NdncDN     strDomainDNS = objTranslator.Get(ADS_NAME_TYPE_CANONICAL)     strDomainDNS = Left(strDomainDNS, len(strDomainDNS)-1)          Wscript.Echo "DNS name: " & strDomainDNS

    ' Find a domain controller that hosts this NDNC and that is online.     set objRootDSE = GetObject("LDAP://" & strDomainDNS & "/RootDSE")     strDnsHostName = objRootDSE.Get("dnsHostName")     strDsServiceName = objRootDSE.Get("dsServiceName")     Wscript.Echo "Using DC " & strDnsHostName

    ' Get the current infrastructure fsmo.     strInfraDN = "CN=Infrastructure," & NdncDN     set objInfra = GetObject("LDAP://" & strInfraDN)     Wscript.Echo "infra fsmo is " & objInfra.fsmoroleowner

    ' 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.         objInfra.Put "fSMORoleOwner",  strDsServiceName         objInfra.SetInfo

        ' Read the fsmo holder back.         set objInfra = GetObject("LDAP://" & strInfraDN)         Wscript.Echo "infra fsmo changed to:" & objInfra.fsmoroleowner

    End if

End if

 

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.

HTH!