none
Content Download Failed: Content mismatch RRS feed

  • Question

  • Hello Everyone, I've been having issues recently with pushing packages out to my distribution points.

    I am running ConfigMgr 2007 SP1 R2.

    For many of the packages, I am receiving the following message:

    Content Download for the package"RH100002" - "31" failed.  The download failed because the content downloaded to the client does not match the content specified in the package source.

    Two of the packages that are having issues deploying are the x64 and x86 boot images.  Others are simple apps like a Lenovo Trackpoint application. 

    I've done a generous amount of Googling as well as searching of this forum.  Many of the threads I am finding are regarding distributing a package to a PC for installation, whereas this is just to get the package staged on the BDP.

    Before I ultimately delete the package from the BDP and redistribute, is there somewhere I can check to find out what is causing this issue?

    Thanks in advance,
    Sean
    Thursday, May 14, 2009 4:20 PM

Answers

  • Well, I think I came to a resolution to this problem without having to call Microsoft.

    Preface all of this with a factor I never considered in all this troubleshooting.  This is the first time I've updated the x64 boot image since I upgraded to SP1R2.

    After tinkering around for a while longer, I ended up stumbling upon the Boot Image's "Images" tab.  On there, I noticed that the creation date, and OS version were old.  They still listed the information about the WIM that was provided by the original installation of ConfigMgr.  After clicking the reload button, it examined the new wim that was installed during the SP1 install, and updated the Images tab to reflect the new version and date of the source boot wim.

    I then updated the package and redeployed.  So far, I've had 2 BDP's stage the x64 Boot Image that were getting the error message stated at the start of this thread.  I suspect the rest will follow suit over the weekend (I'm hoping that is the case.)

    Thanks again for everyone who provided input on this.

    Sean
    • Marked as answer by seanka79 Friday, May 29, 2009 9:18 PM
    Friday, May 29, 2009 9:15 PM

All replies

  • You could manually copy the pck files to the problematic DP and use preloadpkgonsite.exe to ensure the correct files are there and the correct version number is stored in the DB. Or just remove the package and resend it.
    John Marcum, Systems Management Architect - www.TrueSec.com
    Thursday, May 14, 2009 4:44 PM
    Moderator
  • Interesting, I haven't been doing the compresed copy option.  Do you think it would be wise to move to that option instead of "always obtain files from the source directory?"

    Thanks,
    Sean

    Thursday, May 14, 2009 4:49 PM
  • Seems that version of the package the client is expecting to get from the policy it received does not match the content version on a particular DP/BDP (or some combination of them).

    Have you tried updating the problematic DP/BDP from the AdminUI?

    If you have, can you try again and monitor distmgr.log for errors?
    Thursday, May 14, 2009 6:48 PM
    Moderator
  • That has nothing to do with the option (compressed copy) you just mentioned.

    John: he is talking about a BDP, so preloadpkgonsite.exe won't help here. You could try http://technet.microsoft.com/en-us/library/bb681046.aspx instead.
    Thursday, May 14, 2009 6:50 PM
    Moderator
  • sorry I missed the "B"
    John Marcum, Systems Management Architect - www.TrueSec.com
    Friday, May 15, 2009 1:15 PM
    Moderator
  • Thanks for the feedback guys.

    Ideally, I'd like to get the replication feature working properly instead of pre-staging the packages onsite. 

    I think what I'm going to do is just delete the package off of one of the servers, then try redistributing it to see if it resolves the problem.  Fortunately, I have a test BDP here in the same building as the the main DP.  So, I'll give that a shot and get back to you guys later today.

    Sean
    Friday, May 15, 2009 1:34 PM
  • Here's a quick update.

    Well, I have tried a few things with no success.  I removed the BDP from a package, performed a BDP Maintenance task and waited for the package to dissappear from the SMSPKGC$ folder.  Then, I re-added the BDP to the package and re-initiated the BDP Maintenance task on the BDP.  The package never ended up getting distributed to the machine, instead I had a re-occurance of the "client does not match" error.

    So, to go even more extreme, I completely removed the Site System role from the BDP and demoted it back to a regular PC.

    After the roles and everything associated with it were cleared from the device, I recreated it as a BDP and pushed ONLY the package that has been giving me the issues (the x64 boot image).

    After a while, the package deployment failed again with the same error.  There's some snippits from the different logs below, hopefully they may help shed some light.  All in all they look "clean."  There aren't any errors indicating that there was something wrong distribution-wise.

    I'm at a complete loss with this, if anyone can help I'd be grateful.

    Sean


    PeerDPAgent.log

    Created Branch DP job {C4D94994-605A-461A-B090-1A5DB3C31009} for package RH100002 PeerDPAgent 5/18/2009 11:31:50 AM 636 (0x027C)

    Package RH100002 in state 'Starting'. PeerDPAgent 5/18/2009 11:31:51 AM 636 (0x027C)

    Raising event:
    [SMS_CodePage(437), SMS_LocaleID(1033)]
    instance of PDPBITSConfigChanged
    {
     ClientID = "GUID:95EA21F7-B75C-4980-A877-9663A2243AD9";
     DateTime = "20090518163151.255000+000";
     MachineName = "ARIZONADIST";
     ProcessID = 1176;
     SiteCode = "RH1";
     ThreadID = 1240;
    };
     PeerDPAgent 5/18/2009 11:31:51 AM 1240 (0x04D8)

    Raising event:
    [SMS_CodePage(437), SMS_LocaleID(1033)]
    instance of PDPDownloadStartedEvent
    {
     ClientID = "GUID:95EA21F7-B75C-4980-A877-9663A2243AD9";
     DateTime = "20090518163151.443000+000";
     MachineName = "ARIZONADIST";
     PackageID = "RH100002";
     ProcessID = 1176;
     SiteCode = "RH1";
     SourceVersion = 31;
     ThreadID = 2180;
    };
     PeerDPAgent 5/18/2009 11:31:51 AM 2180 (0x0884)

    Package RH100002 in state 'Downloading'. PeerDPAgent 5/18/2009 11:31:51 AM 2180 (0x0884)

    Checking provisioning status for package = RH100002, version = 31. PeerDPAgent 5/18/2009 11:59:44 AM 3828 (0x0EF4)

    Download complete for CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5}, downloaded KB 141595 PeerDPAgent 5/18/2009 2:16:45 PM 3204 (0x0C84)

    Package RH100002 in state 'DownloadComplete'. PeerDPAgent 5/18/2009 2:16:45 PM 3204 (0x0C84)

    Raising event:
    [SMS_CodePage(437), SMS_LocaleID(1033)]
    instance of PDPHashMismatchEvent
    {
     ClientID = "GUID:95EA21F7-B75C-4980-A877-9663A2243AD9";
     DateTime = "20090518191647.558000+000";
     MachineName = "ARIZONADIST";
     PackageID = "RH100002";
     ProcessID = 1176;
     SiteCode = "RH1";
     SourceVersion = 31;
     ThreadID = 3916;
    };
     PeerDPAgent 5/18/2009 2:16:47 PM 3916 (0x0F4C)

    Package RH100002 in state 'HostingIncomplete'. PeerDPAgent 5/18/2009 2:16:47 PM 3916 (0x0F4C)



    ContentTransferManager.log

    Starting CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5}. ContentTransferManager 5/18/2009 11:31:51 AM 2180 (0x0884)

    Created CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5} for user S-1-5-18 ContentTransferManager 5/18/2009 11:31:51 AM 2180 (0x0884)

    CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5} entered phase CCM_DOWNLOADSTATUS_DOWNLOADING_DATA ContentTransferManager 5/18/2009 11:31:51 AM 3344 (0x0D10)

    Persisted locations for CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5}:
     (LOCAL) http://SCCMSERVER/SMS_DP_SMSPKGD$/RH100002
     (LOCAL) file:\\SCCMSERVER\SMSPKGD$\RH100002 ContentTransferManager 5/18/2009 11:31:51 AM 636 (0x027C)

    CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5} (corresponding DTS job {1F0DB4DD-A9A3-436F-9679-BA39FD1A6744}) started download from 'http://SCCMSERVER/SMS_DP_SMSPKGD$/RH100002' ContentTransferManager 5/18/2009 11:31:51 AM 636 (0x027C)

    Persisted locations for CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5}:
     (LOCAL) http://SCCMSERVER/SMS_DP_SMSPKGD$/RH100002
     (LOCAL) file:\\SCCMSERVER\SMSPKGD$\RH100002 ContentTransferManager 5/18/2009 11:59:46 AM 3828 (0x0EF4)

    Persisted locations for CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5}:
     (LOCAL) http://SCCMSERVER/SMS_DP_SMSPKGD$/RH100002
     (LOCAL) file:\\SCCMSERVER\SMSPKGD$\RH100002 ContentTransferManager 5/18/2009 12:59:48 PM 3896 (0x0F38)

    Persisted locations for CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5}:
     (LOCAL) http://SCCMSERVER/SMS_DP_SMSPKGD$/RH100002
     (LOCAL) file:\\SCCMSERVER\SMSPKGD$\RH100002 ContentTransferManager 5/18/2009 1:59:49 PM 3716 (0x0E84)

    CTM job {B6D293B6-AD1D-4A9E-A0E0-A8B3662276D5} successfully processed download completion. ContentTransferManager 5/18/2009 2:16:45 PM 3204 (0x0C84)

    Monday, May 18, 2009 7:42 PM
  • Another quick update.  Just for the heck of it, I tried re-deploying two packages that I thought I wasn't having problems with, and they deployed without any problems. 

    I'm going to try to add a driver to the x64 boot image to see if I can modify the WIM and have it re-deploy.  I'm hoping that will fix this issue.
    Monday, May 18, 2009 8:16 PM
  • Alrighty, another update.

    I added a new driver to the x64 Boot image and updated all distribution points.  After two hours on several of the BDP's, I received the same error again.

    As a side note, after updating the image with a new file and updating the BDP's, the Distmgr.log file on the ConfigMgr server had several of the following items:

    Removing all the signatures for package RH100002 with version at or lower than 30
    DeletePackageSignatures() called for package RH100002 
    Unpacked folder for package version RH100002.21 is being used by 1 user(s) currently
    Unpacked folder for package version RH100002.21 is being used by 1 user(s) currently
    Unpacked folder for package version RH100002.22 is being used by 1 user(s) currently
    Unpacked folder for package version RH100002.22 is being used by 1 user(s) currently
    Unpacked folder for package version RH100002.23 is being used by 1 user(s) currently
    Unpacked folder for package version RH100002.23 is being used by 1 user(s) currently
    Unpacked folder for package version RH100002.27 is being used by 1 user(s) currently
    Unpacked folder for package version RH100002.27 is being used by 1 user(s) currently
    UnRegisterSignatureUsage() called for Package RH100002, Version 31 with TargetPath as D:\SMSPKGD$\RH100002\
    Unpacked folder for package version RH100002.31 is not being used by any user. It will be deleted now.

    Would you guys think that there are some BDP's which are still trying to distribute the older versions of these packages since RH100002.21, 22, 23 and 27 are all old packages and the current version is .32?  Could it be possible that ConfigMgr is pushing out the older version to these BDP's and that is why I'm getting these errors?  How can I find out if the older versions are getting pushed instead of the correct, .32, version?

    I'm completely out of ideas now, any advice would be greatly appreciated.

    Thanks again!
    Sean

    Tuesday, May 19, 2009 2:16 PM
  • Do you guys know if there is a tech support contact with Microsoft that I can contact via email, or something like that which would not incur a support charge through our Software assurance program?
    Tuesday, May 19, 2009 8:27 PM
  • Most SA agreements get a certain number of free support calls per year. I think email support is free also but I could be wrong. And I see that there's STILL not a link for SCCM on the support page. I use the SMS 2003 one, seems like they would have fixed that by now!

    http://support.microsoft.com/select/default.aspx?target=hub&c1=508&


    If you don't get anywhere that way I would be happy to setup a live session with you and take a look at it for you.






    John Marcum, Systems Management Architect - www.TrueSec.com
    Tuesday, May 19, 2009 8:36 PM
    Moderator
  • Did you try this?

    http://technet.microsoft.com/en-us/library/bb681046.aspx



    John Marcum, Systems Management Architect - www.TrueSec.com
    Tuesday, May 19, 2009 8:41 PM
    Moderator
  • Unfortunately, yeah I did try that. I copied the package folder directly from the site server to the BDP and initiated the BDP Maintenance Task... still received the same error message when re-deploying.

    I'm considering re-doing the x64 boot image and re-deploying it out to the BDP's so that it has a completely different package number, but that's kind of avoiding what the original problem was, you know what I mean?

    I just tried to "update" the package again and now I'm receiving this error:

       Error: Boot image to update: 
    	Microsoft Windows Vista PE (AMD64)
    
       Error: Actions to perform: 
    	Add ConfigMgr binaries
    	Enable Windows PE command line support
    	Add drivers
    
       Error: Failed to import the following drivers:
    	Intel(R) 82801EB Ultra ATA Storage Controllers
    	Intel(R) 631xESB/632xESB SATA RAID Controller
    	Intel(R) 631xESB/632xESB SATA RAID Controller
    	Intel(R) 631xESB/632xESB SATA RAID Controller
    	Intel(R) PRO/1000 PT Dual Port Network Connection
    	Intel(R) PRO/1000 PT Dual Port Network Connection
    	Intel(R) PRO/1000 Gigabit Server Adapter
    	Intel(R) PRO/1000 PT Dual Port Network Connection
    	Intel(R) PRO/1000 MT Desktop Adapter
    	Intel(R) PRO/1000 PT Dual Port Network Connection
    	Intel(R) PRO/1000 MT Desktop Adapter
    	Intel(R) 82801FBM SATA AHCI Controller
    	Intel(R) 631xESB/632xESB SATA RAID Controller
    	Intel(R) 82801FBM SATA AHCI Controller
    	Intel(R) 631xESB/632xESB SATA RAID Controller
    	3Com Dual Port 1000-SX PCI-X Server NIC
    	3Com 10/100/1000 PCI
    	Intel(R) 82567LM-3 Gigabit Network Connection
    	Intel(R) 82567LM-3 Gigabit Network Connection
    
       Error: The wizard detected the following problems when updating the boot image.
    	Failed to insert OSD binaries into the mounted WIM file
    	The ConfigMgr Provider reported an error.: ConfigMgr Error Object:
    	instance of SMS_ExtendedStatus
    	{
    		Description = "Failed to insert OSD binaries into the WIM file";
    		ErrorCode = 2152205056;
    		File = "e:\\nts_sms_fre\\sms\\siteserver\\sdk_provider\\smsprov\\sspbootimagepackage.cpp";
    		Line = 3824;
    		ObjectInfo = "CSspBootImagePackage::PreRefreshPkgSrcHook";
    		Operation = "ExecMethod";
    		ParameterInfo = "SMS_BootImagePackage.PackageID=\"RH100002\"";
    		ProviderName = "WinMgmt";
    		StatusCode = 2147749889;
    	};
    Tuesday, May 19, 2009 8:46 PM
  • That error has nothing to do with a BDP. The siteserver tries to add drivers to the boot image and fails for some reasons ...
    Are there any details in the ConfigMgr console's logfiles (\adminui\adminuilog)?
    Tuesday, May 19, 2009 8:57 PM
    Moderator
  • Two things...

    I seem to recall in one of Johan's sessions there's a bug that will keep the boot media mounted after you add drivers to it. You have to manuyally unmount it from imagex to get rid fo the error. I don't recall the command off hand that shows all currently mounted volumes but goole for that and see if the thing is mounted.

    secondly, have you tried to just reboot the server?



    John Marcum, Systems Management Architect - www.TrueSec.com
    Tuesday, May 19, 2009 10:19 PM
    Moderator
  • John, you were right - I could see in Computer Management that the WIM was still open despite the fact that the wizard had completed.  After a reboot of the Site Server, it mounted, injected, and processed the WIM properly.  I've begun the distribution of that package again to see if I have any luck now.  I'll let you guys know in a couple hours.

    In the meantime, does anyone know anything about the SMSSIG folder?  When I looked in that folder, I can still see the .tar files and folders pointing to the Older versions of the package, RH100002.  Is there a query or something that I can run to find what BDP's may be trying to pull those older versions of the Package? 

    Do you think this scenario could be causing the issue - could it be possible that ConfigMgr is copying down the latest version to the BDP's via the SMSPKGD$ folder on the site server (which also serves as a DP) but when it reaches back to verify the package version, perhaps it is seeing the older versions in the SMSSIG folder?  I don't want to just delete them out of the SMSSIG folder because obviously that wouldn't make too much sense.  Configuration manager must be hanging onto the older copies of the package in some way.

    **EDIT**

    Do you guys think there is anything wrong with me moving the tar files out of the SMSSIG folder, the ones I know are *not* good anymore?

    Thanks again,
    Sean
    • Edited by seanka79 Wednesday, May 20, 2009 4:10 PM
    Wednesday, May 20, 2009 3:28 PM
  • this is all i know about that:

    Site servers also have a folder named SMSPKGSIG on drives used for distribution points. This folder is used to download signatures for Microsoft Remote Differential Compression for branch distribution points when performing binary delta downloads from distribution points. Standard distribution points have the SMSSIG$ folder, which contains the package signatures to be used for branch distribution points. SMSSIG$ is created on the drive with the most free space.

    http://technet.microsoft.com/zh-tw/library/bb680614.aspx


    John Marcum, Systems Management Architect - www.TrueSec.com
    Wednesday, May 20, 2009 5:48 PM
    Moderator
  • Hey Everyone,

    The replies that were marked as answers were not answers to the problem in this thread. 

    Nothing has worked to fix this issue.  I am still receiving this error and am unable to distribute the x64 boot image to BDP's. 

    As a result, I'm going to call Microsoft and initiate a ticket to see if I can get this fixed.  When I have the true answer to the problem, I will let you guys know so other people can use this as a resource in the future.
    Wednesday, May 27, 2009 2:06 PM
  • Well, I think I came to a resolution to this problem without having to call Microsoft.

    Preface all of this with a factor I never considered in all this troubleshooting.  This is the first time I've updated the x64 boot image since I upgraded to SP1R2.

    After tinkering around for a while longer, I ended up stumbling upon the Boot Image's "Images" tab.  On there, I noticed that the creation date, and OS version were old.  They still listed the information about the WIM that was provided by the original installation of ConfigMgr.  After clicking the reload button, it examined the new wim that was installed during the SP1 install, and updated the Images tab to reflect the new version and date of the source boot wim.

    I then updated the package and redeployed.  So far, I've had 2 BDP's stage the x64 Boot Image that were getting the error message stated at the start of this thread.  I suspect the rest will follow suit over the weekend (I'm hoping that is the case.)

    Thanks again for everyone who provided input on this.

    Sean
    • Marked as answer by seanka79 Friday, May 29, 2009 9:18 PM
    Friday, May 29, 2009 9:15 PM