ConfigMgr : KB2840628 Workaround and Taking Control of a CONFIGMGRSEC Database

Came up against the known ConfigMgr issues associated with KB2840628 today. Initially I noticed that one of the Distribution Point Groups I have was showing content replication for a large number of packages as ‘In Progress’ – these dated back over the last few days: 


So I then noticed that the Database Replication for the Secondary Site where these Distribution Points were had failed. Digging a little deeper I had a strange .Net error in rcmctrl.log on the Secondary Site server:

{code lang:text showtitle:false lines:false hidden:false}Asynchronous command finished with return message: [A .NET Framework error occurred during execution of user-defined routine or aggregate “spDRSActivation”: ~~System.TypeInitializationException: The type initializer for ‘System.Data.SqlClient.SqlConnection’ threw an exception. —> System.TypeInitializationException: The type initializer for ‘System.Data.SqlClient.SqlConnectionFactory’ threw an exception. —> System.TypeInitializationException: The type initializer for ‘System.Data.SqlClient.SqlPerformanceCounters’ threw an exception. —> System.MethodAccessException: Attempt by method ‘System.Configuration.TypeUtil.CreateInstanceRestricted(System.Type, System.Type)’ to access method ‘System.Diagnostics.SwitchElementsCollection..ctor()’ failed. —> System.Security.SecurityException: Request failed.~~System.Security.SecurityException: ~~ at System.Security.CodeAccessSecurityEngine.ThrowSecurityException(RuntimeAssembly asm, PermissionSet granted, PermissionSet refused, RuntimeMethodHandleInternal rmh, SecurityAction action, Object demand, IPermission permThatFailed)~~ at System.Security.CodeAccessSecurityEngine.CheckSetHelper(PermissionSet grants, PermissionSet refused, PermissionSet demands, RuntimeMethodHandleInternal rmh, Object assemblyOrString, SecurityAction action, Boolean throwException)~~ at System.Security.PermissionListSet.CheckSetDemandWithModification(PermissionSet pset, PermissionSet& alteredDemandSet, RuntimeMethodHandleInternal rmh)~~ at System.Security.PermissionListSet.CheckSetDemand(PermissionSet pset, RuntimeMethodHandleInternal rmh)~~ at System.Security.PermissionListSet.DemandFlagsOrGrantSet(Int32 flags, PermissionSet grantSet)~~ at System.Security.CodeAccessSecurityEngine.ReflectionTargetDemandHelper(Int32 permission, PermissionSet targetGrant)~~System.TypeInitializationException: ~~ at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()~~ at Microsoft.ConfigurationManager.DataReplicationService.DatabaseOperation.ExecuteNonQuery(String commandText)~~ at Microsoft.ConfigurationManager.DataReplicationService.MessageHandl…].{/code}

More info available on this known issue here:

The supplied workaround required using SQL Management Studio to perform the following:

SQL Server -> Databases -> (Site Database) -> Programmability -> Assemblies -> MessageHandlerService ->Right-click and select Properties and highlight -> General -> Expand the “Permissions Set” drop-down -> Select Unrestricted.
When the change is made, replication between sites should automatically recover within 5-10 minutes.

Also, the same is required for the SMSSQLCLR assembly Permission; SQL Server -> Databases -> (Site Database) -> Programmability -> Assemblies -> SMSSQLCLR

Of course, when ConfigMgr deploys a Secondary Site SQL instance there is a limited set of users defined that have SYSADMIN access to the instance. To perform this changes I needed SYSADMIN access.

Using the SysInternals tools, specifically PSExec I was able to grant myself these permissions:

{code lang:text showtitle:false lines:false hidden:false}:: Launch cmd.exe via PSexec in SYSTEM Context
psexec -s cmd

:: Create new login and add to SYSADMIN role
osql -E -S SRV1\INSTANCE -Q “sp_grantlogin ‘DOMAIN\user'”
osql -E -S SRV1\INSTANCE -Q “sp_addsrvrolemember @loginame=’DOMAIN\user’, @rolename=’sysadmin'”

I could then make the required changes – once completed the content that was stuck ‘In Progress’ slowly transitioned to a ‘Success’ status.


Leave a Reply

Your email address will not be published. Required fields are marked *