When deploying agents in SCOM, it is often required to enable agent proxying in order to achieve full monitoring. Common servers that require agent proxying are AD servers, cluster servers, Exchange servers etc. The reason for enabling agent proxying is to allow the agent to pass data about a computer name other than itself, such as another AD server that is being replicated.  For most SCOM administrators, managing agent proxying can be a time consuming and monotonous task, that really feels unnecessary.

In many organisations, it is felt it as an unnecessary security precaution, and they just enable proxying on all agents using PowerShell, as blogged by Kevin Holman here, http://blogs.technet.com/b/kevinholman/archive/2014/02/11/opsmgr-2012-enable-agent-proxy-on-all-agents.aspx.

In other organisations though, they only want proxying enabled on the agents that require it, which means enabling proxying on the agents you know need it, or waiting for the “Agent proxy not enabled” alerts to appear in SCOM and then enable appropriately.  Where this gets time consuming is when you have a lot of computers that require proxying, as each agent needs to be updated individually.

Agent Proxying not enabled

The alert above is a typical agent proxying alert (with server name erased), which provides all the information needed to automatically enable agent proxying on the required agent.

As I recently had a requirement to automatically enable agent proxying, but only on agents that required it, I wrote a management pack to check for the agent proxying alerts, enables proxying on the affected agents, and closes the relevant alerts.  The management pack has a rule that, by default, will run at 00:05 every day to enable proxying where needed, however this can be changed using overrides.

The PowerShell script that management pack rule runs is:

The management pack can be downloaded by clicking here.

Please leave feedback if you have any issues, or have any improvement suggestions!


Agent Proxying not enabled