OpsMgr 2012: Enable agent proxy on all agents



Turn on agent proxy for all agents where it is disabled:

get-SCOMagent | where {$_.ProxyingEnabled -match "False"} | Enable-SCOMAgentProxy

Turn on agent proxy as a default setting for all new agents to be deployed, never to have to mess with this again:

add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"; new-managementGroupConnection -ConnectionString:scomserver.domain.com; set-location "OperationsManagerMonitoring::"; Set-DefaultSetting -Name HealthService\ProxyingEnabled -Value True

Thanks for Daniele Muscetta and John Erskine for the references on the default-setting.

Comments (33)

  1. Kevin Holman says:

    I re-verified this working on SCOM 2012 R2 with UR1. Willi – your issue is your typing – try a copy and paste of my actual commands. These are case sensitive and you used a lower case "e" in "ProxyingEnabled"

  2. Eric G-S says:

    Kevin, what’s the benefit and/or penalty of turning on the proxy for all agents?

  3. Kevin Holman says:

    @U – Yes, it is. You must load the snap-in I display in the code sample.

  4. Kevin Holman says:

    @Eric – glad you asked.

    Agent proxy setting allows an agent to submit data on behalf of someone else. This is like an agent submitting data for a cluster node, or about an instance that it might not be hosting. This was turned off by default as an “added” security measure, to keep someone from maliciously installing an agent on a server in your management group, and then submitting “spoofed” data. As you can imagine, what a rare condition/risk that would be! Almost every major role in SCOM requires that agent proxy be enabled/allowed, such as Exchange, Domain Controllers, Clusters, SharePoint, etc… These are often the MOST CRITICAL servers in the company. In my opinion, if we can trust these servers to agent proxy, it isn’t some great risk. 99% of all deployment just enable agent proxy wherever it is needed/requested, with very little validation if at all. Other customers are running scripts multiple times a day to find all agents that don’t have it enabled, and just turn it on, to reduce the administrative overhead of dealing with this in SCOM. Therefore, when you build a new management group, it is quite convenient to simply enable this agent proxy setting as a default setting, so that all NEW agents added to the Management group will inherit this as a default initial setting and you will not have to deal with it.

  5. Kevin Holman says:

    In what context specifically do you mean?

  6. Kevin Holman says:

    @Larry – in my opinion, there isn’t any. I recommend enabling agent proxy as a default setting using PowerShell in the example above, then all agents are automatically enabled for agent proxy when they join the MG and this silly nuisance of administrative
    overhead goes away. I have all my direct customers set this.

  7. Anonymous says:

    That makes sense. Thanks for the quick response.

  8. Kevin Holman says:

    @Jonathan – I believe having NULL in the DB for ProxyingEnabled is normal, for agents that accepted this as a default setting, when you configure the default setting to Enabled. All my agents that inherited agent proxy enabled as a default setting are
    NULL for this value, and all my agents have a set value where they were installed before I configured the default setting.

  9. J says:

    When will the scom team provide proper powershell support? 2012 seems better but still seems like it’s bolted on afterwards instead of being created properly.

  10. J says:

    This would be ideal, but it doesn’t work and you have go back to text based matching/parsing to get things to work. just a rant Get-SCOMAgent | where {!$_.proxyEnabled} | Enable-SCOMAgentProxy or Get-SCOMAgent -ProxyEnabled:$false

  11. Anonymous says:

    Kevin HOLMAN a publié un billet sur son blog concernant l’activation du proxy sur les agents qui n’ont

  12. U says:

    Set-DefaultSetting -Name HealthServiceProxyingEnabled -Value True It´s not a Cmdlet in SCOM 2012 anymore.

  13. Willi says:

    Testing the set-defaultsetting in SCOM 2012 R2 UR1 doesn’t work in my environment. It looks, that "set-Defaultsetting" doesn’t accept the parameter "-name", instead "-path" is requested.

  14. Willi says:

    Update: PS Microsoft.EnterpriseManagement.OperationsManager.ClientOperationsManagerMonitoring::> Set-DefaultSetting -Name HealthServiceProxyingenabled -Value True Set-DefaultSetting : A default setting with a name matching the ‘Name’ parameter was not
    found. At line:1 char:1 + Set-DefaultSetting -Name HealthServiceProxyingenabled -Value True + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (Microsoft.Enter…ltSettingCmdlet:GetDefaultSettingCmdlet)
    [Set-DefaultSetting], ArgumentOutOfRangeException + FullyQualifiedErrorId : InvalidParameter,Microsoft.EnterpriseManagement.OperationsManager.ClientShell.GetDefaultSettingCmdlet

  15. Ricardo Carvalho says:

    Works perfectly with SCOM 2012 SP1 UR3, thanks Kevin

  16. Willi says:

    Hi Kevin, thanx for the hint (I didn’t care about case sensitivity of parameters and the error message does not lead to the real issue).

  17. ashish_1 says:

    Thankyou kavin, but I am afraid that runing this command will not enable proxies for my other agents except the one managment server for which I am getting this alert?
    Pls help

  18. Dennis Wright says:

    We found that this did not work in the Operations Manager PowerShell shell window. This functioned correctly if executed from a normal Powershell window (that did not have the Operations Manager module installed). We are SCOM 2012 R2 UR3. Because PowerShell
    is predisposed to ignore many issues silently, PS did not complain about the cmdlet not working when the Operations Manager module was loaded. YMMV.

  19. Jonathan says:

    I noticed in a customer environment that the database did not match the SDK output. SELECT * FROM MT_HealthService returns NULL for MANY agents, when we verified the SDK returns TRUE for all agents. This was a week after we initially enabled this for all
    agents. MT_HealthService_Log didn’t help in figuring this out.

  20. Jonathan says:

    That makes sense. Thanks for the quick response.

  21. Larry Leblanc says:

    Apart from the security risk identified earlier on, what’s the downside (if any) to having this setting enabled on all agents?

  22. Larry Leblanc says:

    Thanks for the clarification Kevin! 🙂

  23. JP says:

    Thanks Kevin! We moved the exchange servers today and it was started to create some noice because of this.

  24. Yousef Bableh says:

    Thank you. this is helpfull

  25. zouaoui says:

    easy :

    Import-Module OperationsManager

    Get-SCOMAgent | where ProxyingEnabled -Match $False | Enable-SCOMAgentProxy

  26. Eric says:

    I’d like to reduce the auto proxy enable setting permission from all agents to only as your script shows to just SCOM Gateway management servers… I was hoping this was as simple as amending the "add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client""
    first command line to "add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.GatewayManagementServer"" or something like that. Neither "Gateway" nor "GatewayManagementServer" work.

    Any ideas? End goal is for any future new Gateway management servers to have the Proxy Enabled to true.

  27. Kevin Holman says:

    @Eric – pretty sure proxing is enabled for GW by default. No?

  28. Dave Weir says:

    Your script works like a champ. Thanks much for posting this, saved me a ton of work. 🙂

    1. Kevin Holman says:

      I don’t even mess with the powershell script setting the agents – I only just set the default setting now to enable for everyone.

      1. Dave Weir says:

        Yep, thanks again. Your blog is a wealth of knowledge, and has saved me lots of time and anguish.

  29. Arjan Griffioen says:

    In the first example I used Get-Agent in place of Get-ScomAgent, Get-ScomAgent did not work for me on SCOM 2012R2 UR11

  30. Ralph says:

    I was setting up a new SCOM 2016 environment on Windows 2016 as nicely described here:

    That article also brought me here. So having two servers with the following roles:
    SCOM1 Management Server Role, Web Console Role, Console
    SCOM2 Management Server Role, Web Console Role, Console

    … what should “scomserver.domain.com” be pointing to? SCOM1? SCOM2? Both?


Skip to main content