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:


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_TYPE_1779 = 1
const ADS_NAME_TYPE_CANONICAL = 2set inArgs = WScript.Arguments

if (inArgs.Count = 1) then
‘ Assume the command line argument is the NDNC (in DN form) to use.
NdncDN = inArgs(0)
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

‘ 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.


Perfmon Blackbox… more better :)

During a recent workshop in southern California I promised my students that I would update an old blog of mine that referenced how to create a blackbox perfmon data collector set. In the instructions I mentioned that the best way to get one of these running and keep it running all the time was to create a startup script. I have since found a better way. I credit my colleague Martin Vokurek with figuring out this neat little trick.

So, first you will want to create the blackbox data collector set and you can see how to do that in my original blog HERE. Afterword, you come back to this post and follow these easy steps.

Number 1… go to the computer management (Start –> right-click Computer –> click Manage)


Number 2… browse down to the “PLA” section of your Task Library (Server Manager –> Configuration –> Task Scheduler –> Task Scheduler Library –> Microsoft –> Windows –> PLA)


Number 3… in this list you’ll see your data collector set and if you don’t you need to enable the hidden tasks (view -> show hidden tasks)

Number 4… double click your data collector set to open its properties

Number 5… go to the triggers tab

Number 6… click on new and add “At Startup”


That’s it. You should now see the blackbox data collector set restart each and every time the system starts.


I also want to use this time to point out a strange behavior that’s been noticed. And it has to do with how perfmon interprets “append” and “circular logging” (or bincirc with is the binary circular logging format).

You basically have two choices, and it really comes down to that double dash in the –v (once again see HERE). With this on, perfmon will use the same filename (thus an actual blackbox) each time it restarts. Turn off the dash dash v and you’ll see it actually create a new file each time it restarts.

There are upsides and downsides to both approaches. If you WANT perfmon to always use the same file (and not risk ever accidentally consuming all the space on your drive with a bunch of 500mb log files) you’ll want to go with the –v option. The downside to this approach is that perfmon will clear out the log file and start fresh with a zero byte log. Meaning if your server reboots you’ll not have any perf data from the previous session.

If you want to keep the file just don’t use the v option. And keep an eye on that disk space. Because what will happen is perfmon will simply create a new blackbox after each restart so you can go back through the previous blg file.