Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

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

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

  • Comments 11
  • Likes

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?

  • 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: AODOMAIN\Administrator

    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 ?

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

  • 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 ?

  • 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

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

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


  • @Sam - I dont have any details - it was just a plausible idea.  :-)

  • 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!


  • @Brumsky -

    Never heard of that issue.

  • 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".

  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs