NOTE: I believe the IIS 6 Management Pack exhibits similar behaviors. In the interest of simplicity I am going to confine my comments to the IIS 7 Management Pack, but you should easily be able to extend the concepts if you need to.
One frequent complaint about the IIS management pack for SCOM is that it raises alerts on servers where IIS is not installed. The two alerts usually seen are “Web Management service is stopped” and “IIS 7 server role is unavailable.” These alerts are raised due to inconsistent behavior in the Microsoft.Windows.Win32ServiceInformationProvider Data Source when the service to be monitored doesn’t exist.
For more information, please see http://msdn.microsoft.com/en-us/library/jj130359.aspx
The IIS 7 Management Pack performs an initial discovery against all Windows 2008 (and 2008 R2) Server computers. It simply checks to see if the registry key HKLM\SOFTWARE\MICROSOFT\InetStp exists. If that key exists, it believes it has found the IIS 7 Server Role class, to which it applies a pair of basic service monitors that check to see if the WMSvc and IISADMIN services are running. These monitors work correctly if those services exist, but can behave unpredictably if they don’t exist.
If you add the Application Server Role to your server, it will install the Windows Process Activation Service (also known as WAS) which came from IIS, but can exist separately from IIS. Since the service came from IIS, installing it creates the HKLM\SOFTWARE\Microsoft\InetStp\Components\WASConfigurationAPI REG_DWORD. That is enough to get the IIS 7 Management Pack to believe it has discovered an IIS 7 Server Role, and apply the two service monitors mentioned above.
So what can we do about this? There are two options.
The first option is more simple, but also more presumptuous. You can disable Microsoft.Windows.InternetInformationServices.2008.ServerRole.Discovery.Rule (IIS 7 Server Role Discovery) and replace it with a discovery that checks for any of the following REG_DWORDs exist:
Those are the services that are discovered by targeting the IIS 7 Server Role.
The other method is to extend the IIS 7 Computer Role class, and then create groups that contain instances of it where WMSvc and IISADMIN actually exist. Then use those to override the monitors. This method is more complex, but makes less invasive changes to the management pack in case a future release of the IIS 7 management pack significantly changes how discovery works. This is the method I chose.
First we need to make a custom class that extends the Microsoft.Windows.InternetInformationServices.2008.ServerRole class so we can add properties to it.
Now we add a pair of Boolean properties to the class.
The discovery is quite simple. Just make an unfiltered registry discovery that targets the IIS 7 Computer Role. We discover two Boolean attributes for the existence of SYSTEM\CurrentControlSet\services\IISADMIN\Start and SYSTEM\CurrentControlSet\services\WMSvc\Start and map those to our new class properties.
Now that we have discovered the properties, we can use them to populate our groups. I’ll spare you all the screenshots, as I am attaching an example management pack that has all of the classes, relationships, discoveries, and overrides that I am referencing.
Here’s an example of using a Boolean object property in a group populator:
The last step is four Monitor Property Overrides. Two non-enforced overrides to disable the monitors for all IIS 7 Server Roles, and two enforced overrides to re-enable them for members of our groups where we know the services exist.
A complete management pack that contains a full implementation of my solution is attached.