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:¬†

DPstats

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:
http://blogs.technet.com/b/configmgrteam/archive/2013/07/17/issues-reported-with-ms13-052-kb2840628-and-configmgr.aspx

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'”
{/code}

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

 

ConfigMgr : Deployment Update Failed 80091007

Strange one this… I recently released a new version of a product in ConfigMgr, configured supersedence and waited for the defined uninstall/update to occur – only it didn’t. The software appeared to download on the client as expected (both old and new version) and then without any update in AppEnforce.log the deployment failed with an 80091007 error code.

On further investigation CAS.log contained the following:

{code lang:ini showtitle:false lines:false hidden:false}Download completed for content Content_1a0a6203-e945-4228-911c-3e3f7b6082aa.1 under context System ContentAccess 21/07/2013 16:48:36 9600 (0x2580)
Computed hash: 5AEBBE1E909AF384387E804ABCE3C8C71BBA007B433731766C0734EE44A28938 ContentAccess 21/07/2013 16:48:36 9600 (0x2580)
Failed to do hash verification with preference : 4. Try to verify at next hash algorithm ContentAccess 21/07/2013 16:48:36 9600 (0x2580)
Download failed for content Content_1a0a6203-e945-4228-911c-3e3f7b6082aa.1 under context System, error 0x80091007 ContentAccess 21/07/2013 16:48:36 9600 (0x2580){/code}

Content hash verification had failed.. strange as the MSI had been tested and was working. I simply updated the deployment content , waited for this to distribute and tested again without issue…!