Category: Orchestrator

Load Balancing SCOM Agents

So you have multiple SCOM Management Servers, yet you just happen to have all of your SCOM agents reporting to one server, or maybe two if you half tried to load balance your agents. There are several reasons why you would want to have multiple Management Servers, ie. off-load workflows, reduce stress on servers, etc., etc. Well what is the point of having multiple Management Servers yet nearly all of your agents are reporting to one, or maybe two at best Management Servers, while the others are collecting dust. Load balance those agents! You could manually move an agent by right clicking and moving to a new server, or you could let our friend PowerShell automate this for you.

In my experience I have seen many SCOM environments where load balancing is either done manually, or not done at all. And usually manually implies the SCOM administrator takes a look which of the servers has the least agents, and deploys away. That works, but why not deploy to any server then let PowerShell load balance for you.

In the solution below, I am using PowerShell along with Orchestrator 2012R2. The runbook can be setup to run ad-hoc, or run regularly, ie. monthly, weekly, etc. Of course if you do not Orchestrator deployed in your environment, you could very well take the script and schedule it to run via Windows Scheduled tasks.

ce63742c-85d7-402e-b114-c3979b7ce32b

Here I have created a Runbook to execute the script, and then send back a warning notification if the Runbook failed, or an informational notification that the Runbook executed successfully.

See below for the PowerShell script. Please note, you will need to change the Line 5 with a SCOM Management server applicable to your environment, duh. This script can also be modified, and you can load balance between two gateway servers.

The script can be found HERE!

Happy SCOM’ing!

Wintel Gray Agents Runbook Automation

This Orchestrator Runbook, “SCOM2012R2_Check_HealthService” is setup to capture a “Health Service Heartbeat Failure” for Windows machines, and restart the HealthService and/or delete the corrupted HealthService cache folder and restart the service.

The Runbook will capture the alert from SCOM, once captured, it will wait 60 seconds, it will then ping the machine, and if the ping is successful then it will then wait for 180 seconds, then check to see if the HealthService on the machine is running. If the ping is unsuccessful, it will send an email indicating the machine is actually offline.

If the HealthService is running, then it is possibly a corrupted cache folder. It will then stop the HealthService, delete the cache folder, and restart the service.

If the HealthService is not running, it will then start the service.

In both events, an email will be sent out as an information alert, to indicate that the Runbook resolved the issue.

1

Details of Configuration

Monitor Alert Properties:

2

Link from Monitor Alert to Run Program:

3

Link from Run Program to Get HealthService Status:

4

Link from Get HealthService Status.

If Not running:

5

 Start HealthService Properties:

6

Since the Stop HealthService Properties are almost the same as Start HealthService, we have omitted this.

Delete Folder Properties

This pertains to SCOM 2012R2. There is a duplicate run book with the same configuration that checks against the old folder structure:

7

8