none
Failed to validate content hash on Distribution Point RRS feed

  • Question

  • Hi

    I begin to see a lot of warnings in "Monitoring -> Distribution Status -> Distribution Point Configuration Status".

    The warning is:

    Message: "Failed to validate content hash"

    Description: "Failed to retrieve the package list on the distribution ["Distribution Point"]. Or the package list in content library does'nt match the one in WMI. Review smsdpmon.log for more information about this failure.

    In smsdpmon.log

    Intializing DP Monitoring Manager... 
    Getting monitoring thread priority
    Getting content library root path
    Getting site code 
    Getting algorithm ID 
    Failed to find algorighm ID from registry. Use default algorithm. 
    Getting DP Cert Type 

    Setting this DP NALPath Set media certificate in transport Set authenticator in transport Start to evaluate ... 

    CContentDefinition::LibraryPackagesWmi: The package data in WMI is not consistent to PkgLib 
    CContentDefinition::LibraryPackagesWmi failed; 0x80004005

    Start to evaluate all packages ... 

    Content Validation is enabled on the DP's.

    Everything seems to work okay but the warning does'nt disappear although some of the the warnings are more than a month old.

    How do I get rid of the warnings...?

    Thursday, May 24, 2012 3:19 AM

All replies

  • Those hash mismatches will not be remediated automatically. You have to redistribute the affected packages manually in order to fix it.

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, May 24, 2012 6:56 AM
  • Hi

    Thanks.

    But one of the affected DP's only have this warning. Everything else is green.

    And the content has been evaluated a lot of times without errors. But the warning does'nt disappear.

    As far as I recall, I even tried to uninstall all the roles and install them again without getting rid of the warning.

    Thursday, May 24, 2012 9:58 AM
  • Hi,

    Thanks again, Torsten.

    This link was very helpful.

    Also noticed this:

    Note: There is currently a known issue in the current release where the warning might not always clear to return the distribution point status back to a success state. We hope to address this issue in a future release.

    Nice to know... :-).

    • Proposed as answer by NateSMSAdmin Thursday, October 24, 2013 7:02 PM
    Thursday, May 24, 2012 10:53 AM
  • Hello all,

    Picking up on the above discussion, I have come across the same error, however it does not point to any particular package. I have tried re-distributing every package on the distribution point, however the error re-appears.

    smsdpmon.log file extract below -

    Intializing DP Monitoring Manager... SMS_Distribution_Point_Monitoring 07/07/2012 02:00:00 1412 (0x0584)
    Getting monitoring thread priority SMS_Distribution_Point_Monitoring 07/07/2012 02:00:00 1412 (0x0584)
    Getting content library root path SMS_Distribution_Point_Monitoring 07/07/2012 02:00:00 1412 (0x0584)
    Getting site code SMS_Distribution_Point_Monitoring 07/07/2012 02:00:00 1412 (0x0584)
    Getting algorithm ID SMS_Distribution_Point_Monitoring 07/07/2012 02:00:00 1412 (0x0584)
    Failed to find algorighm ID from registry. Use default algorithm. SMS_Distribution_Point_Monitoring 07/07/2012 02:00:00 1412 (0x0584)
    Getting DP Cert Type SMS_Distribution_Point_Monitoring 07/07/2012 02:00:00 1412 (0x0584)
    Getting this DP NALPath SMS_Distribution_Point_Monitoring 07/07/2012 02:00:00 1412 (0x0584)
    Set media certificate in transport SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    Set authenticator in transport SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    Start to evaluate ... SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    CContentDefinition::LibraryPackagesWmi: The package data in WMI is not consistent to PkgLib SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    CContentDefinition::LibraryPackagesWmi failed; 0x80004005 SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    Start to evaluate all packages ... SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    Start to evaluate package 'S0100053' ... SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    Report status message 0x4000094C to MP SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    Set authenticator in transport SMS_Distribution_Point_Monitoring 07/07/2012 02:00:01 1412 (0x0584)
    Status message has been successfully sent to MP from remote DP SMS_Distribution_Point_Monitoring 07/07/2012 02:00:02 1412 (0x0584)
    Package S0100053 is verified successfully SMS_Distribution_Point_Monitoring 07/07/2012 02:00:03 1412 (0x0584)


    Please assist.

    Regards

    mittu

    Tuesday, July 10, 2012 9:10 AM
  • Hello all,

    Picking up on the above discussion, I have come across the same error, however it does not point to any particular package. I have tried re-distributing every package on the distribution point, however the error re-appears.

    smsdpmon.log file extract below -

    Intializing DP Monitoring Manager... SMS_Distribution_Point_Monitoring07/07/2012 02:00:00 1412 (0x0584)
    Getting monitoring thread priority SMS_Distribution_Point_Monitoring07/07/2012 02:00:00 1412 (0x0584)
    Getting content library root path SMS_Distribution_Point_Monitoring07/07/2012 02:00:00 1412 (0x0584)
    Getting site code SMS_Distribution_Point_Monitoring07/07/2012 02:00:00 1412 (0x0584)
    Getting algorithm ID SMS_Distribution_Point_Monitoring07/07/2012 02:00:00 1412 (0x0584)
    Failed to find algorighm ID from registry. Use default algorithm.SMS_Distribution_Point_Monitoring 07/07/2012 02:00:001412 (0x0584)
    Getting DP Cert Type SMS_Distribution_Point_Monitoring07/07/2012 02:00:00 1412 (0x0584)
    Getting this DP NALPath SMS_Distribution_Point_Monitoring07/07/2012 02:00:00 1412 (0x0584)
    Set media certificate in transport SMS_Distribution_Point_Monitoring07/07/2012 02:00:01 1412 (0x0584)
    Set authenticator in transport SMS_Distribution_Point_Monitoring07/07/2012 02:00:01 1412 (0x0584)
    Start to evaluate ... SMS_Distribution_Point_Monitoring07/07/2012 02:00:01 1412 (0x0584)
    CContentDefinition::LibraryPackagesWmi: The package data in WMI is not consistent to PkgLibSMS_Distribution_Point_Monitoring 07/07/2012 02:00:011412 (0x0584)
    CContentDefinition::LibraryPackagesWmi failed; 0x80004005SMS_Distribution_Point_Monitoring 07/07/2012 02:00:011412 (0x0584)
    Start to evaluate all packages ... SMS_Distribution_Point_Monitoring07/07/2012 02:00:01 1412 (0x0584)
    Start to evaluate package 'S0100053' ... SMS_Distribution_Point_Monitoring07/07/2012 02:00:01 1412 (0x0584)
    Report status message 0x4000094C to MP SMS_Distribution_Point_Monitoring07/07/2012 02:00:01 1412 (0x0584)
    Set authenticator in transport SMS_Distribution_Point_Monitoring07/07/2012 02:00:01 1412 (0x0584)
    Status message has been successfully sent to MP from remote DPSMS_Distribution_Point_Monitoring 07/07/2012 02:00:021412 (0x0584)
    Package S0100053 is verified successfully SMS_Distribution_Point_Monitoring07/07/2012 02:00:03 1412 (0x0584)


    Please assist.

    Regards

    mittu

    I've got the same problem. Did you ever find a fix for it yet?

    Ben

    Monday, July 16, 2012 5:25 AM
  • Nothing yet Ben. I'm still looking around for a resolution. None of the logs point to any particular package which is frustrating.

    mittu

    Tuesday, July 31, 2012 7:28 AM
  • I know this is old but jave you found a solution for this problem?

    I have the same problem, I have already searched all around without finding a solution for this problem

    Tuesday, January 22, 2013 7:25 AM
  • Which problem exactly?

    Torsten Meringer | http://www.mssccmfaq.de

    Tuesday, January 22, 2013 8:04 AM
  • I have a content validation error on my SCCM distribution point

    And this is what I see in smsdpmon.log

    Start to evaluate ... SMS_Distribution_Point_Monitoring 23/01/2013 01.00.01 9260 (0x242C)
    CContentDefinition::LibraryPackagesWmi: The package data in WMI is not consistent to PkgLib SMS_Distribution_Point_Monitoring 23/01/2013 01.00.01 9260 (0x242C)
    CContentDefinition::LibraryPackagesWmi failed; 0x80004005 SMS_Distribution_Point_Monitoring 23/01/2013 01.00.01 9260 (0x242C)

    The problem is that all the packages have been validated successfully.

    This is not a production environment, is just my home lab for learning but I'd like to know what kind of problem is this because I have already searched everywhere and I can't find a solution.

    I have SCCM 2012 SP1 RTM

    Wednesday, January 23, 2013 3:06 PM
  • I too am experiencing the same issue.  I followed the article referenced above as the log originally had four packages that it could not locate.  They had been removed from SCCM but were still referenced in WMI.  After I cleaned up WMI I am getting just

    CContentDefinition::LibraryPackagesWmi: The package data in WMI is not consistent to PkgLib

    CContentDefinition::LibraryPackagesWmi failed; 0x80004005

    In the log file.  I am also running SCCM 2012 SP1.

    Tuesday, January 29, 2013 5:08 PM
  • I am also having this problem on one DP site where the log does not specify the package with the issue..

    CContentDefinition::LibraryPackagesWmi: The package data in WMI is not consistent to PkgLib

    CContentDefinition::LibraryPackagesWmi failed; 0x80004005

    Thursday, February 14, 2013 2:37 PM
  • Hello all,

    I hit the same error on a second implementation. Is this a bug? Any luck with fixes?

    Monday, February 18, 2013 5:35 AM
  • There is a known issue in 2012 SP1 RTM where content validation will throw this error on a DP hosted on a secondary site. The fix is part of CU1 due at the end of march apparently. It is caused by Task Sequence updates.
    Friday, March 8, 2013 8:00 AM
  • I have similar issue when updating a specific deployment package to a Remote DP.  But my error code is 0x80041033.  Has anyone seen this or know the fix?  I see the fix in the link is pointing to a different error code.

    This is the pkgxfermgr.log:   Any help would be appreciated! thx

    Wednesday, March 20, 2013 10:47 PM
  • Did you try my suggestions in your original thread (http://social.technet.microsoft.com/Forums/en-US/configmanagergeneral/thread/1a64e9f5-9817-4238-b36f-b21351151241/#4ac80266-a4a4-4c2a-bc8b-b6b0d9e87085)? Specifically, updating the content?

    The link doesn't really have an error code in it (0x80004005 is a generic error); it is talking about hash mismatches in general.


    Jason | http://blog.configmgrftw.com

    Thursday, March 21, 2013 2:22 PM
    Moderator
  • Thanks Jason,

    The weird part here is that its been failing to update for almost a week now.  But this morning, when I check the content status for the Deployment Package and it now shows that it successfully updated the DP that was having the 0x80041033 issue.  Can this be because the deployment package is 25GB?  To provide further detail regarding the package, I download all desktop and server updates to this same package.  Is it recommended to split this so the package? can it be the size of the package is causing it to fail?

    I'm going to download another update to this package and see if it fails again on this DP with the issue

    Thursday, March 21, 2013 3:57 PM
  • Content Hash issue are very annoying because there is no way to truly determine cause except maybe through trial and error -- thankfully they don't happen as often in 2012.

    25GB is a huge package indeed and I think the chances of a content hash issues go up logarithmically the larger the package. I always recommend breaking updates up into much smaller, more manageable packages (note that this is difficult to do with ADRs because you can't change the package an ADR uses in the console but you can using PowerShell).

    If this package is happy, I would definitely recommend starting a new update package. Not only for this, but what happens when you add a new DP? You will have to push 25GB is one fell swoop to that DP. Not pretty.


    Jason | http://blog.configmgrftw.com

    • Proposed as answer by TomW11 Thursday, March 21, 2013 4:24 PM
    Thursday, March 21, 2013 4:09 PM
    Moderator
  • Thanks Jason.  I will create create new packages and split desktop from server.  Thanks for your help
    Thursday, March 21, 2013 4:27 PM
  • I wish I had a perfect answer for this but there are so many things can cause content to get corrupted it's hard to truly know what is causing it. And there's no way for ConfigMgr to know either so you're kind of left out in the dark. At a recent customer I had a similar issue: they had one large monolithic update package. It took me about a week (because they had DPs all over the globe), but I divided that package into many smaller ones just so I could have a better handle on the content and hopefully prevent any issue.

    Jason | http://blog.configmgrftw.com

    Thursday, March 21, 2013 4:33 PM
    Moderator
  • Yes the "one large monolithic update package" was the approach the vendor that recommended when this was first installed but it didnt seem like a good approach.  I think he was just trying to close and rush the deployment. I was curious how invasive the process to divide an existing package

    Thursday, March 21, 2013 4:58 PM
  • Just a sidenote to Jasons answer. I've always divided my Update Packages into Server and Client and created and furthermore, I create a new package on a yearly basis e.g. "Windows 7 updates - 2012"
    Thursday, March 21, 2013 5:26 PM
  • It's not really invasive and there is no direct way to divide the package, you simply have to redownload the content to new packages. That in and of itself takes a while. So you could actually leave your large package in place until you've divided it up into the smaller packages -- that way content is always available.

    Jason | http://blog.configmgrftw.com

    Thursday, March 21, 2013 5:38 PM
    Moderator
  • I appreciate the advisement gentlemen, thank again!

    Thursday, March 21, 2013 7:06 PM
  • Hi,

    I have the same problem here "failed to validate content hash" without any PackageID after the weekly content validation from one DP.

    But all Packages could be verified successfully.

    I hope there is as solution!

    Regards

    Monday, March 25, 2013 11:32 AM
  • Hi,

    I have the same problem here "failed to validate content hash" without any PackageID after the weekly content validation from one DP.

    But all Packages could be verified successfully.

    I hope there is as solution!

    Regards

    As mentioned, this isn't a problem with ConfigMgr itself, it's a problem with your content being properly replicated out which can be caused by many, many things including anti-virus, other security devices, etc.

    Have you tried updating the packages that are having issues?


    Jason | http://blog.configmgrftw.com

    Monday, March 25, 2013 1:18 PM
    Moderator
  • Thanks for the reply,

    here is a screenshot of the smsdpmon.log:

    http://imageshack.us/a/img692/3236/unbenanntncz.png

    after the message, all packages will be successfull evaluated

    the problem is, that I cant find any information about the PackageID whos responsible for the issue.

    Thanks

    Monday, March 25, 2013 2:14 PM
  • Hi,

    I know it's a bit late but I ran into the same issue.

    Is there a final solution for this yet?

    Tuesday, April 9, 2013 1:15 AM
  • I see two issues:

    1. Standalone DP - Content Validation reports hash failure:

    Obliviously, a re-distribution should fix this, sometimes this didn't work for me and a remove, wait, redistribute works. It is important to note, that the status in the console DP Status node might not return to green. If that's the case, check the status messages in the Component Status node for success, then re-run content validation for that DP. You can trigger the Content Validation task in Task Scheduler on the DP at any time. I am ignoring other things that might cause file corruption ie: antivirus, filter drivers etc

    2. DP on a Secondary Site Server - Content Validation Reports an error but doesn't show you what package cause it in the Console or the Log:

    OliMu and Mars both show examples of this. This problem was resolved by SP1 CU1. The log now correctly enumerates the mismatch between the PkgLib and WMI. You are able to see which packages need to be fixed. NOTE: If after looking at the log, you determine the INI file is missing from the PkgLib folder, you can either edit WMI and remove the matching entry and re-distribute, or to force INI re-creation without editing WMI you need to UPDATE the package. A redist will not recreate the INI file, and the problem will remain.

    JT

    Tuesday, April 9, 2013 2:07 AM
  • Hi,

    I am also noticing same issue and we are running SP1 CU1. My smsdpmon.log shows the following:

     

    Intializing DP Monitoring Manager... 
    Getting monitoring thread priority 
    Getting content library root path 
    Getting site code 
    Getting algorithm ID 
    Failed to find algorighm ID from registry. Use default algorithm. 
    Getting DP Cert Type 
    Getting this DP NALPath 
    Client is set to use HTTPS when available. The current state is 224.  
    Start to evaluate ... 
    Start to evaluate package 'DL10001B' version 0 ... 
    Report status message 0x4000094C to MP 
    Status message has been successfully sent to MP from remote DP 
    CContentDefinition::CheckFiles failed; 0x80070003 
    Failed to evaluate package DL10001B, Error code 0x80070003 
    Report state message 0x8000094F to MP

    Note that I am only seeing this with one of the packages (Workstation Updates). Initial distribution works ok and its when the validation kicks in, we see this on all of our 7 DP's.

    Wednesday, May 1, 2013 10:26 AM
  • Sorry to resurrect this thread but I see the same issue. Seems like 50% of my DPs suffer from this.

    Any news on this?

    Friday, August 30, 2013 6:18 AM
  • Have you already tried to redistribute or update content?

    Torsten Meringer | http://www.mssccmfaq.de

    Friday, August 30, 2013 7:04 AM
  • It does not say exactly what package/application is the problem.

    Monday, September 2, 2013 10:14 AM
  • What about smsdpmon.log?

    Torsten Meringer | http://www.mssccmfaq.de

    Monday, September 2, 2013 10:58 AM
  • Im having the same issue with one of my Secondary site servers, all other DP's and Secondary Site servers are fine.

    I thought this issue was caused with that .net update which broke the sync with Primary sites which I uninstalled a few days later but everything pushed to the server at that time can never be distributed to that Secondary site server.. All new packages work fine when I push to it.

    Since installing CU3 earlier this week, it's now giving me this error which is great since I now have something to go on.

    smsdpmon.log on Problemed Secondary site Server

    Failed to find algorighm ID from registry. Use default algorithm. SMS_Distribution_Point_Monitoring 5/10/2013 1:00:00 AM 5112 (0x13F8)
    Getting DP Cert Type SMS_Distribution_Point_Monitoring 5/10/2013 1:00:00 AM 5112 (0x13F8)
    Getting this DP NALPath SMS_Distribution_Point_Monitoring 5/10/2013 1:00:00 AM 5112 (0x13F8)
    Client is set to use HTTPS when available. The current state is 224. SMS_Distribution_Point_Monitoring 5/10/2013 1:00:00 AM 5112 (0x13F8)
    Start to evaluate ... SMS_Distribution_Point_Monitoring 5/10/2013 1:00:00 AM 5112 (0x13F8)
    CContentDefinition::LibraryPackagesWmi: The package data in WMI is not consistent to PkgLib SMS_Distribution_Point_Monitoring 5/10/2013 1:00:01 AM 5112 (0x13F8)
    CContentDefinition::LibraryPackagesWmi failed; 0x80004005 SMS_Distribution_Point_Monitoring 5/10/2013 1:00:01 AM 5112 (0x13F8)

    It's not giving me the problemed packages in the log but there are 8 packages that are always in progress of distribution but never finish (has been like this for over a month), even if I redistribute them. I've also tried removing the package, updating the source version and pushing it again to the site. Still no go.

    Soon ill have at least 10 DP's hanging off this Secondary site server so ill need to get this sorted.

    I really want to avoid rebuilding the site due to the link not being the best to the primary as it took over 2 weeks to sync the packages it needs.

    Thanks.

    Saturday, October 5, 2013 9:09 AM
  • Same issue here! We have one primary site (2012 SP1) with four DP's and they all throw this warning every week without saying the PackageID.

    Thursday, November 7, 2013 1:05 PM
  • I found a solution:

    Created an vbs script with this content

    strComputer  = "."
    strNamespace = "root\sccmdp"
     
    Set objCol = GetObject("winmgmts:\\" & strComputer & "\" & strNamespace).InstancesOf("SMS_PackagesInContLib")
    For Each Package In objCol
           WScript.Echo Package.PackageID
    Next

    and run it with a administrative rights console with

    cscript xy.vbs > xy.txt

    then you will get a packageid list. Ive copied that list in Excel.

    After this I copied the DP Output after a verification into Excel and compared both PackageID's.

    On PackageID was missing so I redistributet it to the DP.

    Problem is gone

    Hope this helps

    Saturday, December 21, 2013 11:20 AM
  • You can do the same thing with Powershell. This will give show you if items are in WMI and not in PkgLib, and vice versa.

    A content library clean-up function would be great MS.

    JT

    $WMIPkgList = Get-WmiObject -Namespace Root\SCCMDP -Class SMS_PackagesInContLib | Select -ExpandProperty PackageID | Sort-Object
    
    $ContentLib = (Get-ItemProperty -path HKLM:SOFTWARE\Microsoft\SMS\DP -Name ContentLibraryPath)
    
    $PkgLibPath = ($ContentLib.ContentLibraryPath) + "\PkgLib"
    
    $PkgLibList = (Get-ChildItem $PkgLibPath | Select -ExpandProperty Name | Sort-Object)
    
    $PkgLibList = ($PKgLibList | ForEach-Object {$_.replace(".INI","")})
    
    $PksinWMIButNotContentLib = Compare-Object -ReferenceObject $WMIPkgList -DifferenceObject $PKgLibList -PassThru | Where-Object { $_.SideIndicator -eq "<=" } 
    
    $PksinContentLibButNotWMI = Compare-Object -ReferenceObject $WMIPkgList -DifferenceObject $PKgLibList -PassThru | Where-Object { $_.SideIndicator -eq "=>" } 
    
    Write-Host Items in WMI but not the Content Library
    Write-Host ========================================
    $PksinWMIButNotContentLib
    
    Write-Host Items in Content Library but not WMI
    Write-Host ====================================
    $PksinContentLibButNotWMI
    


    • Proposed as answer by Roel Janssens Tuesday, December 24, 2013 10:28 AM
    Monday, December 23, 2013 1:16 AM
  • wow, thanks for this powershell script. If I detect items in WMI who are not in the content libary. What is the best way to remove them?

    Thank you!

    Monday, December 23, 2013 10:49 AM
  • To remove the item from WMI (Using the list from the previous script):

    Foreach ($Pkg in $PksinWMIButNotContentLib){
    Get-WmiObject -Namespace Root\SCCMDP -Class SMS_PackagesInContLib -Filter "PackageID = '$Pkg'" | Remove-WmiObject -Confirm
    }

    To remove INI files using the list from the previous script:

    Foreach ($Pkg in $PksinContentLibButNotWMI){
    Remove-Item -Path "$PkgLibPath\$Pkg.INI" -Confirm
    }

    NOTE: This will get content validation running OK, but the Site Server DB may still have the DP Listed as a content location. Only delete items from WMI once you have checked to see if any of you current packages match, if they do, you should redistribute. If you can't find them they may be orphan packages.

    We mostly find extra .INI files in the PkgLib folder, which relate to old packages that have been deleted. They get removed from WMI, but for what ever reason, the files aren't cleaned up from the ContentLib. Removing the INI file allows Conntent Validation to run succefully, but won't clean up all the binary files file from the other ContentLib folders.

    It would be nice to get the DP to scan WMI, the PkgLib folder and then work out what packages it has (including the actual binaries, and report back to the Site DB. Maybe in R3.

     

    • Proposed as answer by Roel Janssens Tuesday, December 24, 2013 10:27 AM
    Tuesday, December 24, 2013 12:12 AM
  • I have a quick and verified fix on 5 distribution points with this error:

    Robocopy /xn /xo /e \\gooddpserver\d$\sccmcontentlib\datalib \\baddpserver\d$\sccmcontentlib\datalib

    So far it has worked like a champ with no fallout and has saved me from redistributing over 300 GB on distribution points that got boogered up in the hash errors.  Bear in mind, this is assuming your goal is to have identical distribution points.  You can modify this to only target the packages that are bad by using the smsdpmon.log on the offending server.  After this is done, just run the Content Validation Task Sequence on the offending server and watch the Distribution Point Group Status get super green.


    Mike In Vancouver



    Thursday, November 19, 2015 7:10 PM