This is for SCOM 2012 through SCOM 2019.
The default setting for new SCOM agents is that Agent Proxy is disabled. You can enable this agent by agent, or for specific agents with script automations. I find this to be a clumsy task, and more and more management packs require this capability to be enabled, like Active Directory, SharePoint, Exchange, Clustering, Skype, etc. At some point, it makes a lot more sense to just enable this as a default setting, and that is what I advise my customers.
Set it once, and forget it.
One of the FIRST things I do after installing SCOM:
On a SCOM management server: Open up any PowerShell session (SCOM shell or regular old PowerShell)
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"; new-managementGroupConnection -ConnectionString:localhost; set-location "OperationsManagerMonitoring::"; Set-DefaultSetting -Name HealthService\ProxyingEnabled -Value True
If you want to use this remotely – change “localhost” above to the FQDN of your SCOM server.
In order to inspect this setting, you can run:
add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"; new-managementGroupConnection -ConnectionString:localhost; set-location "OperationsManagerMonitoring::"; Get-DefaultSetting
thanks Kevin!
Does this work on SCOM 2019? I am rolling out a new environment and this is a pesky part with SQL especially.
Yep
Thanks!
I’m getting the alert for my management servers but I’ve enabled it. I’ve tried turning it off and waiting and then enable it again but the alert comes back. Any ideas?
Is this count for all agent installation method (Push, and Manual)?
Yes. It is a one-time permanent change for all agents in the management group, present and future.
Minor adjustment, you should not run this on any scom managementserver but on a server where the scom console is installed. If you have the console on your managementserver it will run fine but it’s the console that brings the powershell commandlet.
What about SCOM 2022?
Yes
Will this increase the resource utilization of the reporting server? Like CPU and Mem consumption?
Absolutely not.
Hi, could this be a security thing when I enable this on a not good secured server where nearly everyone have access to it? With this setting I should be possible to create temporary a object which should not be there on a critical server. Maybe if I knew there is a rule to this object like make user xyz to local admin?
I’m not sure you understand what this does. This is simply allowing for an agent to proxy for other “things” when sending data into SCOM. MOST management packs require this, so this is not a security issue. The default setting is dumb, at this point. It was an “ok” setting maybe back in 2007, when very few MP’s needed this to be enabled.
I thought enabling this whould disable the check on the discovery that only objects hostet on this computer will be allowed to create. Without this I can create objects for another computers. Also existing computers in scom? Is it possible to manipulate the discovery scripts in the agent cache?
Ok – yes – it allows for alerts to be sent for classes that might not be directly hosted, or for virtual objects, like clusters, domains, forests, hierarchies, etc. It also allows the same for discovered objects.
It is required for Clusters, SQL servers, Exchange, Domain Controllers, SharePoint servers, etc. Almost every monitored agent really needs this enabled these days due to the management packs that most companies use. On the manipulation of discovery scripts – I have never seen that before. It would be interesting to test. But if someone already has administrative access to a server, what are you protecting?
I admit this is more of a theoretical scenario, but for example if I tell my scom admin to create a rule which I can use on my computer (he usually asks me which application->object to be determined), for example a hard-coded user with no be present in the local admin group. Then I could use this knowledge to create this application object for another server from my server until the next discovery run on the target server, provided I can manipulate the discovery scripts locally and do not have a CRC check so that the agent executes them? If that were the case, then as a non-scom admin I could still manipulate the SCOM database for servers other than my own. I’m just trying to deduce the reason for this function to understand it too well.
Not really, because in order to leverage a RunAs account – the SCOM admin must distribute the RunAs account to the agent. That is a manual and intentional process. If you want to discover something on a box you own, you can easily fake that information by putting in the registry entries, files, etc, that discoveries use.
But I want to create this object and it’s belonging workflows on a server where I do not have access (I want to foist something on the foreign server). And with this feature enabled on my “low risk computer” it is possible for me? If this is possible I think I know the reason for this setting.