I have gone through an excellent documentation on SCCM State Messaging. Here are the details.Understanding state messaging in ConfigMgr is important – critical software update data relies on this system – but in v.next of ConfigMgr, understanding state messaging is even more important as more and more components take advantage of it. That said, lets dig into how the state messaging system works
State messaging is a new mechanism in SCCM which reflects point in time conditions on the client. Status messages, by contrast, work to help administrators track the flow of data through various SCCM components. There is even a status message viewer built right into the console so these messages can be viewed and tracked. There is no such equivalent for state messages. The result of state messages is largely only seen in reports, various data in the console (such as number of systems needing a patch) or the client logs themselves.
State messages are very small – communicating very succinct information regarding conditions in place on the client. We will see state messages in action shortly.
The state messaging system is used by specific components of SCCM – the most well known being software updates, desired configuration management, network access protection and the client. There are a few other places as well but these are the major components.
Understanding state messaging in SCCM is important – critical software update data relies on this system – but in v.next of SCCM understanding state messaging is even more important as more and more components take advantage of it. That said, lets dig into how the state messaging system works. To summarize I pulled together the general state message flow below.
Let’s walk through the graphic. The green box represents the state messaging system and the components inside are those that feed information into the state messaging system. When state messages are received two things happen – first, state messages are stored in WMI. Then, on a 15 minute cycle (by default – this can be changed), the state system will scrape WMI for any state message that has not yet been sent and forward up to the MP.
Note in the graphic I have pulled the client installation piece out separately. During client install and before installation has proceeded sufficiently to be able to find or access the MP – or if the MP is down for some reason – state messages about client install will be forwarded to the FSP if configured. For everything else, traffic goes directly to the MP.
State messages arriving at the MP will be processed into .SMX files by the MP_Relay component and placed in the auth\statesys.box\incoming folder on the site server. From there they are processed into the database to complete the flow.
The graphic hopefully does a good job of communicating the general flow – but lets dig deeper for a better understanding of what happens in detail. To get started we need to make sure verbose logging is enabled for the client, MP and state messaging component on the site server.
To set verbose/debug logging on an SCCM client or MP simply edit (or create) the following registry keys and additional logging should kick in.
HKLM/Software/Wow6432Node/Microsoft/CCM/Logging/@Global/LogLevel to 0
HKLM/Software/Wow6432Node/Microsoft/CCM/Logging/DebugLogging/Enabled to True
On the site server edit the following registry key to enable verbose logging and then restart the SMS_Executive (or the state system component)
HKLM/Software/Wow6432Node/Microsoft/SMS/Components/SMS_STATE_SYSTEM/Verbose Logging – Reg_DWORD set to 1
For more in depth analysis. Let’s gothrough the original post