Branch DP’s and Hash Values

How can I find the package hash value in WMI on a BDP:

1. Open Webemtest and connect to root\ccm

2. Select Enum Classes, click the recursive radio button press OK

3. Scroll down to ccm_peerdpagent and double click

4. select ccm_peerdp_job and click instances.

5. click a package packageID listed.

6. Scroll Down to the hash value.

Compare this value in WMI to the Hash value that you find on the Distribution Point for the same package. To get the hash value for the distribution point content use a tool called hashdir.exe. (This is an internal tool so you would need to contact your PFE DSE for it). Compare the two hashes above with the 40 character Sha1 hash that is listed in the “NewHash” column of the SMSPackages Table of the database. Obviously these should all be the same.

What is the BDPTmpWrkFldr?

There are three folders that come into play here, they are listed below in this order:

Needs Folder

Assemble Folder

Content Folder

The flow from one folder to the next is like this:

Flow—–>Needs Folder—–>Assemble Folder—->Content Folder

1. BDPTmpWrkFldr\PDP5DB1.tmp – AKA “Needs” folder used by the Content Transfer Manager where deltas and needs files are downloaded and saved to, before being compiled and sent to the Assemble folder, this folder is deleted after it has been utilized.

2. BDPTmpWrkFldr\PDP5D91.tmp – AKA “Assemble” folder, Delta and needs files are brought in to the Assemble folder once downloaded to the Needs folder and then merged (or assembled). Once we have hash successes here we then copy to SMSPKG$.

3. SMSPKG$ – AKA “Content” folder, this is where the content is actually stored for client retrieval after the deltas have been merged and hash has been verified from content in the Assemble folder.

In this Short example from CTM log we will find the Needs folder is referenced first then the Assemble folder. The merge delta operation occurs in the next log entry in the Assemble folder. Both folders are created with a naming convention of PDP****.tmp

CCMRDC] GenerateTargetFile() called with OldFile as “F:\SMSPKGF$\UP10004A\Patches\WINDOWS_VISTA\Windows6.0-KB960225-x86.msu”,

NeedsFile as “F:\BDPTmpWrkFldr\PDP5DB1.tmp\work\Patches\WINDOWS_VISTA\Windows6.0-KB960225-x86.msu .needs”,

0 Deltafiles and AssembledFile as “F:\BDPTmpWrkFldr\PDP5D91.tmp\Patches\WINDOWS_VISTA\Windows6.0-KB960225-x86.msu”

CMergeDeltaOperation::_ProcessFile – Created merged file F:\BDPTmpWrkFldr\PDP5D91.tmp\Patches\WINDOWS_VISTA\Windows6.0-KB960225-x86.msu. ContentTransferManager 7/28/2009 5:18:16 PM 7380 (0x1CD4)

What’s the difference between “Hash failed for package” and a “PDPHashMismatchEvent”?

“Hash failed for package” is shown when the current version of the ALREADY LOCALLY stored package does not match the stored package hash. If we get this message it indicates for the BDP to NOT download a delta but instead download the full current needed version of the package. Redownloading content is not so much as a “retry” but instead an indicator that we need the full content and not just the deltas.

Example of Hash Failed for Package:

Checking provisioning status for package = UP10004A, version = 3. PeerDPAgent 2/7/2009 1:20:46 PM 7660 (0x1DEC

Hash failed for package UP10004A. Redownloading content. PeerDPAgent 2/11/2009 5:43:33 PM 6312 (0x18A8)

Package UP10004A in state ‘UpdatingPackage’. PeerDPAgent 2/11/2009 5:43:33 PM 6312 (0x18A8)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPDownloadStartedEvent

{

ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090211234333.305000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP10004A”;

ProcessID = 2212;

SiteCode = “UP1”;

SourceVersion = 4;

ThreadID = 6836;

};

PeerDPAgent 2/11/2009 5:43:33 PM 6836 (0x1AB4)

Package UP10004A in state ‘Downloading’. PeerDPAgent 2/11/2009 5:43:33 PM 6836 (0x1AB4)

Download complete for CTM job {C2D4DFC8-670F-44A6-8332-88A0F1D3710B}, downloaded KB 8291 PeerDPAgent 2/11/2009 5:44:36 PM 7396 (0x1CE4)

Package UP10004A in state ‘DownloadComplete’. PeerDPAgent 2/11/2009 5:44:41 PM 7396 (0x1CE4)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPDownloadSuccessEvent

{

ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090211234450.011000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP10004A”;

ProcessID = 2212;

SiteCode = “UP1”;

SourceVersion = 4;

ThreadID = 6028;

};

PeerDPAgent 2/11/2009 5:44:50 PM 6028 (0x178C)

Package UP10004A in state ‘HashContentSuccess’. PeerDPAgent 2/11/2009 5:44:50 PM 6028 (0x178C)

Package UP10004A in state ‘HostingComplete’. PeerDPAgent 2/11/2009 5:44:58 PM 7396 (0x1CE4)

Package UP10004A in state ‘Succeeded’. PeerDPAgent 2/11/2009 5:44:58 PM 1800 (0x0708)

Note the version number above is “3” Before we update the package above from 3 to 4 we rehash the content. The Hash failed for content so instead of grabbing a Delta update we download the full 4 content.

A “PDPHashMismatchEvent” is shown when the content that we downloaded from the DP fails the hash match immediately after the content was downloaded. In the example below we did in fact attempt to redownload the package however the hash once again failed.

Here is an example of “PDPHashMismatchEvent”:

Package UP100035 in state ‘Downloading’. PeerDPAgent 4/27/2009 7:30:28 PM 6028 (0x178C)

Download complete for CTM job {772B7EAF-D420-4D6B-B421-45B7226A2D0B}, downloaded KB 4961 PeerDPAgent 4/27/2009 7:30:50 PM 1908 (0x0774)

Package UP100035 in state ‘DownloadComplete’. PeerDPAgent 4/27/2009 7:30:50 PM 1908 (0x0774)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPHashMismatchEvent

{

ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090428003051.129000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP100035”;

ProcessID = 672;

SiteCode = “UP1”;

SourceVersion = 5;

ThreadID = 5792;

};

PeerDPAgent 4/27/2009 7:30:51 PM 5792 (0x16A0)

Package UP100035 in state ‘HostingIncomplete’. PeerDPAgent 4/27/2009 7:30:51 PM 5792 (0x16A0)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPPkgDeleteEvent

{

ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090428013514.996000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP100035”;

ProcessID = 672;

Share = “”;

SiteCode = “UP1”;

SourceVersion = 5;

ThreadID = 4724;

};

PeerDPAgent 4/27/2009 8:35:14 PM 4724 (0x1274)

We did in fact retry again and failed the hash again at 10:40:51

Package UP100035 in state ‘DownloadComplete’. PeerDPAgent 4/27/2009 10:40:51 PM 5244 (0x147C)

Raising event:

[SMS_CodePage(437), SMS_LocaleID(1033)]

instance of PDPHashMismatchEvent

{

ClientID = “GUID:BF41F222-3D9A-4AD6-ABDF-A8E301068C76”;

DateTime = “20090428034051.189000+000”;

MachineName = “WAK-FS-01”;

PackageID = “UP100035”;

ProcessID = 672;

SiteCode = “UP1”;

SourceVersion = 5;

ThreadID = 4168;

};

PeerDPAgent 4/27/2009 10:40:51 PM 4168 (0x1048)

Package UP100035 in state ‘HostingIncomplete’. PeerDPAgent 4/27/2009 10:40:51 PM 4168 (0x1048)

Why we still do MD5 hash in Config Manager as the SHA1 hash has not been used for content security since SMS 2003 RTM?

We use this value as a quick integrity check as it’s very fast. Something to note is that the older MD5 Hashes are always 32 characters in length and corresponds to the “Hash” column in the SQL Database. Newer (as of SMS 2003 SP1 and Config Mgr) and more secure SHA1 hashes are always 40 characters in length and correspond to the “New Hash” column in the SQL DB.

Troubleshooting application deployment issues – Tips

If you experience any of the following problems, check these recommended troubleshooting steps and information.

Problem 1 – application download failures:
Client stuck downloading an application
Client failed to download application
Client stuck at 0% while downloading software

Possible solutions and troubleshooting information:
Missing or misconfigured boundaries and boundary groups: If the client is on the intranet and is not configured for Internet-only client management, the client’s network location must be in a configured boundary and there must be a boundary group assigned to this boundary for the client to be able to download content. For more information about boundaries and boundary group, see the following TechNet information.

Planning for Boundaries and Boundary Groups: http://technet.microsoft.com/en-us/library/gg712679.aspx. Configuring Boundaries and Boundary Groups: http://technet.microsoft.com/en-us/library/hh427326.aspx

Content might not be distributed to the distribution points yet, which is why it is not available for clients to download. Use the in-console monitoring facilities to monitor content distribution to the distribution points. For more information about monitoring content, see the following blog post: http://blogs.technet.com/b/inside_osd/archive/2011/04/06/configuration-manager-2012-content-monitoring-and-validation.aspx

Problem 2 – application deployment compliance stuck at 0%

Possible solution and troubleshooting information:
When compliance is 0%, check for the following deployment status for the application in the Monitoring workspace, Deployments node:
“In progress”: The client could be stuck downloading content. Check problem 1, above.
“Error”: For more information about this status, see the following blog post: http://blogs.technet.com/b/configmgrteam/archive/2012/03/23/tips-and-tricks-how-to-take-action-on-assets-that-report-a-failed-deployment-in-system-center-2012-configuration-manager.aspx

“Unknown”: This implies that the client has not received policy. Try manually initiating client policy and if this does not work, use client status to help verify client functionality. For more information, see the following TechNet information: Initiate Policy Retrieval for a Configuration Manager Client: http://technet.microsoft.com/en-us/library/gg712288.aspx#BKMK_PolicyRetrieval Monitoring the Status of Client Computers in Configuration Manager: http://technet.microsoft.com/en-us/library/gg682132.aspx#BKMK_ClientHealth