This chapter is from the book
This chapter is from the book
This chapter is from the book
Status and State Messages Overview
The following sections discuss status and state messages and their use within ConfigMgr. Status messages have existed in ConfigMgr since SMS 2.0. State messages are a newer concept, introduced with ConfigMgr 2007, and their usage has expanded since that time.
Using Status Messages
A status message represents an event and is similar to messages in the Windows Event Log. Each status message type has a defined message template and variables populated by the component generating the message. These messages are not stateful, in that they do not designate the particular state of a client or a client operation or deployment. However, each process (such as legacy software distribution via packages and programs, discussed in Chapters 13 and 14) has a process defined in code that it goes through and certain status messages it generates. From that defined process, it is possible to infer statefulness. For example, if a package-based software distribution deployment goes through six steps, each with its own message, you can infer that if you see the message from step 6 that it has completed the process. The issue is that if a seventh step is added in an update to ConfigMgr, reports and processes would need to be rewritten to support the new definition of the final message in the process.
Conversely, status messages are useful for task sequences in OSD. Because a task sequence (TS) is a custom set of steps defined by an administrator, generating a hard-coded set of state messages would not be useful as these messages could only define known stages (such as starting, processing, and ending a TS). Status messages are generated for each step in the TS during task sequence execution. (For more information about OSD, see Chapter 22, “Operating System Deployment.”)
Status messages are also useful for picking up specific events from site servers and site systems for methods of eventing as data from clients is processed and internal processes occur. For example, if the Data Loader (DataLdr) is unable to process a delta inventory because it has yet to receive a full inventory (usually because a client was deleted manually from the console), it generates a status message to reflect that. If the Site Component Manager (SiteComp) cannot install or reinstall a site system role, it generates a status message for each failed attempt.
Client status messages are sent via the MP to the primary site server for processing. Both client and server status messages are written to the statmgr.box inbox for processing and are processed by the Status Manager component of SMSExec on the site server and inserted into the site database.
How State Messages Work
In contrast to status messages, state messages (as their name implies) are stateful. Each state message refers to a specific activity, compliance item, or operation. These messages have distinctly defined topics that they relate to (for example, application management). Each topic has multiple corresponding state message IDs that define the state for the instance of the topic.
For example, a certain topic type defines some state messages as relating to application management. Within that topic type are state message IDs that correlate to the various states of an application deployment, including Success, In Progress, Unknown, Requirements Not Met, or Error. The instance of the topic type in this case is an application deployment to a user or device. Each message reflects a state of the deployment and overwrites the last reported state. Conceptually, an application deployment may go from Unknown to In Progress and then to either Success or Error, depending on whether the application installer succeeded or failed.
State messages are used primarily to support client operations and reduce the need for repeated messages and are generally less noisy than status messages. For example, if an application repeatedly fails, it may simply stay in the Error state unless the specific type of error changes. Contrast this with status messages, which are generated for each attempt, with potentially more than one status message per attempt. A client also maintains a list of the various activities and deployments for which it has sent a state message; wherever possible, it attempts to send delta state messages to reduce the load on the site infrastructure.
State messages are sent via the MP to the primary site server for processing. They are written to the auth\statesys.box inboxes for processing and are in turn processed by the State System component of SMSExec on the site server and inserted into the site database.