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.
sccm road 