Dam Good Admin

Or at least not entirely useless

Server Group Patching: Troubleshooting

I’ve been blogging recently about my experiences with the pre-release Server Group Patching feature.  It didn’t go well but it did give me an opportunity to do some troubleshooting with a senior escalation engineer who showed me a few things.  I couldn’t find any documentation out there on how to troubleshoot this feature so I’ll share what I learned.

Lock States

There are four lock states:

  • Waiting for Lock: 0
  • Have Lock: 1
  • Released Lock: 2
  • Node Script Failed: 3

When a cycle is initiated the clients will all wait for a lock (state 0).  During a cycle the client will execute a GetLockState method every 15 seconds to try and get a lock from the site.  The site then controls who gets a lock (state 1) so that they can patch.  Once a server has the lock they will patch, reboot, and then release the lock (state 2).  That tells the site that a lock is available for the next server.

To the Logs!

This is Configuration Manager where the ethos is that you can never have enough logs.  Sure enough, UpdatesDeployment.log is tracking the lock states for the device.

Here’s a device requesting a lock and getting the wait state:

GetLockState. UpdatesDeploymentAgent 9/14/2017 8:00:00 PM 8700 (0x21FC)
Lock state: 0 UpdatesDeploymentAgent 9/14/2017 8:00:00 PM 8700 (0x21FC)
Waiting for turn to start updates. UpdatesDeploymentAgent 9/14/2017 8:00:00 PM 8700 (0x21FC)

Here’s a device requesting a lock and getting it:

GetLockState. UpdatesDeploymentAgent 9/14/2017 8:00:30 PM 8700 (0x21FC)
Lock state: 1 UpdatesDeploymentAgent 9/14/2017 8:00:30 PM 8700 (0x21FC)
Available to run updates. UpdatesDeploymentAgent 9/14/2017 8:00:30 PM 8700 (0x21FC)

Here’s a device having successfully completed patching:

GetLockState. UpdatesDeploymentAgent 10/27/2017 9:55:47 PM 6916 (0x1B04)
Lock state: 2 UpdatesDeploymentAgent 10/27/2017 9:55:47 PM 6916 (0x1B04)
Available to run updates. UpdatesDeploymentAgent 10/27/2017 9:55:47 PM 6916 (0x1B04)

Here’s a node script failing:

Running: "C:\Windows\system32\WindowsPowerShell\v1.0\PowerShell.exe" -NoProfile -ExecutionPolicy RemoteSigned -File C:\Windows\TEMP\CCM1B08.tmp.ps1
Process completed with exit code 123
Non-zero exit code. 123.
RunPowershellScript() failed. 0x80004005.

Database Query

The support engineer I worked with gave me the information for the query below which lists the current lock states of all devices currently in a cycle.  If you clear the locks from the console these entries are wiped out.

SELECT C.CollectionName, SD.Name0, DM.* FROM DeploymentMutex DM
JOIN SYSTEM_DISC SD ON SD.SMS_Unique_Identifier0 = DM.SMS_Unique_Identifier
JOIN Collections C ON C.CollectionID = DM.CollectionID
ORDER BY C.CollectionName, DM.State Desc

1 Comment

  1. There it not much info out there on this yet. Thanks for the post!

Leave a Reply to Ryan Cancel reply

© 2018 Dam Good Admin

Theme by Anders NorenUp ↑