Remove IIS servers from SCOM monitoring

In our environment we have alot of Windows servers running IIS (Internet Information Services). Many of these servers do not need to have IIS monitoring enabled in SCOM because they are development or test servers that have their IIS services stopped, restarted, or specific sites stopped at random by developers and engineers. So, the problem I am faced with is removing these servers from IIS monitoring in SCOM (we’re using the Microsoft-provided IIS management packs) while still getting things like OS-related alerts.

To do this, create a group in SCOM under the Authoring tab. Use explicit membership and add each Windows computer object for the servers running IIS that we don’t want to monitor. Then, we need to set overrides on the object discoveries. Click on Object Discoveries in the Authoring section, and search for the following three object discovery rules:

• Windows Internet Information Services Server Role Discovery Rule (for Windows 2003/IIS 6 servers)
• IIS 7 Server Role Discovery
• IIS 8 Server Role Discovery

Right-click each of these rules, click “Overrides – Override the Object Discovery – For a group…” and select the group created in the previous step. Check the override for the “Enabled” parameter and change the value to “False.” The next time the object discovery runs, it will remove IIS monitoring for the servers in the group. (Note: By default, the object discoveries for IIS on Windows 2003 and 2012 run every hour, but for 2008/2008 R2, they run every 4 hours.)

BUT WAIT…there’s more! After the discovery runs and the IIS objects are disabled, you’ll notice that they still show up in the views, and old alerts will remain in the console. There is a powershell cmdlet you need to run in order to clean these up. Open the Operations Manager Shell and run the following:

• SCOM 2007: remove-disabledmonitoringobject
• SCOM 2012: remove-scomdisabledclassinstance

You’ll receive a warning that the operation will permanently delete class instances and relationships from the database and it can take a significant amount of time to complete. I haven’t experienced any long delays in my environment of over 700 agents, it typically takes less than one minute to complete.

If you need to add IIS monitoring back for one of these servers, simply remove it from the group you used to disable monitoring, and the IIS objects will be added back to SCOM on the next discovery cycle.

Strange SCOM CScript.exe Errors On Domain Controllers

I recently encountered a domain controller running Windows Server 2008 R2 in our Active Directory domain that was recording a strange event in the Application event log every five minutes. The event information was:

Log Name:      Application
Source:        Application Error
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Description:
Faulting application name: cscript.exe, version: 5.8.7600.16385, time stamp: 0x4a5bca2a
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e
Exception code: 0xc00000fd
Fault offset: 0x0000000000053560
Faulting process id: 0x25ac
Faulting application start time: 0x01cdffe08a2d9a20
Faulting application path: C:\Windows\system32\cscript.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: c8dd9c2a-6bd3-11e2-89a7-2c768a515630

After doing a little research online I discovered that there was a problem with one of the AD monitoring scripts in System Center Operations Manager 2007 R2. In my case, it was the AD_General_Response.vbs script. It appeared to be related to information this script reads and writes to/from the registry. The registry path in question can be found at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Modules\{D0C83F7B-F7B6-91F9-47DE-B63140166447}\S-1-5-18\Script\AD Management Pack\AD General Response

(Note that the unique identifiers may vary on your system.) In this path there are two keys, ErrorCount and ErrorDescription, that contained data. ErrorCount contained a number, and ErrorDescriptions contained a long string of data that was too big to see. It is this long ErrorDescriptions key that I believe contained faulty data and needed to be cleared to prevent these errors from being logged. After backing up the registry (always back up your registry before making registry changes!) I deleted the values in both of these keys. I noticed after doing this that within 5 minutes, the ErrorCount key was repopulated with the value “0”.

Note that the ErrorDescriptions key, when I opened it, didn’t contain any text in the box, but if I held down the delete key for several seconds and then hit OK, it cleared the data from the value. Again, something was definitely unusual about this key.

SCOM Domain Controllers Alert Script Based Test Failed to Complet

If you are using the Microsoft Active Directory management pack in System Center Operations Manager 2007 R2, you may encounter some strange alerts on a new domain controller after adding it to your domain. Specifically, you may receive “Script Based Test Failed to Complete” alerts. There will probably be two alerts that show up, the description for these alerts will state:

“AD Lost And Found Object Count: The script ‘AD Lost And Found Object Count’ failed to create object ‘McActiveDir.ActiveDirectory’. This is an unexpected error. The error returned was ‘ActiveX component can’t create object’ (0x1AD)”

“AD Database and Log: The script ‘AD Database and Log’ failed to create object ‘McActiveDir.ActiveDirectory’. The error returned was: ‘ActiveX component can’t create object’ (0x1AD)”

These scripts run every five minutes, and you will see corresponding errors in the OperationsManager Event log on the domain controller that is raising the alerts.

More than likely, the problem domain controller had a manual installation of the Operations Manager agent, rather than a push from the management server. When you do this, it prevents the Active Directory Management Helper Object for SCOM to be installed, which is automatic for agents that were pushed from the management server. This helper object is necessary for these scripts to run properly.

You can manually install the helper object by copying the “OomADs.msi” file from the management server’s “C:\Program Files\System Center Operations Manager 2007\HelperObjects” folder to the domain controller and running the MSI installer. My experience has been that no reboot is required and the installation should only take a few seconds or so to complete.

After installing the helper object, you can manually close the associated alerts in the Operations Manager console.

Configure SCOM to alert when new shares are created

My company, like many other companies, are under strict regulations from governments at various levels to control who has access to sensitive data.  We not only have to worry about who can access data on our network from outside the corporate firewall, but also users who are internal.  One of the most difficult struggles we have had is controlling who has access to shared folders on our internal servers.

Since we delegate administrative privileges to many of our servers to other groups in IT (such as DBAs or Application Developers), it is a frequent occurrence that one of these individuals will create a new file share but not lock it down properly.  As you may know, shares created on a server running Windows Server 2003 are, by default, open to “Everyone” with read-only access.  So, how can you get some control on this situation?  You can beat systems administrators over the head with policies until your arms are tired, or you can configure SCOM to send an alert any time a share is created on any of your monitored servers.

SCOM can be configured to monitor for WMI events in addition to events in the Windows event logs.  Fortunately for us, a WMI event is triggered every time a shared folder is created in Windows.  Unfortunately for us, the WMI event looks the same no matter what is shared, so SCOM will not differentiate between a new shared printer and a new shared folder.  However, if you are like me, you won’t mind getting notified when printer shares are created, as long as you are also notified when a folder is shared.

I want to make it clear that I didn’t come up with this on my own, I simply pulled information from other sources on the Internet and used what I needed to accomplish my goals.  The following two blog posts were very helpful for me:

http://blogcastrepository.com/blogs/francoisd/archive/2008/09/22/scom-2007-how-to-raise-alerts-using-wmi-event-rule-and-get-the-desired-variable-in-alert-description.aspx

http://blogs.technet.com/b/smsandmom/archive/2008/08/21/opsmgr-2007-how-to-create-a-monitor-to-alert-when-a-network-share-is-created.aspx

Now, here’s what I did:

1. We’re going to be creating a rule.  Launch the Operations Manager Console UI, go to Authoring, select Rules.
2. Right-click Rules, select “Create New Rule.”
3. On the Created Rule Wizard, expand Collection Rules >Event Based > WMI Event and click Next (don’t forget to select a custom management pack other than the “Default Management Pack”.
4. Enter a Rule Name (I used “New network file share created”) and if you would like, you can also enter a description.
5. On Rule Category, select Alert.
6. For Rule Target, click Select, click on View All Targets, and select Windows Computer
7. For WMI Namespace, type root\cimv2 and for Query, enter the following:SELECT * FROM __InstanceCreationEvent WITHIN 120 WHERE TargetInstance ISA ‘Win32_Share’
   
8. Set the Poll Interval to 120 seconds.

When finishing out the rule, you’ll want to configure this rule to have a response of an Alert.  Here was the tricky part for me.  I needed to get useful information out of the WMI Event to put into the alert so I could make sense of what the alert was telling me.  Specifically, I wanted to know the name of the share and the local path to the folder on the server.  Configure your alert to look like the following screen shot:

After configuring the alert, I setup a subscription in SCOM for the alert to email me whenever a new share is created.  Now I am able to check new shares when they are created to make sure they are locked down with the appropriate permissions.

Add Email as a delivery method for SCOM Scheduled Reports

Ever noticed that when setting up a scheduled report in System Center Operations Manager that E-mail is not available as a delivery method?  The only options I had in my environment by default were “Null Delivery Provider” and “Windows File Share.”  After searching the options in SCOM, and digging through my copy of “Systems Center Operations Manager Unleashed”, I discovered that this is intentional.  Since SCOM relies on Microsoft SQL Reporting for reports, this is actually an option that has to be configured on the SQL server.

Our environment uses SQL 2008 for the database server.  We run both the Operations Manager DB and the Data Warehouse DB on this server, in addition to the SQL Reporting Services.  If you want to configure E-mail as an option for SCOM scheduled reports delivery, log on to your SCOM database server, and go to Start, All Programs, Microsoft SQL Server 2008, Configuration Tools, Reporting Services Configuration Manager.  Connect to your server and server instance, then go to E-mail Settings on the left and enter your Sender Address and SMTP server name.  It should look something like this in SQL 2008:

Now you should have E-mail listed as a Delivery Method in SCOM for a scheduled report.

Troubleshooting IIS Server Discovery in SCOM 2007

I am currently in the process of deploying Microsoft System Center Operations Manager (SCOM) 2007 R2 in our environment to monitor all of our servers.  During the deployment process, I noticed that several of our servers that run IIS 6.0 on Windows Server 2003 to host an internal web-based application were not being discovered in SCOM as IIS servers.  I contacted Microsoft Premier Support about this and was able to get some assistance.

The first thing they had me try was to reinstall the agent, doing a reboot in between the uninstall and reinstall.  Doing this didn’t fix the problem.  The second thing they had me do was to check the IIS Admin service startup type, and make sure it was set to “Automatic”.  It turns out that all of the servers in question had their IIS Admin service startup type set to “Manual”.  I changed the IIS Admin service’s startup type to “Automatic” on all of the servers in question, then restarted the System Center Management (Health Service) service.  I waited a few minutes, then refreshed the IIS Computer Role view in the SCOM console, and viola!  The missing servers showed up, problem solved.

So if you have any IIS servers not being discovered properly in SCOM, you should make sure the IIS Admin service startup type is set to “Automatic”, restart the Health Service, wait 5 minutes and check again.