SMS 2003 SP3 is required on SMS s003 site servers to enable maintenance mode or to view site topology with Operations Manager 2007. For more information, see Supported SMS Configuration.

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.

• 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.
  
  

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.

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.

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, Operations Manager 2007 NT event log, Windows NT event logs, and Operations Manager 2007 events for agent communication.

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 Operations Console, click the Authoring button.
   
   
2. In the results pane, right-click Microsoft Systems Management Server (SMS) 2003, and then select View Group Members.
   
   

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.
   
   

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.

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
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.

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.

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, use the following steps:

1. In the Operations Manager 2007 Operations Console, click the Authoring button, expand Management Pack Objects, and then click Rules.

2. In the Details pane, right-click the rule that you want to modify and select Properties.

3. Click the Configuration tab.

4. In the Responses pane, select the response whose xml you wish to edit.

5. Click the Edit… button. The GenerateAlert - Properties dialog box opens.

6. On the Configuration tab of the GenerateAlert - Properties dialog box, click the Edit… button.

7. Edit the directory string as appropriate. Click OK, click Apply, and then click OK to save the change.

Concepts

Other Resources