locked
SCEPinstall.exe fails hash check after KB2828233 Hotfix RRS feed

  • Question

  • After applying the platform hotfix KB2828233 (http://support.microsoft.com/kb/2828233?wa=wsignin1.0) I am now getting Hash check failures on SCEPInstall.exe during client install (thus causing the client install to fail)

    From ccmsetup.log

    Adding file 'http://myserver.mydomain.com:80/CCM_Client/i386/vcredist_x86.exe' to BITS job, saving as 'C:\Windows\ccmsetup\vcredist_x86.exe'. ccmsetup 4/19/2013 9:00:38 AM 6940 (0x1B1C)
    Adding file 'http://myserver.mydomain.com:80/CCM_Client/x64/vcredist_x64.exe' to BITS job, saving as 'C:\Windows\ccmsetup\vcredist_x64.exe'. ccmsetup 4/19/2013 9:00:38 AM 6940 (0x1B1C)
    Adding file 'http://myserver.mydomain.com:80/CCM_Client/x64/MicrosoftPolicyPlatformSetup.msi' to BITS job, saving as 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi'. ccmsetup 4/19/2013 9:00:38 AM 6940 (0x1B1C)
    Adding file 'http://myserver.mydomain.com:80/CCM_Client/x64/WindowsFirewallConfigurationProvider.msi' to BITS job, saving as 'C:\Windows\ccmsetup\WindowsFirewallConfigurationProvider.msi'. ccmsetup 4/19/2013 9:00:38 AM 6940 (0x1B1C)
    Adding file 'http://myserver.mydomain.com:80/CCM_Client/SCEPInstall.exe' to BITS job, saving as 'C:\Windows\ccmsetup\SCEPInstall.exe'. ccmsetup 4/19/2013 9:00:38 AM 6940 (0x1B1C)
    Adding file 'http://myserver.mydomain.com:80/CCM_Client/x64/client.msi' to BITS job, saving as 'C:\Windows\ccmsetup\client.msi'. ccmsetup 4/19/2013 9:00:38 AM 6940 (0x1B1C)
    Starting BITS download for client deployment files. ccmsetup 4/19/2013 9:00:38 AM 6940 (0x1B1C)
    Download Update: Connecting to the server. ccmsetup 4/19/2013 9:00:39 AM 6940 (0x1B1C)
    Successfully completed BITS download for client deployment files. ccmsetup 4/19/2013 9:02:57 AM 6940 (0x1B1C)
    Successfully downloaded client files via BITS. ccmsetup 4/19/2013 9:02:57 AM 6940 (0x1B1C)
    Validated file 'C:\Windows\ccmsetup\vcredist_x86.exe' hash '97C260D35BCFE18E046A1C413B9FC5A2754B8F790F7ACE669A3BE2500C0DF229' ccmsetup 4/19/2013 9:02:57 AM 6940 (0x1B1C)
    Validated file 'C:\Windows\ccmsetup\vcredist_x64.exe' hash '7451BA5C6C05347789717561E871A303A4D171850790A3CDC99D4DDBF07E320B' ccmsetup 4/19/2013 9:02:57 AM 6940 (0x1B1C)
    Validated file 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' hash '8C42189693C3220017E8C93A79B989EE126ADF33EADBE229011404C123B7B897' ccmsetup 4/19/2013 9:02:57 AM 6940 (0x1B1C)
    Validated file 'C:\Windows\ccmsetup\WindowsFirewallConfigurationProvider.msi' hash '3BF0651FD4A01170925CEF694468D4EF6F64D76FD3413DEBD14CB8DE019AA10E' ccmsetup 4/19/2013 9:02:57 AM 6940 (0x1B1C)
    File 'C:\Windows\ccmsetup\SCEPInstall.exe' with hash '495B488FFCEE7C2D682AC6ABFC62D7F9CCB15E22911BA2B76C41307343E617CC' from manifest doesn't match with the file hash 'EEBF8FBE6920D51B2728DE6303457F25DE302C1E3A5742ED175D281CAEC276BD' ccmsetup 4/19/2013 9:02:57 AM 6940 (0x1B1C)

    I've tried against 2 different MP/DP's now and same for both.

    Anyone have any ideas on how to correct this?



    Friday, April 19, 2013 2:36 PM

Answers

  • This has been corrected now.  Here's what we believe may have been the chain of events in case anyone else comes up against this:

    We installed SCCM 2012 SP1 PRIOR to the refreshed source code that contained the updated version of microsoftpolicyplatformsetup.msi, thus we have to apply the released hotfix for this after each new secondary site install.

    We "think" this hotfix modified the date of ccmsetup.cab to January 2013.  The FEP hotfix linked above appears to NOT overwrite the ccmsetup.cab if the date is newer than the included cab.  The hotfix did install the new version of SCEPnstall.exe but did not replace the ccmsetup.cab.  As stated above, the xml file inside the existing cab was holding the hash value for the previous scepinstall.exe thus causing the hash checking to fail.

    To fix the issue we uninstall the hotfix, renamed the existing ccmsetup.cab to .bak, reinstalled the hotfix and thus the correct ccmsetup.cab was placed in the client directory.  From there we just copied the correct ccmsetup.cab to the secondary site servers "Client" directory as well as the package source directory.

    Can't say for sure this is what happened but all signs seem to point to it.

    Friday, April 19, 2013 7:07 PM

All replies

  • Looking at the ccmsetup.xml, it does show the "invalid" hash

    <Item FileName="SCEPInstall.exe" FileHash="495B488FFCEE7C2D682AC6ABFC62D7F9CCB15E22911BA2B76C41307343E617CC" KeepAfterExit="true">
      <Applicability Platform="ALL" OS="ALL"/>
      <Discovery Type="File" Identifier="%windir%\ccmsetup\SCEPInstall.exe" VerifyHash="true">
       <Property Name="Version" Operator="&gt;=">4.1.522.0</Property>
      </Discovery>
      <Installation Order="17" InstallationType="NONE"/>
     </Item>

    The file dates are:

    ccmsetup.cab - 1/11/2012 10:40 AM (10k)

    SCEPInstall.exe - 12/20/2012 9:05 AM (24,232k)

    Friday, April 19, 2013 3:21 PM
  • So I extracted the ccmsetup.cab that is located in the hotfix .msp file and the ccmsetup.xml file inside DOES contain the corrected Hash value that scepinstall.exe is returning above.  So it "appears" that the hotfix install didn't actually update the .cab file in the Client directory on the servers...

    Seems like an easy fix would be to copy the correct .cab file to the client directory on all servers but that seems silly that I would have to do that.  I may try to reinstall the hotfix again to see if that fixes the issue first.

    If anyone else has any ideas please let me know.

    Thanks,

    William

    Friday, April 19, 2013 3:56 PM
  • This has been corrected now.  Here's what we believe may have been the chain of events in case anyone else comes up against this:

    We installed SCCM 2012 SP1 PRIOR to the refreshed source code that contained the updated version of microsoftpolicyplatformsetup.msi, thus we have to apply the released hotfix for this after each new secondary site install.

    We "think" this hotfix modified the date of ccmsetup.cab to January 2013.  The FEP hotfix linked above appears to NOT overwrite the ccmsetup.cab if the date is newer than the included cab.  The hotfix did install the new version of SCEPnstall.exe but did not replace the ccmsetup.cab.  As stated above, the xml file inside the existing cab was holding the hash value for the previous scepinstall.exe thus causing the hash checking to fail.

    To fix the issue we uninstall the hotfix, renamed the existing ccmsetup.cab to .bak, reinstalled the hotfix and thus the correct ccmsetup.cab was placed in the client directory.  From there we just copied the correct ccmsetup.cab to the secondary site servers "Client" directory as well as the package source directory.

    Can't say for sure this is what happened but all signs seem to point to it.

    Friday, April 19, 2013 7:07 PM
  • Hi,

    Based on this article http://sccmguru.wordpress.com/2013/05/24/configuration-manager-client-fails-to-install-after-kb2828233-hotfix-is-installed/?blogsub=confirming#subscribe-blog

    Question:  When you said: “So I decide to try the fix from the forum post and uninstalls the KB2828233 hotfix and then I rename the ccmsetup.cab file in the Client folder to ccmsetup.bak and install the KB2828233 hotfix again, after the installation a new ccmsetup.cab is created” – What exactly did you do? Did you uninstall the hotfix and simply rename the ccmsetup.cab?

    2nd Question: You said, “So I update the Client Package so it sends the new bits to the distribution point” – How did you exactly do that? Where is that?

    Thursday, June 13, 2013 8:10 PM
  • Question 1:  Yes, we uninstalled the hotfix from the server, renamed the cab and reinstalled the hotfix.  The reinstall created the "correct" cab in the client directory.

    Question 2:  I updated the distribution points for the default client package that is created during the initial SCCM Server install (The source location for default client package points to the default client location within the SCCM server install directory.  i.e. D:\SCCM\Client, if you installed your server into D:\SCCM ).  You may not use the default client package and may have created your own package.  If so just copy the contents of the default client directory into your custom source directory and update you distribution points.

    Thursday, June 13, 2013 9:57 PM
  • Thank you William!
    Thursday, June 13, 2013 10:13 PM
  • we are having same issue, anyone can assist me

    File 'C:\Windows\ccmsetup\SCEPInstall.exe' with hash 'AE71ED1F26ED5CAE468E556E2983D5237805A67808EDFB058535D69F993E7597' from manifest doesn't match with the file hash '053213C962817ECFF8819B592547355CA0EB15381BD999E19EF9396754D11B47' ccmsetup 10/24/2016 12:38:06 PM 6532 (0x1984)
    Params to send '5.0.8239.1403 Deployment SCEPInstall.exe' ccmsetup 10/24/2016 12:38:06 PM 6532 (0x1984)
    Sending Fallback Status Point message to 'xyz.contoso.com', STATEID='325'. ccmsetup 10/24/2016 12:38:06 PM 6532 (0x1984)
    <ClientDeploymentMessage ErrorCode="-2016410978"><Client Baseline="1" Platform="2"/></ClientDeploymentMessage> ccmsetup 10/24/2016 12:38:06 PM 6532 (0x1984)
    State message with TopicType 800 and TopicId {21301248-9D27-4F20-9C4B-C505E25BE24F} has been sent to the FSP FSPStateMessage 10/24/2016 12:38:06 PM 6532 (0x1984)
    CcmSetup failed with error code 0x87d0029e ccmsetup 10/24/2016 12:38:06 PM 6492 (0x195C)


    Wednesday, October 26, 2016 10:48 AM