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

I’d like to hear some community feedback on this….


In OpsMgr – deploying a SCOM agent to a DC often presents companies with a bit of a challenge.  The reason is – in order to install software to a DC and manage it – we need rights on the DC to accomplish this.  These rights are needed, anytime we are going to deploy an agent, hotfix an agent, or run a repair on a broken agent to keep the agent healthy.

When we push agents from the console, the default account used to perform the push is the Management Server Action Account.  If this account does not have Domain Admin rights – the push will fail to a DC, with an Access Denied.  We do allow the option to type in temporary (encrypted) credentials, which are used to deploy the agent, one time, and then are discarded.  See the image below:



Here is a list of the most common options I have observed, in place at customer sites… and potential custom options that can be developed.  I’d be interested in any community feedback on any options you are using, that I dont cover or haven’t seen before.



1. Grant the Management Server Action account Domain Admin or Builtin\Administrators.

a. Not recommended as a best practice, this gives rights to the MSAA that are not required for day to day activities.

b. Con – SCOM Admins now control a domain admin account.


2. Grant a SCOM Administrator a special domain account, for this purpose, that is a domain admin.

a. This allows us to track the actions of that SCOM admin, when he/she uses that special privileged account.

b. That SCOM admin will be able to do repairs, hotfixes, and deployments for DC’s.

c.  Con – Domain Admin teams often wont delegate these rights as they are tightly controlled.


3. The SCOM admin team delegates console based agent management to a Domain Administrator for DC agent health.

a.  The domain admin must become a SCOM Admin, and therefore could potentially hurt the SCOM environment.

b.  Pro – the admins in charge of the DC’s now have full responsibility to keep the agents healthy.

c.  Con – the Domain Admins might not understand components of SCOM, and create something that impacts the monitoring environment.


4. The SCOM admin team must partner with the Domain Admin team, and have the Domain Administrator type in his credentials any time the SCOM administrator needs to deploy/hotfix/repair an agent on a domain controller.

a. This is a bit more labor intensive… because the SCOM admin must wait for a domain admin to be available to work on DC agents, but tight security boundaries are maintained.


5. All DC based agents will be manually installed/updated/repaired.

a. This is very common, when the two teams do not trust each other.  The Domain Admin team is now required to manually deploy agents to domain controllers, and keep them up to date, and healthy.


6. Use a software deployment tool already in place to deploy/update/repair agents.

a. If a software deployment tool is already in place on DC’s, like SMS/SCCM, you can create packages to deploy, hotfix, and repair agents, similar to your patching of the OS today.


7. Customized solution:  Create a Run-As account that is a domain admin, one time, for use in agent deployment/repair.

a. This involves the domain admin typing in credentials ONCE, into a RUN-AS account, which is stored securely and encrypted in the SCOM database. 

b. This run-as account can be associated with a run-as profile, which is used by a custom task, which will remotely deploy the agent to the domain controller.  This task will execute under the security context of the privileged run-as account.

c. The benefit is that the domain admin gets to control the password for this account, the SCOM admin does not need to know the account credentials.

d. The downside, is that this run-as account could potentially be leveraged by some other workflow, if a SCOM admin intentionally misused it…. Similar to solution #2 above.

e.  This is just an idea I had – curious if anyone has already developed a solution like this?

Comments (15)

  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!