I have gone through 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, let us dig into how the state messaging system works.
State messaging is a new mechanism in SCCM that 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 to view and follow these messages. 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 a 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, let’s 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 it up to the MP.
Note in the graphic, and I have pulled the client installation piece out separately. During client install and before installation has proceeded sufficiently 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.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.
Hopefully, the graphic does a good job of communicating the general flow, but let’s dig deeper to understand better what happens in detail. We need to make sure verbose logging is enabled for the client, MP, and state messaging component on the site server to get started.
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, the 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 go through the original post.
Anoop is Microsoft MVP! He is a Solution Architect on enterprise client management with more than 20 years of experience (calculation done in 2021) in IT. He is Blogger, Speaker, and Local User Group HTMD Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, Intune. He writes about technologies like ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc.…