was successfully added to your cart.

Managing the Infrastructure with SCOM Tasks – Part 2

By August 29, 2011SCOM 2007

Last month, we described how you can save time and resources by leveraging SCOM to automate problem resolution. In Part 1 of this series, we described the approach behind implementing a time‐saving process to preemptively automate a known, user impacting issue. In Part 2, we will describe how to use a SCOM rule in conjunction with custom data source and write action module types to execute a PowerShell script.

Since PowerShell may not be configured on your servers, it’s important to ensure your environment is capable of using this approach. As a refresher, last month we discussed how proper planning will lead to a successful and predictable outcome. Before continuing, you may wish to read Part 1 again to understand the prerequisites.

Designing the PowerShell Script

IIS 7 has awesome administrative capabilities when using the WebAdministration PowerShell snap‐in. You can read more about. We are going to leverage this module to achieve our goal of locating the log file directory. Afterwards, we can enumerate through the log files and delete the ones older than xx days. Since we are deleting log files, it would be nice to have a record of which logs were deleted. This is accomplished by writing a Windows Event with the deleted log name for ease of tracking and troubleshooting. From a high level, this is the general flow of the script:

  • Determine the number of days to keep the IIS logs (passed as an overridable SCOM parameter)
  • Locate the directory of the IIS logs (using the IIS WebAdministration snap‐in)
  • Enumerate through the list of IIS logs and determine the file date
  • Take the log file date, determine if it is older than xx days and delete
  • With a few lines of PowerShell, the aforementioned requirements turn into the following script.

Testing the PowerShell Script

Before implementing the SCOM rule, you can test the PowerShell script at the command prompt to ensure everything is working properly. Copy the included script to an IIS 7 web server that has old log files. Go into the log directory and make a mental note how many logs exist and their dates. Open a PowerShell command and run the script.

During the testing phase, we do not want to inadvertently delete IIS log files because we want SCOM to do this.  Additionally, you should validate the number of days to retain the logs is exactly what you want. There is a safe and simple way to test which logs would be deleted without actually deleting them. Open the script in your favorite editor and look towards the bottom of the script. Notice the “‐WhatIf” switch parameter in the Remove‐Item command? This will show you the logs that would have been deleted as shown below. Do the log files listed coincide with those that you observed above?

Alternatively, you could remove the “‐WhatIf” switch parameter and delete the log files manually. For demonstration
purposes, the script output would look as follows:

Working with Scripts in a Management Pack

In order to get the script into a management pack, we have to understand how to pass configuration parameters to the
script. In some cases, you may have servers that need to keep their logs for 7 days and other servers to keep logs for 5
days. By modifying the $NumDays variable, we can pass this value to the script as a configuration parameter. In the
management pack, the first line of the script looks like this:

This allows SCOM to pass the $NumDays value that you define in the rule or override. This works well for IIS servers that have different log retention policies. In the DataSourceModuleType, you can see how this is implemented as “IntervalDays”.

Getting the PowerShell script bolted into a MP requires the use of the Microsoft.Windows.PowerShellWriteAction. The first 8 lines of the script are modified to make it “compatible” with the write action and provide debug output as shown below.

Implementing the Solution

The last thing prior to importing the management pack is to determine which servers to run the cleanup rule against.  Since the rule is disabled by default, you must enable through overrides. This table will help you make the best choice for determining how to override the rule:

After importing the sample management pack, click on the Authoring Tab in the Operations Console and select Rules.  You will need to adjust your scope to display only IIS 7 Web Server. Next, search for “IIS 7 Log Cleanup Rule”.  Based on your particular scenario, override the rule according to your requirements in the table above.

Note: Once the override has enabled the rule, it will run immediately after and delete the IIS logs. If you wish to have the capability to run the rule at a specific time, WME offers a turnkey solution to set the time to delete the logs during after‐hours.


Referring to the scenario outlined in Part 1 where customers are negatively impacted by LOB application unavailability due to disk spaces issues; the SCOM rule has automated the cleanup process so your users are not interrupted. This is simply one way to use SCOM to automate management of common cleanup tasks.

The files referenced in this article can be found here.

Subscribe to our mailing list

* indicates required