Troubleshooting Configuration Manager: Resolving Multiple Topic ID 611 State Messages

Table of Contents

This article addresses a specific issue encountered in Configuration Manager environments where clients inadvertently transmit numerous Topic ID 611 state messages. This problem typically surfaces when administrators are engaged in servicing a server group within a child primary site, especially one utilizing a remote management point. Understanding and resolving this issue is crucial for maintaining the smooth operation and efficient state message processing within your Configuration Manager infrastructure.

Original product versions affected by this issue include: Configuration Manager (current branch) and Configuration Manager (Long-Term Servicing Branch). This issue is documented under the original KB number 4018656.

Symptoms¶

The primary manifestation of this issue is the appearance of errors during server group servicing, specifically when performed on a child primary site that incorporates a remote management point. These errors are typically captured in the MP_ClientID.log file, a crucial log for troubleshooting management point related activities. The error messages logged will bear a striking resemblance to the following:

CMPDBConnection::ExecuteSQL(): ICommandText::Execute() failed with 0x80040E09
MPDB ERROR - EXTENDED INFORMATION
MPDB Method : ExecuteSP()
MPDB Method HRESULT : 0x80040E09
Error Description : The EXECUTE permission was denied on the object 'spGetLockState', database '<dbname>', schema 'dbo'.

These log entries clearly indicate a permission problem within the SQL Server database. The error message “EXECUTE permission was denied” points directly to insufficient rights for the management point to execute the stored procedure spGetLockState. This stored procedure plays a vital role in the server group servicing process, and lack of execution rights hinders the operation.

In addition to these server-side errors, client-side symptoms also become evident. Clients may begin sending a flood of Topic ID 611, Type 611 state messages. These messages are typically stored as .smx files on the client machines before being processed and relayed to the management point. The sheer volume of these messages can quickly lead to a significant backlog in state message processing. This backlog can, in turn, impact other Configuration Manager functionalities that rely on timely state message updates, potentially affecting reporting accuracy, compliance status updates, and overall system responsiveness. The excessive generation of these state messages is not just a symptom but also a contributing factor to performance degradation within the Configuration Manager environment.

Cause¶

The root cause of this issue lies in the interaction between the “Service a server group” feature and the security permissions associated with remote management points. When the “Service a server group” feature is enabled in Configuration Manager, it relies on specific stored procedures within the SQL Server database to manage and coordinate the servicing process. One such crucial stored procedure is spGetLockState.

The problem arises because, in certain configurations, particularly those involving remote management points on child primary sites, the necessary “Execute” permissions for these remote management points are not automatically or correctly applied to the spGetLockState stored procedure. This oversight in permission assignment prevents the remote management point from properly executing the required database operations when servicing a server group.

Essentially, the management point, acting on behalf of the clients within the child primary site, attempts to interact with the SQL database to manage the server group servicing process. However, due to the missing “Execute” permission on spGetLockState, these database interactions fail. This failure triggers the error messages observed in the MP_ClientID.log and, consequently, leads to the client-side behavior of sending multiple Topic ID 611 state messages. These messages are likely attempts by the client to report the servicing status or errors encountered, but due to the underlying permission issue, they become repetitive and overwhelming.

To put it simply, it’s a permissions configuration gap. The “Service a server group” feature, when used with remote management points in child primary sites, has a dependency on the spGetLockState stored procedure, but the system doesn’t automatically ensure that these remote management points have the necessary permissions to execute it. This gap in permissions is the fundamental cause of the observed symptoms.

Workaround 1: Disable the “Service a server group” Feature¶

The most straightforward workaround, especially if the “Service a server group” feature is not actively being utilized in your environment, is to simply disable it. Disabling this feature will immediately prevent the conditions that trigger the permission issue, as the system will no longer attempt to use the spGetLockState stored procedure in the context of server group servicing.

To disable the “Service a server group” feature, you would typically navigate to the Configuration Manager console, locate the Software Updates settings, and find the option to enable or disable this feature. The exact steps might vary slightly depending on your Configuration Manager version, but generally, it involves locating the relevant feature settings within the console and toggling it off.

This workaround is particularly suitable for organizations that are not leveraging the automated server group servicing capabilities of Configuration Manager. If server groups are being serviced manually or through other methods, disabling this feature will not impact those processes and will effectively resolve the issue of excessive Topic ID 611 state messages.

However, it’s crucial to remember that disabling this feature means you will lose the automated server group servicing functionality provided by Configuration Manager. If you intend to use this feature in the future, or if it is a required component of your update management strategy, then disabling it is not a long-term solution. In such cases, Workaround 2, which focuses on correcting the permissions, is the more appropriate approach.

Workaround 2: Manually Grant Execute Rights¶

The more robust and recommended solution, especially if you intend to continue using the “Service a server group” feature, is to manually grant the necessary “Execute” rights to the management points for the spGetLockState stored procedure within the SQL Server database. This workaround directly addresses the root cause of the issue by ensuring that the remote management points have the required permissions to perform their operations.

This involves executing a SQL script against the Configuration Manager site database. The script will specifically grant the “Execute” permission on the spGetLockState stored procedure to the appropriate security principal representing the management points. The exact syntax of the SQL script might vary slightly depending on your SQL Server setup and the specific security context of your management points, but a general example of such a script is as follows:

-- Replace <YourManagementPointAccount> with the actual account used by your management point

USE <YourConfigMgrDatabaseName> -- Replace with your ConfigMgr database name
GO

GRANT EXECUTE ON spGetLockState TO <YourManagementPointAccount>
GO

Important Considerations:

• Identify the Management Point Account: You need to accurately identify the SQL Server account under which your remote management points are running. This might be a domain account, a local system account, or a network service account, depending on your Configuration Manager configuration and security practices. Incorrectly specifying this account will render the permission grant ineffective.
• Database Context: Ensure you execute the script against the correct Configuration Manager site database. Applying the permission to the wrong database will not resolve the issue.
• SQL Server Permissions: You will need to execute this SQL script using an account that has sufficient permissions within SQL Server to grant permissions on database objects. Typically, a SQL Server administrator account or an account with database owner (db_owner) rights on the Configuration Manager database would be required.
• Testing and Verification: After executing the script, it’s advisable to test the server group servicing process again to verify that the errors are resolved and that clients are no longer sending excessive Topic ID 611 state messages. Monitoring the MP_ClientID.log file will be crucial to confirm the resolution.

By manually granting the “Execute” rights, you are effectively closing the permissions gap and enabling the remote management points to correctly interact with the spGetLockState stored procedure. This allows the “Service a server group” feature to function as intended, resolving the issue and preventing the generation of excessive state messages. This workaround is the preferred long-term solution if you plan to utilize the server group servicing capabilities of Configuration Manager.

It is also worth noting that applying service updates or cumulative updates to Configuration Manager might potentially address this permission issue in future releases. Reviewing the release notes of any updates you apply is recommended to see if this issue is explicitly addressed and if the manual permission grant workaround is still necessary after applying the update.

If you continue to experience issues after applying these workarounds, or if you require further assistance, consider consulting the official Microsoft Configuration Manager documentation, community forums, or contacting Microsoft support for more in-depth troubleshooting and guidance tailored to your specific environment.

We encourage you to share your experiences and any further insights you may have in the comments below. Your contributions can help other administrators facing similar challenges in their Configuration Manager deployments.