Inspired by this blog post from 2011, I set about fixing my customers new ConfigMgr 2012 R2 implementation today. The situation is this:

An OSD Task sequence references a driver package (or several) and upon starting the task sequence it fails to run with no specific message. However when you check the SMSTS.log file you see the following:

Failed to find CCM_SoftwareDistribution object for AdvertID="AB1201A2", PackageID="AB100005", ProgramID="*"


Failed to resolve selected task sequence dependencies. Code(0x80040104)

“How can that be?” you say, the console shows clearly that the driver package is distributed to the distribution point being used. If you run a validation on the content on your distribution point you will see in status message queries that the validation fails. Well it seems there may be big amongst us although I need to test further to identify common conditions in order to reproduce it. Essentially it seems that upon initial creation of the driver package, a content hash is not created in the database. When you run the validation it will compare hash values stored in WMI on the distribution point against the hash values stored in the site database to ensure that the content is the same, without a hash in the site database there is obviously going to be a mismatch. A little searching around the web shows that content hash mismatching is not a new ‘feature’ and there have been issues around this in the past so I guess this is just another manifestation.

You can see in the ConfigMgr database that the hash field is empty by looking in the SMSPackages_G table. All the usual warnings and disclaimers apply to cracking open your ConfigMgr database – don’t do it if you can’t fix it yourself! Either through the SQL management studio interface with a right click, select or by running the following query:

SELECT *  FROM [CM_LAB].[dbo].[SMSPackages_G]
  WHERE NewHash = ‘’

This will return you all of the packages that currently have no value in the NewHash field. You will also see a version number on the HashVersion field. This will allow you to identify which of your packages have fell foul of this ‘bug’.

To get around this you should simply select your troublesome packages in the console and right click ‘Update Distribution Points’. I’m not aware of a powershell cmdlet for this yet. This will generate a new hash version which you can check with the above SQL query, the number of results should start to reduce.

Once complete you should be good to run your task sequence again and continue your OSD journey!