Compartilhar via

Deploying SCOM 2016 Agents to Domain controllers – some assembly required

  • Artigo

<!--[if lt IE 9]>

<![endif]-->

Comments

  • Anonymous
    November 11, 2016
    I'm glad we brought this back in 2016! Granting SCOM admin effective domain admin rights was great from an agent setup perspective but horrible from a security point of view.
  • Anonymous
    November 16, 2016
    So, what if my AD group wants to leave the block in place and run the agent as a domain account? We are currently using the System account for all of our agents, but after showing this post to our AD admins, they are rethinking that. I did a test agent install from my current 2012 R2 system. When I got to the last page of the agent install wizard, I changed the Agent Action Account from Local System to a domain account that has admin rights on the target server. The agent was successfully installed, and the Default Action Account run as profile for the agent correctly reflects the domain account I specified. However, the Microsoft Monitoring Agent service on the target server was installed to run as the Local System account! How do I resolve this? Do I have to just manually change the service account? Will that break anything else?
    • Anonymous
      November 16, 2016
      Then it is totally fine if using a domain account for monitoring AD... to leave the default HSLOCKDOWN configuration blocking local system.Now - on your specific question - the SCOM "Healthservice" will ALWAYS run as Local System in the services applet. That's just how it works. The Healthservice doesnt do anything other than handle the communications, and spawn the worker processes. However - the MonitoringHost.exe processes spawned will always run as the default agent action account - or specific RunAs accounts. This is what matters. Don't change the account that the service executes as - that stays as local system and isnt a security issue. It is the default agent action account that matters. If you do choose to run as a specific domain account, but you grant that account domain admin for it to work - I dont see how that is any more secure than just using Local System on the domain controller.
  • Anonymous
    November 16, 2016
    Okay, thanks for the fast reply! :-)
    • Anonymous
      November 16, 2016
      Actually, I just checked on my test agent install system, and there are three MonitoringHost.exe processes running. Two of them are running as the System account and one is running as the default agent action account as you described. Does this sound normal?
      • Anonymous
        November 16, 2016
        Yes - the ones that run under system are internal only and do not run MP workflows, unless there is a workflow that has been associated with the "Privileged Monitoring" profile.... which is specifically used for workflows that MUST run as local system.... of course those would fail to run if local system is denied via HSLOCKDOWN and we would see this in the OpsMgr event logs on the agent.
        • Anonymous
          November 16, 2016
          Thanks again for the information! :-)
  • Anonymous
    November 16, 2016
    Another question (sorry). Is there a general set of workflows that use the privileged monitoring account? I found this article:https://support.microsoft.com/en-us/kb/946428It says that the account is used to process Health Service configuration. Is this all the account is used for? If not, is there a list somewhere of all the workflows that use this account? Can individual management packs use the account for random workflows? How would one go about finding those, if so? Thanks again for all of your insight Kevin.
  • Anonymous
    December 02, 2016
    Thanks for this Information
  • Anonymous
    January 10, 2017
    Awesome man, you save me a lot of time :) Thanks
    • Anonymous
      February 13, 2017
      1.Can SCOM 2012 R2 agent still work and reporting to upgraded SCOM 2016 Management Server group from SCOM 2012 R2 Management group until all the agents are upgraded to SCOM 2016 agent? 2) Can SCOM 2016 agent reporting to SCOM 2012 R2 management group?
      • Anonymous
        February 13, 2017
        Q: Can SCOM 2012 R2 agent still work and reporting to upgraded SCOM 2016 Management Server group from SCOM 2012 R2 Management group until all the agents are upgraded to SCOM 2016 agent? A: Yes, of course, that is a natural result of upgrading a SCOM e2012 environment. There will be a period of time in the upgrade process where agents are still on SCOM 2012R2 version. We support a SCOM 2012R2 agent reporting to SCOM 2016 as long as it is in the context be being upgraded.Q: Can SCOM 2016 agent reporting to SCOM 2012 R2 management group?A: Yes. This is would be very common when doing side by side upgrade migrations.
  • Anonymous
    March 01, 2017
    Hello Kevin,Thank you for the KB, I did a tool to run the HSLOCKDOWN commands.Can you please give your feedbackhttps://waleedmostafa.wordpress.com/2017/03/01/scom-2016-agent-hslockdown-tool/Thank you in Advance.
  • Anonymous
    April 25, 2017
    The comment has been removed
  • Anonymous
    April 27, 2017
    Thanks for solution, Kevin! But when I do it on DC-server, my SCOM management server became GRAY :(DC-server is fine(green agent). Searches on the Internet did not yield results, maybe you know how fix it?
  • Anonymous
    June 02, 2017
    "I’ll be researching why this change was made – this did not happen by default in SCOM 2012R2." - curious if there is additional guidance that explains why the change was made.
  • Anonymous
    August 09, 2017
    Thank you!
  • Anonymous
    August 15, 2017
    I'm curious if anyone have managed to run the agent on a domain controller as a domain user without assigning admin privileges? From my point of view, it doesn't matter if we are running the agent as SYSTEM or another user as admin privileges still is required.
  • Anonymous
    February 19, 2018
    The comment has been removed
  • Anonymous
    July 27, 2018
    Thanks Kevin. It worked for me.