Troubleshooting

Published : January 1, 2005

There are a number of actions that you can take to troubleshoot product issues:

  • Ensure that Microsoft® Operations Manager (MOM) is installed properly.

  • Ensure that MOM configuration settings are set properly.

  • Ensure that all Microsoft® Systems Management Server (SMS) systems have been configured with Operations Management information. For more information, see the Running Configuration Scripts in this guide.

  • Ensure that all managed SMS Provider and SMS site database computers have the MOM agent installed and are enabled to proxy for other computers.

  • Verify that your import of the Management Pack is complete. For more information, see the Importing the Management Pack section in this guide.

  • Ensure that all relevant entities are enabled, such as rules and associated alerts.

  • Ensure that the computer groups are populated with the correct computers. You can use Views to perform this inspection.

  • Ensure that there are no heartbeat failure alerts.

  • Ensure that the heartbeat interval is set properly and that the rules are propagated to the MOM agent computer. If necessary, in the MOM Administrator console, perform a Commit Configuration Change to ensure that agent computers have the correct rules.

  • Ensure that dependent services, including Windows Management Instrumentation (WMI), World Wide Web Publishing Service, Internet Information Services (IIS) Admin Service, Background Intelligent Transfer Service (BITS), and MSSQLServer, are installed and running properly on SMS 2003 site systems.

  • Ensure that there are no rules being automatically disabled by MOM 2005 due to excessive firing, incorrect syntax, or scripts running too long.

  • Ensure that all performance counters are properly installed.

Known Issues

SMS Might Interfere with the Installation of Non-Microsoft Software That Stops the WMI Service

The SMS 2003 Management Pack might interfere with the installation of non-Microsoft software that accesses the WMI service. Most of the Management Pack’s scripts use WMI to access the registry, and can restart the WMI service. If the WMI service is enabled and can be started, Component Object Model (COM) will successfully restart WMI.

If non-Microsoft software stops, but does not disable WMI during an installation or upgrade, the automatic restart of the WMI script might impact the success of the non-Microsoft software installation. This can pose a problem for WMI or WMI provider upgrades if the installation program does not first disable the WMI service. This issue applies to any client of WMI.

WMI Monitoring

  • The following rules based on Windows NT® system event log events from Service Control Manager for unexpected service failures. There are no known operating system limitations for these rules.

  • SMS 2003 dependent service failure: Windows Management Instrumentation terminated unexpectedly.

  • SMS 2003 dependent service failure: Windows Management Instrumentation hung on starting.

  • SMS 2003 dependent service failure: Windows Management Instrumentation failed to start.

  • SMS 2003 dependent service failure: Windows Management Instrumentation was unable to log on.

  • SMS 2003 dependent service failure: Windows Management Instrumentation depends on another service which failed to start, or is nonexistent.

SMS Tasks Run Only Under User Context That Was Used to Install the SMS 2003 SP1 Administrator Console

This issue occurs because the SMS_UI_PATH environment variable was created by the SMS Administrator console installation as a user environment variable, not a system environment variable. To work around this problem, you can copy the name and value for SMS_UI_PATH and define the above variables as system environment variables, so that all operators and administrators can invoke tasks without errors.

Systems Management Server 2003 Management Pack Cannot Detect SMS Secondary Site if SMS Administrator Console Installed on the Same Computer  

The installation of a Systems Management Server 2003 Administrator console on a computer that is also a SMS secondary site server causes the SMS 2003 Management Pack to fail to identify the server as a SMS Secondary Site Server.

As a workaround for this issue, when you install the SMS Administrator console on an SMS secondary site server, you need to change the registry value HKLM\SOFTWARE\Microsoft\SMS\Setup\Type from 4 to 2.

System Restarts

In the case of a system restart, you might receive only a few service stop alerts. There are no events or alerts indicating that the system was restarted. The best solution to detect an expected or unexpected system shutdown is to install the Microsoft Windows Servers Base Operating System Management Pack, which contains a rule that alerts you of a system restart. Other methods for determining whether a system restart has occurred are to check SMS logs, MOM logs, Windows NT event logs, and MOM events for agent communication.

Monitor SMS Status Messages Script in SMS 2003

When the SMS status message table exceeds 4,294,967,296 messages, the record ID restarts at zero. The Monitor SMS Status Messages script in SMS 2003 does not have a mechanism for detecting when the record ID has restarted at zero. The script currently looks forward only from the record ID of the last status message that it processed. If the record ID restarts, the Management Pack is not able to detect any new status messages.

On the site server, note the Next Status Message Record ID registry value in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\
COMPONENTS\SMS_STATUS_MANAGER registry key. This is the next record ID placed in the SQL StatusMessages table. If this value is less than the LastRecordID value, the StatusMessages table has looped back around and restarted. The script does not process messages again until the Next Status Message Record ID registry value is greater than the LastRecordID value in the VarSet file.

You should periodically monitor the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\
COMPONENTS\SMS_STATUS_MANAGER registry key on the site server for the record ID of the next status message. Small organizations or small sites that are low in the SMS hierarchy should check this registry key every two to three months. Large organizations or sites with several child sites should check this registry key every month. If the value approaches 4,294,967,296, monitor it more frequently. After the record ID has reset to zero, you must unblock status message monitoring on the computer running the SMS site database server for the site. You designate the SMS site database location when you install SMS.

One way to automate registry key monitoring is to create a computer attribute and computer group to monitor the computers that are nearing this threshold.

To locate all SMS site databases in your configuration group

  1. In the MOM Operator console, navigate to Computers and Groups, Microsoft Systems Management Server (SMS) 2003, and then click Computer Groups.

  2. In the Details pane, in the Computer Group column, double-click Microsoft SMS 2003 Site Database Servers. 

To unblock status message monitoring

  1. On the computer hosting the SMS site database role, in the Windows Temp folder, open the following text file: SMS 2003 Monitor SMS Status Messages.VarSet. The LastRecordID_SMSDatabaseName entry is a record ID value that indicates the last status message in the SQL StatusMessages table that the script processed.

  2. On the computer hosting the SMS site database role, change the LastRecordID_SMSDatabaseName value, for the appropriate site, in the file named SMS 2003 Monitor SMS Status Messages.VarSet to be equal to the Next Status Message record ID registry value minus one. If the result is 4,294,967,296, set the value to zero and save the file.

Monitor Site Summarizer Script in SMS 2003 Is Offset From the Default Site System Status Summarizer Interval

The interval at which the Monitor Site System Summarizer script in SMS 2003 runs is offset by 10 minutes from the site system status summarizer polling interval of one hour on the hour. Although the SMS Administrator console allows for configuring the site system status summarizer schedule, it does not change this polling interval, rather only the interval for other maintenance tasks. The Monitor Site System Summarizer script in SMS 2003 is run through a timed event provider, Schedule Every 60 Minutes Synchronize at 00:10. The 10 minute offset period allows time for the site system status summarizer to complete its cycle. If this is an insufficient period of time, it should be extended, otherwise the script finishes before the site system summarizer completes its cycle. This can result in old site system status being reported.

Status Message Rules That Monitor Sender Connectivity Have a Dependency on the Sender Functioning

If the sender cannot connect to its parent site, status messages do not flow up the SMS hierarchy and the Management Pack does not generate an alert on those status messages. This is especially significant in the case of secondary sites, which do not have the SMS 2003 Monitor Status Message script running. The following status message rules that monitor sender connectivity have a dependency on the sender functioning and are disabled by default:

  • SMS 2003 Status: The sender cannot connect to remote site over the LAN (Standard Security).

  • SMS 2003 Status: The sender cannot connect to remote site over the RAS connection.

  • SMS 2003 Status: The sender cannot connect to remote site over the LAN (Advanced Security).

    note.gif  Note
    All of these rules are disabled by default. For these rules to work, each SMS site database server, or at a minimum the central site, must be a managed computer.

A parallel monitoring method has been provided based on an application log provider, the SMS 2003 sender log. These rules are enabled by default. If you disable these rules, you should consider enabling the above companion status message rules. Do not enable both sets of rules, because duplicate alerts will be raised. There is no consolidation of these events or alert rules that addresses both the status message and the component rule being active.

  • SMS 2003 Component: The sender cannot connect to remote site over the LAN (Standard Security).

  • SMS 2003 Component: The sender cannot connect to remote site over the RAS connection.

  • SMS 2003 Component: The sender cannot connect to remote site over the LAN (Advanced Security).

For these rules to work, you need to modify them to point to the SMS log files. Also, each SMS server with a sender must be a managed computer.

BITS Monitoring Disabled by Default

Because the Background Intelligent Transfer Service (BITS) service is started upon demand by the SMS Advanced Client, the following rule is disabled by default in the SMS 2003 Management Pack:

  • SMS 2003 dependent service running: Background Intelligent Transfer Service

You should enable this rule if you have the service configured to automatically start.

The following rules are enabled by default in order to monitor issues with the BITS service and to report if the SMS Agent Host is unable to start the BITS service when required:

  • SMS 2003 service failure: Background Intelligent Transfer Service terminated unexpectedly.

  • SMS 2003 service failure: Background Intelligent Transfer Service hung on starting.

  • SMS 2003 service failure: Background Intelligent Transfer Service failed to start.

  • SMS 2003 service failure: Background Intelligent Transfer Service was unable to log on.

  • SMS 2003 service failure: Background Intelligent Transfer Service depends on another service which failed to start, or is nonexistent.

Application Provider Path Is Set to C:\SMS\Logs by Default, Which Might Not be Valid on Every SMS Site Server

There are four component rules that use the application log provider to monitor the SMS log files in C:\SMS\Logs:

  • SMS 2003 Component: The sender cannot connect to remote site over the LAN (Standard Security).

  • SMS 2003 Component: The sender cannot connect to remote site over the RAS connection.

  • SMS 2003 Component: The sender cannot connect to remote site over the LAN (Advanced Security).

  • SMS 2003 Component: Distribution Manager failed to process a package.

The sender rules are enabled by default where as the Distribution Manager rule is disabled by default. If you installed SMS on a drive other than drive C or modified the default folder where logs are stored, you need to modify this rule before you enable it. If this rule is not modified to search the appropriate folder for log files, the alert does not return the information that you sought.

When you modify the rule to designate the correct path, you can type a path to your log files or create an environment variable and modify the rule to use that variable. If you type a path, it must work on all site servers affected by this rule. If you have two different paths, one for primary site servers and another for secondary sites servers, you can:

  • Create a copy of the providers and modify them to have the paths for primary and secondary site servers.

  • Copy the Sender event processing rules from the SMS Site Servers – Common processing rule group to the SMS Sender Servers or SMS Site Servers – Primary and SMS Site Servers – Secondary processing rule groups.

  • Copy the Distribution Manager event processing rule from the SMS Site Servers – Common processing rule group to SMS Site Servers – Primary and SMS Site Servers – Secondary processing rule groups.

  • Modify the copied rules to use the new corresponding application log providers.

To modify component rules to use an alternative path for log files

  1. In the MOM Administrator console, navigate to Microsoft Operations Manager, Management Packs, and then click Rule Groups.

  2. Next, click Microsoft Systems Management Server (SMS) 2003, SMS Site Servers – Common, and then click Event Rules.

  3. In the Details pane, double-click the rule that you want to modify.

  4. In the Event Rule Properties dialog box, click the Data Provider tab.

  5. For a sender log rule, select SMS 2003 Sender Log. For a distribution manager rule, select SMS 2003 Distribution Manager Log.

  6. Click Modify.

  7. In the Application Log Provider Properties dialog box, click the Directories tab, and then click Add.

  8. In the Directory Edit dialog box, type the folder where the SMS logs are located on all your site servers. For example, if you set the environment variable SMSSETDIR on all your site servers, type %SMSSETDIR%\logs.

  9. Click OK to close each dialog box.