Getting and keeping the SCOM agent on a Domain Controller – how do YOU do it?

<!--[if lt IE 9]>


Comments (20)
  1. Anonymous says:

    Hi Kevin,

    In my opinion we only need a domain policy, 'Allow logon locally'. Then the issue is solved and now domain admin rights needed.

    Kind regards,

    André Borgeld

  2. Kevin Holman says:

    Have you tried a manual install?  Does the agent install then, and come into pending actions, or does it throw an error?

    Only things I could think of are a firewall/AV product blocking this execution, or not having enough rights.

    The agent should be installed as local system default agent action account, but the domain account specified to run the discovery and agent push should be a domain admin account, for domain controllers.

  3. Kevin Holman says:

    @Brumsky –

    Never heard of that issue.

  4. Kevin Holman says:

    @Sam – I dont have any details – it was just a plausible idea.  🙂

  5. Martin Z Pedersen. says:

    Hello Kevin.

    I’m having big trouble deploying mom 2007 agents, on my domain controllers.

    No matter what account i use to install the agent, i get the same error.

    The MOM Server could not execute WMI Query "Select * from Win32_OperatingSystem" on computer

    Operation: Agent Install

    Install account: AODOMAINAdministrator

    Error Code: 80041003

    Error Description: IDispatch error #3587

    I tried the domain administrator, local system & our service admin. (Service admin is our Management Server Action Account).

    This is only a problem on Windows 2003 DC’s

    Windows 2008 DC’s work fine with Domain admin.

    Any idea what could be the problem ?

  6. Martin Z Pedersen says:

    Yes i tried manual installation. But there is still some sort of validation problem. Now i get alot of these "Object enumeration failed" errors. Here are 2 of them.

    Object enumeration failed

    Query: ‘SELECT NumberOfProcessors FROM Win32_ComputerSystem WHERE DomainRole >3’

    HRESULT: 0x80041003

    Details: Access denied

    One or more workflows were affected by this.  

    Workflow name: Microsoft.SystemCenter.DiscoverWindowsServerDCComputer

    Object enumeration failed

    Query: ‘SELECT * FROM Win32_Service WHERE Name="ClusSvc" and State="Running"’

    HRESULT: 0x80041003

    Details: Access denied

    One or more workflows were affected by this.  

    Workflow name: Microsoft.Windows.Cluster.Service.Discovery

    The action account i’m using is a domain administrator. Any idea ?

  7. Ron Hagerman says:

    I am looking at maybe a web front end that allows a domain admin to enter their credentials to deploy an agent. I got it to deploy an agent so far but the agent never comes out of pending.

    That’s just me though

  8. la_bruin says:

    Although this is unlikely to solve all the issues described here, it looks like enabling Automatic Updates is part of the story.

  9. sam says:

    Kevin – We are planning to use the option 7 in our environment.  Can you please give us more details on the part b?


  10. Bumsky says:

    Hi Kevin,

    is there a known issue where SCOM causes a domain controller lockup? the DC is not monitored and there is no agent installed. We tried pushing the agent from the RMS to the DC but we never were successful in doing it.

    Anybody outhere had the same issue?

    Thanks for the help!


  11. wally says:

    Make sure your Domain Admin account has "Log on Locally" rights or you will not be able to install the Agent! We have several Domain Admin rights which do not have this permission and the installation will fail: "Access is denied".

  12. Newby SCOM (2012R2) guy here. Today I attempted to deploy/install the agent to a couple of 2012r2 servers and got the typical display with three possible reasons why it did not work. I used the default “Use Selected Management Server Action Account” option. When that did not work I went back and used my admin-accountname account and it was successful. How can I know if the Management Server Action Account” has sufficient rights/was setup correctly in SCOM? I have inherited the current setup and trying to work my way through it…Also attempted to have a Domain Admin (with DA Account) do the same for three of our DC’s but it failed the same way…
    Thanks for any advise, assistance!

    1. Kevin Holman says:

      Tony – in MOST correctly configured environments, the SCOM management server action account will NOT have rights on agents, and we would always expect someone to input credentials to push agents. Once an agent is pushed, the management server action account does not need any rights to the agent managed machine. This defaults to the MSAA only for convenience, if customers wanted to grant rights to the MSAA to be able to manage agent push installs, updates, etc. I’d call that a non-issue.

      1. Afternoon and thanks for the response Kevin! I can breath a little easier now. So I can focus on figuring out if the firewall rules/ports I have requested open have been done correctly. Could I impose with another question for this: I have requested Ports to open on all subnets where servers reside that we will monitor: bi-directional-5723,5724,135-139,445,ping,icmp//to be able to deploy, install, repair, update via the scom console….would that be sufficient or am I missing any?
        Thank you again for your time!

  13. Kitaab says:

    I am using SCOm 2016 COnsole Discovery wizard to install agents , I have admin rights and use my account in Administrator account to discover and then push the agent s . I was able to do this for all our servers .

    Now that all servers were done i started the discovery wizard and choose the domain controllers , this time i used my domain admin account as the Administrator account , however it is not able to discover the DC’s

    Yes, i am using teh domain admin account and i can login to the DC’s with that account interactively

    What am i missing – any idea
    Thank you Kevin 🙂

  14. Bijesh NS says:

    Hi Kevin,

    In our environment the Management Server Account is member of Domain Admin Group in AD. The same account we used in SCOM 2007 R2 Infrastructure and when the environment migrated to SCOM 2012 R2 we used the same account with same level of permission. As per your above statement Management server action account need to have Domain Admin rights only if we need to push the agent to the DC servers using SCOM console. Can we remove the Domain Admin rights for the Management Server action account now? if yes then is there any challenge we face post the Domain Admin access removal?.

    Note – This account will remain have Local Administrator rights on all managed agents.


    1. Bijesh NS says:

      Hi Kevin,

      it will be great if you can help me on my query posted below


    2. Kevin Holman says:

      There is NO requirement for Domain Admin rights in SCOM. Management Server Action account should not have domain admin rights generally.

      It should be safe to remove Domain Admin group membership from your Management Server Action account. However, I cannot tell you for certain because it will depends on custom workflows you have written, database configurations and security settings, etc. The best way to tell, is to remove it and see what happens by watching the event logs. If you have other security misconfigurations, there might be some impact on the way to cleaning it up.

      1. Bijesh NS says:

        Hi Kevin,

        Thanks for your valuable feedback.


Comments are closed.

Skip to main content