Cannot edit NETDOM Query FSMO Task in relation to "Could not determine the FSMO role holder" alert RRS feed

  • Question

  • Hi,

    We have the "Could not determine the FSMO role holder" alert frequently occuring and from reading the forums, one of the fixes appears to be to alter the NETDOM Query FSMO Task to change the support tools location to %windir%\system32 however when I go to Authoring, select the NETDOM Query FSMO task and select properties, I can view the xml configuration and see the original support tools location of %programfiles%\support tools but I cannot seem to edit this.

    Is this the correct way to change the task or am I doing something incorrectly?



    Thursday, April 22, 2010 8:04 AM


  • Hi, No activity for 30 days. Will mark as answer. Feel free to re-open. Thanks

    Anders Bengtsson | Microsoft PFE | blog at http://www.contoso.se
    Sunday, December 26, 2010 7:48 PM

All replies

  • Hi,


    Firstly, please check the network connectivity of the servers.


    To validate FSMO role holder, you can also try the following methods:


    How to view and transfer FSMO roles in Windows Server 2003



    Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller



    In addition, please also provide more information, such as the operating system version of the Windows servers. If you find some related errors in Event Log, please also let us know the details.



    Nicholas Li - MSFT
    Monday, April 26, 2010 7:12 AM
  • Hi Nicholas, Sorry, the FSMO roles are actually fine on the domain controllers, I can view them in ntdsutil on all the DCs and the roles are on the correct servers and there aren't any errors being generated on the domain controllers themselves. It just seems to be SCOM that thinks there is an issue. From some reading online it would appear that in some cases, the path to run the script is incorrect and needs amended as per my first post, however when I try and amend the path in the script, I can view the current path but cannot edit it as its greyed out. Does that make more sense?
    Monday, April 26, 2010 9:19 AM
  • Make a symbolic link to  %windir%\system32  from %programfiles%\support tools (I did this on Windows 2008 R2).


    Monday, May 24, 2010 11:15 AM

    I just fixed this type of error and you may have the same issue, so I would take a look at this the link below. I used the vb script. Make sure you add a single quote to the first line inside the script " '------" or the vbs will fail compilation. You can also change it via adsiedit. I looked at the location before and after the change.


    SCOM dumps an error but it jsut means it found some old junk. It appears not to matter if you are using AD Integrated zones.

    I ran the script on the current FSMO role holder. Afterwords I was used adsitedit.msc to see what it changed. In my case an old DC was still stuck in the the DC=DomainDnsZones,DC=####,DC=local .


    Thursday, May 27, 2010 7:45 PM
  • Hi Jonathan,

    According a comment to this blog post (http://blogs.msdn.com/b/jakuboleksy/archive/2006/12/06/overrides-in-scom-2007.aspx), task overrides cannot be made global:

    "Task overrides are not "global". They only apply to a single run of the task. Essentially, you can't change the task configuration for a sealed task across the board, but rather for a single run of the task only."

    So effectively, when running the task from the actions, you can modify the location there for that instance only, and it won't stick for the next time you run it.  However, you also can't modify it at all in the authoring panel and thereby prevent the warning alert that pops up.  Presumably, part of this is because it's a sealed management pack.  

    I came across the same issue recently.




    Thursday, November 4, 2010 11:42 AM
  • Hi, No activity for 30 days. Will mark as answer. Feel free to re-open. Thanks

    Anders Bengtsson | Microsoft PFE | blog at http://www.contoso.se
    Sunday, December 26, 2010 7:48 PM