Status Message Process Flow

---

Now that we’ve examined the different tools for handling status messages, let’s look at the status message process flow. Nearly every SMS 2003 service and component generates status messages. Not only does the site server itself generate messages, as one would expect, but the components and services running on site systems (management points, client access points, and so on) and agents running on SMS clients also generate status messages. The status message system in SMS 2003 has the capacity to generate a multitude of messages; however, as we’ve seen, status summarizers and filters keep these messages to a manageable level by default. Nevertheless, status message reporting can add to your existing network traffic bandwidth issues.

Reporting Status on Site Servers and Site Systems

Status messages generated on the site server are processed within the site server itself and then updated to the SMS database. If the SMS database resides on the same server, no additional network traffic is generated. However, status messages that SMS services and components generate on site systems are copied to the site server so that they can be updated to the SMS database. Figure 5.41 depicts the process flow for status messages generated on the site server and site systems.

Figure 5.41: Status message process flow for status messages generated on the site server and site systems.

As we’ve mentioned in the section entitled “Configuring Status Reporting Properties” earlier in this chapter, several options are available to the SMS administrator when configuring status message reporting. Remember that one option enables the SMS administrator to specify whether to convert the status message to a Windows event. When an SMS service or thread generates a status message, that service or thread checks its properties to see whether this option has been set. If it has, the status message is first converted to a Windows event and written to the Windows Application Event Log. If no other reporting options have been configured, the process stops here. If other reporting options have been configured, the status message must be handed off to the Status Manager component on the site server. If the server on which the status message was generated is the site server, the status message is placed either in Status Manager’s In Memory Queue if a thread component generated the message or in Status Manager’s inbox (SMS\Inboxes\Statmgr.box\Statmsgs) as an .SVF file if a service component generated the message.

If the server on which the status message was generated is a site system, the status message is copied to Status Manager’s inbox on the site server. If for some reason the component is unable to copy the status message to the site server, it stores the status message(s) in the %Systemroot%\System32\Smsmsgs subdirectory on the site system and retries until it can successfully copy the status message to the Status Manager’s inbox on the site server.

Reporting Status from Clients

As we’ve seen, SMS components and agents residing on SMS clients also generate status messages, and these messages too must be reported back to the site server for updating to the SMS database. Figure 5.42 illustrates the flow of status messages from the SMS Legacy Client to the site server. Status messages generated on the SMS Advanced Client are propagated to the site’s management point and from there moved to the site server.

Status information is collected not only from SMS client components and agents, but also as the result of application installations in the form of status MIF files. For example, both the package program created through the SMS Administrator Console and the packages compiled through the SMS Installer have the ability to generate status MIF files upon the execution of the program or package.

Figure 5.42: Status message process flow from the client to the site server.

When a status message is generated on the SMS client by an SMS client component, its properties are checked by that component to determine whether the message needs to be converted to a Windows event. If so, and if the SMS client is also a Windows NT client or higher, the status message is written to the Windows Application Event Log. Next, the status message and status MIF files are written to an .SVF file and stored in the %Systemroot% or in the Temp or TMP directory. The client component then initiates a request for the Copy Queue component on the client to move the .SVF file to the Status Manager’s inbox on the client access point (CAP) (CAP_sitecode\Statmsgs.box). Copy Queue is an SMS client component that writes data to CAPs and management points reliably. When Copy Queue has trouble writing its error messages to the CAP, it will write to the CPQMgr32.log file in the %Systemroot%\MS\SMS\Logs file on the client in question. After the file is written to the management point or the CAP, the Inbox Manager Assistant thread wakes up and moves the .SVF file to Status Manager’s inbox on the site server.

Tip 

Each client component generates a log file in the %Systemroot%\MS\SMS\Logs directory on the client computer by default. Check these log files to determine whether the .SVF file was created during troubleshooting of status message generation. In addition, in the log file of the component that should have generated the status message, look for a line that begins with “STATMSG” on or around the time that the status message should have been generated. If it doesn’t exist, or if the next line begins with the text “CserverStatusReporter,” the component might have had trouble generating and reporting the status message.

Reporting Status to the SMS Database

Once the status message is written to its in-memory queue or to its inbox, Status Manager wakes up and reads the status message or .SVF file. It evaluates the message against the status filter rules established by SMS during setup or modified by the SMS administrator. As we’ve discussed, a status message can be handled in one of five ways, as shown in Figure 5.43.

Figure 5.43: Using status filter rules to handle the disposition of a status message.

The status message could be written to the SMS database or discarded. If the Status Manager has not already done so, the status message could be converted to a Windows event and written to the Windows event log. The status message could be handed to a status summarizer to be condensed for viewing through the SMS Administrator Console. If a parent site exists, the message could be sent to the parent site for inclusion in its SMS database or viewing through its SMS Administrator Console. The SMS administrator could also configure a program to be executed upon receipt of a status message. This program might be a system pop-up notification on the SMS administrator’s desktop, the execution of a batch file, or a notification using paging software.

As you can see, the status messaging system in SMS 2003 is quite robust and is capable of inundating you with information about your site server, site systems, and clients. Fortunately, you can control which status messages are reported and how these messages are handled, and you can tailor their generation to fit your specific reporting needs.

---