Download

NEW! Added support for Windows System (HKCU) proxy settings.

First, the bad news: This new MP version requires a rip and replace of your previous version (and any overrides).
The good news: Now you can manage your System proxy settings easily.

Why might you need to manage your Windows System proxy settings?

When your SCOM agent performs activities that leverage HTTP, the agent will use the “agent-specific” proxy settings from the agent config file, documented here.
However, if your agent is leveraging external tools (executables) like the M365 Supplemental Teams Network Assessment management pack which uses the Teams Network Assessment tool,
(C:\Program Files (x86)\Microsoft Teams Network Assessment Tool\NetworkAssessmentTool.exe)
the external tool will likely reference your Windows System (current user context) HTTP proxy settings, which are stored in the HKCU registry hive, rather than the SCOM “agent-specific” settings. It’s significantly challenging to view and modify the Sytem proxy settings especially since they are user-specific, meaning that you must view/set the configuration as the agent RunAs account; whichever RunAs is running the workflow that uses the external tool/exe. Imagine how annoying this would be when you are using a default RunAs account that is a gMSA, like on a management server.

Setup

1. Enable discovery
2. Run config task for the discovered proxy object to enable/configure.

The discoveries for both class types (Agent and System) are disabled by default. You will have to manually enable the discoveries where appropriate for your environment.

Both discoveries will discover a proxy object wherever they get enabled, and will detect the current proxy settings regardless of enabled/disabled status.

Example:
M365 Supplemental Service Monitoring management pack
1) Agent Proxy – You would want to enable the Agent proxy discovery for your M365 Watcher Nodes as 95% of the workflows leverage PowerShell and Microsoft Graph API.
2) System Proxy – Enable the System proxy discovery only for the M365 Teams Network Assessment Class instances. These workflows use the external .exe tool to perform the synthetic test call.
Example here.

Note: a RunAs security profile does exist for the M365 Supplemental Service Monitoring MP mentioned in the example above. This profile is rarely used or necessary, but if you do use it, keep in mind that your System proxy configuration task would have to be executed using the same RunAs account credential. Remember, the System proxy settings are user-specific (stored in the HKCU registry hive). This MP has a RunAs security profile as well for discovery. If an HTTP “external tool” workflow is leveraging a RunAs account profile, then so must your System proxy discovery.

Agent Proxy View

In the example below, I’ve enabled discovery for all agents. I don’t recommend this in a prod environment. Rather, you should be very specific about enabling only where applicable; wherever your agent is required to leverage an HTTP proxy server.

System Proxy View

Availability Monitoring