SCCM 2012R2 – My Clients aren’t getting a deployment.

The Question: 

Recently during some other unfortunate SCCM shenanigans someone brought up the fun problem where they thought that software was randomly hit or miss deploying to machines in a collection. They even thought in some cases the software was installing but not reporting back that it had installed. Now reading that last sentence I’m shaking my head REALLY hard in fact I’m sure you are too and not just because of my terrible grammar.

The Resolution:

First things first, let’s set the record straight the root cause of one of the above described “issues” was that the software was being installed by ANOTHER third party item that was involved in this mash up.

“But problem resolution guy, that’s only HALF the problem”

Oh right the other issue where SCCM isn’t actually doing anything well this should be easy lets go ahead and look at some logs! So off I went to a client to read some logs, sure enough I’m reading along and as I’m reading I notice… well nothing. Nothing jumps out at me in big red letters, nothing is “broken” but what I also notice is that even after being told to update it’s machine policy the machine never receives a policy or any kind of instruction to install the software that it’s being targeted with. That throws up a big shiny red flag and after reading some logs on the server side of the house – statesys and statmsgr logs and seeing no failures I figure it’s time to head off to SQL and take a look to see if SQL even created a policy for the machine to pick up.

First things first I picked  a machine out of the collection the software is being deployed too, lets call it TESTBOX01 and I queried the DB for his ItemKey

select ItemKey from System_DISC where name0 = ‘TESTBOX01’

This returns just the ItemKey for the machine named ‘TESTBOX01’ alternatively you could use * in place of ItemKey and return the full row but I like to minimize what I ask the Data base for when possible.

Then I cracked open my trusty SCCM Console and navigate to the software deployment in question and collect the Deployment ID for example it looks like this: ‘{A7056249-DC44-4DEB-A25D-3821576EB836}’ if you don’t know how to find this go to an application, go to the deployment tab and right click the bar at the top and tell it to display the Deployment ID.


In the above I’ve already allowed the Deployment ID to be visible. If you right click on the white space to the right you will receive the following displayable columns and can select “Deployment ID”.


Assuming you have a deployment you will then see the deployment ID become populated like so:


Using this we can now go check to see if a policy has been created for this machine. Using a little SQL Magic we connect to the primary server that our test box is a child of and opening SQL we lob this at it to get what’s called the PADBID.

select * from PolicyAssignment where PolicyId = ‘{A7056249-DC44-4DEB-A25D-3821576EB836}’


The PADBID ID code will then be returned (Alternatively you can just replace * with PADBID) this ID code is the unique identifier for the deployment and is used to generate the policy that is deployed to a workstation. Once we have the PADBID and the Machine ItemKey we can then test to see if a resultant policy for THIS application for THIS machine has been made by running:

select * from respolicyMap where PADBID = ‘20293425’ and machineid = ‘50336867’

This will then pull out the resultant policy map for that specific machine with that specific deployment. This is the moment of truth.When you’re reading SCCM logs and it says “checking for machine policy” this is one of the things it’s looking for. If the data comes back and you have a resultant policy then one of the following is true:

  1. The root cause is client based and the client cannot properly talk to the SCCM server.
  2. The root cause is Management Point based and the client is not able to properly communicate to the MP – you should have already ruled this out though with a review of the state logs.
  3. The client has a duplicate GUID that is confusing what advertisements the machine should get.

If however it comes back and there is NO resultant policy for the machine it means you have some form of SQL performance issue. In MOST cases the root cause will be that SQL has not indexed recently either via a scheduled maintenance task in SQL or the built in SCCM maintenance task dependent on your environment. In this particular case one of my servers had stopped indexing due to a bad configuration parameter that had been put in place which caused it to be very very angry.


If you’re having deployment problems I feel bad for you son, I got 99 problems but SQL ain’t one.

In short this will allow you to to prove out what the root cause is for a machine not getting deployments. In my case this has become routine for me when someone complains that their deployment group isn’t getting deployments properly. What we’ve done here by following these steps is taken a situation where:

  • Someone has made a proper deployment and pushed it to the environment.
  • That deployment has machines in it and the deployment is active but no machines are receiving the deployment.

Which has a large number of possibilities and removed them. By doing this we have effectively determined: Is this a SQL issue a CLIENT issue or a deployment configuration issue and nine times out of ten? It’s not a SQL problem.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: