none
Couldn't verify 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101

    Question

  • As already discussed here: http://www.windows-noob.com/forums/index.php?/topic/7231-client-push-fails-with-authenticode-signature-error/

    MicrosoftPolicyPlatformSetup.msi which comes during the ccmsetup installation is digitally signed and the signature expired on 2012-01-10, therefore the client installation doesn't get anywhere.

    I'm having pretty big problem with this 'cause I'm trying to install new machines and do a build also. Anyone else experiencing the same problem? Any workaround from MS?

    Running SCCM2012 SP1 RTM.

    Friday, January 11, 2013 8:40 AM

Answers

  • Please note that there is now a SCCM 2012 hotfix for this issue:

    http://support.microsoft.com/kb/2801987

    Regards,

    Mark.

    • Proposed as answer by Benjamin Watt Monday, January 14, 2013 12:33 PM
    • Marked as answer by Narcoticoo Tuesday, January 15, 2013 4:32 AM
    Monday, January 14, 2013 11:11 AM
  • Some notes how to get this thing working during task sequences without manually injecting the fix to the install.wim:

    1. Create a package of KB2749655
    2. Save the drive letter to a variable during partition disk 0 (advanced options, variable: OSDTargetDrive)
    3. After Apply Operating System Image -step, add additional step "Run Command Line" using the package created in step 1. The command line: cmd.exe /c dism.exe /image:%OSDTargetDrive%\ /add-package /packagepath:%CD% /scratchdir:%OSDTargetDrive\Windows\Temp /norestart

    The method above injects the hotfix to the image "Apply Operating System" installs to your hdd.

     

    • Marked as answer by Narcoticoo Tuesday, January 15, 2013 4:32 AM
    Monday, January 14, 2013 9:28 AM

All replies

  • A fellow MVP (Greg) already noticed the same and informed the product group ...

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

    Friday, January 11, 2013 8:56 AM
  • I have the same problem, probably will have to put pens MicrosoftPolicyPlatformSetup.msi until solutions
    Friday, January 11, 2013 9:40 AM
  • As stated in the forum post at windows-noob.com the certificate check passes when changing the date in Windows.

    My workaround for OSD is changing the date before and after "Setup Windows and ConfigMgr" step. And since I'm running in Native Mode I can't change the date too far back, so I'm simply setting it to 2013-01-10.

    Client Push installations are not as easy to get working without a proper patch. We're currently running a batch that changes date before and after installations, ie:

    date 01-10-13
    \\networkpath\ccmsetup.exe <parameters>
    date 01-11-13

    Friday, January 11, 2013 10:08 AM
  • I am seeing the same problem... let's hope for a quick solution!
    Friday, January 11, 2013 10:15 AM
  • I am seeing the same problem... let's hope for a quick solution!

    Make sure to call Microsoft (CSS) support then.

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

    Friday, January 11, 2013 10:42 AM
  • Workaround to change the date is not working when you are running SCCM in HTTPS-only modus. Then the client certificate is not valid...please fix this bug is soon as possible! Is there already a KB for it?
    Friday, January 11, 2013 12:29 PM
  • There's no kb available as far as I know. Again: please make sure to call Microsoft (CSS) so that they will be aware of this issue. They cannot do anything if no calls are logged.

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

    Friday, January 11, 2013 12:37 PM
  • I gave them a call but they told me to sit put and monitor this TechNet thread.

    Friday, January 11, 2013 1:21 PM
  • Hi,

    we raised a call to Premier Support. Let´s see. :-)

    Greets

    Michael

    Friday, January 11, 2013 1:30 PM
  • Hi,

    as a fast Workaround you can install the the MicrosoftPolicyPlatformSetup.msi manually (if you have remote access to the machines). I am currently in a rollout of sccm2012 with a customer and have created this short Batch file for it:

    (Scenario: SCCM Client published to SCCM WSUS)

    ------Batchname: installMSPPS.cmd ------

    set sccmwsus=http://sccmwsus.unknown.local:80
    md \\%~1\admin$\ccmsetup
    copy "%~dp0MicrosoftPolicyPlatformSetup.msi" \\%~1\admin$\ccmsetup
    "%~dp0psexec.exe" \\%~1 msiexec /i c:\windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi /qn /l* c:\windows\mpps.log REBOOT=ReallySuppress
    sc  \\%~1 start RemoteRegistry
    ping 128.0.0.0 -n 5 -w 1000 > nul
    reg add \\%~1\HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /d %sccmwsus% /f
    reg add \\%~1\HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer /t REG_DWORD /d 1 /f
    sc  \\%~1 stop wuauserv
    ping 128.0.0.0 -n 5 -w 1000 > nul
    sc  \\%~1 start wuauserv
    psexec \\%~1 wuauclt.exe /detectnow
    
    Usage: installmspss.cmd pcname
    You need psexec and MicrosoftPolicyPlatformSetup.msi in the same directory.
    Friday, January 11, 2013 1:32 PM
  • Workaround to change the date is not working when you are running SCCM in HTTPS-only modus. Then the client certificate is not valid...please fix this bug is soon as possible! Is there already a KB for it?

    Depending on your PKI/Certificate configuration you might not the able to change the date since this may break other certificate validations.

    I'm running my enviroment in HTTPS-only (aka. Native Mode) and got it working by changing date on the computer.
    This will however not work forever since someday other pki related certificates will cause the installation/download process to fail.


    Friday, January 11, 2013 1:37 PM
  • ah~~, this problem find by my team.

    LOL

    Friday, January 11, 2013 1:43 PM
  • Another workaround, you can install this MSI manually with the following command:

    msiexec /i c:\windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi /qn /l* c:\windows\mpps.log REBOOT=ReallySuppress

    Friday, January 11, 2013 1:59 PM
  • But these workarrounds will not work during a task sequence. The Setup Windows and Configuration Manager step will just stop and break it.

    Friday, January 11, 2013 2:14 PM
  • Another possible workaround might be to install a required hotfix.  I just used a test server running 2008 R2 that was having this exact error in ccmsetup.log, and I pointed it at Microsoft Update and installed everything offered.  This seemed to allow ccmsetup to successfully install the client on restart.  So now I'll look through the 46 updates installed and see which ones might be related to certificate chains/authenticode.

    Here's a summary of the error I'm seeing in ccmsetup.log:

    Successfully downloaded client files via BITS.
    Validated file 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' hash '5670B0C69C75ADEAAF5BEE0CDE27B9780DC12D1B895DCA217C221EC3C3BD1537'
    Validated file 'C:\Windows\ccmsetup\WindowsFirewallConfigurationProvider.msi' hash '3BF0651FD4A01170925CEF694468D4EF6F64D76FD3413DEBD14CB8DE019AA10E'
    Validated file 'C:\Windows\ccmsetup\Silverlight.exe' hash '417B442E128D821119008ACEEEE6CDC2A41224377A829B6EC52BABA2724F0151'
    Validated file 'C:\Windows\ccmsetup\SCEPInstall.exe' hash '495B488FFCEE7C2D682AC6ABFC62D7F9CCB15E22911BA2B76C41307343E617CC'
    Validated file 'C:\Windows\ccmsetup\client.msi' hash '2F0819F959E788CF843F42E9CA7B44E258B8B4BA37BB63902DB39ACF747BE7DA'
    Couldn't verify 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101
    Sending Fallback Status Point message to 'sccm12bprimary.test13.local', STATEID='316'.
    Failed to get client version for sending messages to FSP. Error 0x8004100e
    Params to send FSP message '5.0.7804.1000 Deployment Error 0x80004005. Pre-req file name: C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi'
    State message with TopicType 800 and TopicId {A4DBDF4A-2A92-4305-AE20-AEC689F6AB53} has been sent to the FSP
    InstallFromManifest failed 0x80004005
    CcmSetup failed with error code 0x80004005

    Friday, January 11, 2013 4:17 PM
  • MS will just need to resign and redistribute the MSI somehow.  The other MSIs in the folder all have older certs.  When signing the MSI, the person doing the signing must have forgotten to do the option where you tell it to be signed forever and instead let it be set to expire with the signature.

    Installing a hotfix is not going to work in task sequences.  There's no way I know of to insert an extra Hotfix between when Windows gets installed and when CCMSetup tries to run.

     

    Friday, January 11, 2013 5:14 PM
  • MS will just need to resign and redistribute the MSI somehow.  The other MSIs in the folder all have older certs.  When signing the MSI, the person doing the signing must have forgotten to do the option where you tell it to be signed forever and instead let it be set to expire with the signature.

    Installing a hotfix is not going to work in task sequences.  There's no way I know of to insert an extra Hotfix between when Windows gets installed and when CCMSetup tries to run.

     

    Unless you inject the hotfix (if possible, .msu file perhaps?) straight to the .wim image (to be deployed for example install.wim) using dism.

    Still waiting for the fix from MS.

    Friday, January 11, 2013 5:27 PM
  • I think I narrowed it down to KB2749655 & KB2756872, installing these hotfixes as a prerequisite to the ConfigMgr 2012 SP1 client seems to prevent the error during client push installations.

    I haven't done any testing with task sequences yet, but I'm guessing this hotfix could be included in a build & capture task sequence and then the new updated WIM could be used in the existing deploy task sequence.  Hopefully Microsoft will release an easier solution soon.


    Windows XP, 7, 2008, 2008 R2:

    http://technet.microsoft.com/en-us/security/advisory/2749655

    http://support.microsoft.com/kb/2749655


    EDIT: There is a different hotfix for Windows 8 & Server 2012, cumulative update KB2756872.

    Windows 8, 2012:

    http://support.microsoft.com/kb/2756872


    Friday, January 11, 2013 5:54 PM
  • Instead of injecting the file - that sounds kind of risky to me - modifying the base WIM for the OS install, I think it is easy to add some post installation commands to the windows installation process using the unattend.xml.

    At any rate, the weather here is nice today, so why not just take the afternoon off and hope that MS releases a fix over the weekend.

    Friday, January 11, 2013 6:12 PM
  • Injecting updates into the WIM is a normal activity, is no big deal, and is certainly not a risk. In fact, the offline updates process in ConfigMgr 2012 does just this. It's been a feature of Windows since Vista as a matter of fact. Not every update can be injected this way, but any core OS update can be. Having said all of that, I don't know if this update can actually be injected through this process though.

    Jason | http://blog.configmgrftw.com

    Friday, January 11, 2013 6:35 PM
  • Thank you Marty, I confirm that installing kb2749655 fixes the installation issue. 

    I am hoping there is an easier solution soon as well.  This is a Catch-22 secnario as we count on CM to install updates... updates that it can't get becasue the client will not install :)

    Friday, January 11, 2013 6:45 PM
  • Maybe it is six of one, half dozen th other, but I would prefer to install hotfixes offline into the deployed image prior to setup running rather than inject hotfixes into the Install.Wim from the Win 7 DVD.

    I just like that doing it in the task sequence sort of documents what has happened to that pristine Win 7 WIM, rather than injecting them into the WIM where they are sort of obscured.

    What I did was add that hotfix referenced above KB2749655 and KB2522623 to a hotfix package and used the "Install Language Packs Offline" trick Chris Nackers bloged about here http://www.chrisnackers.com/2011/08/19/configmgr-building-a-reference-image-installing-hotfixes-updates-offline/  - - start reading about 1/4 of the way down at "Installing Multiple Hotfixes/Updates Offline using a MDT Task Sequence"    It's after the LTI stuff.  Using the method there to install the hotfix offline resolved the issue during the build/capture process for me. 

    You still need to figure out someway of patching Windows 7 before you try and install the new client to existing machines though.

    PS - KB2522623 is a hotfix I found I needed in order to get the "Install Software Updates" to work correctly.

    Friday, January 11, 2013 8:03 PM
  • I've DISM-ed KB2749655 into my Operating System Images, updated the Distribution Points with the freshly updated Source, ran my malfunctioning Task Sequences, and Won In Life (then again, I am writing this at 23:20 on a Friday night....)

    I can confirm this KB solves aforementioned issues. Personally don't see any issues with injecting the WIM file, especially since every extra step adds to deployment time, and SCCM aleady isn't the fastest in the race.

    DMcCleskey: you could install this KB through a Startup script to the clients you want the SCCM Client Agent installed to.

    Edit: narcoticoo: you need to extract Windows6.1-KB2749655-x64.cab from the MSU file Microsoft offers up for download.

    Friday, January 11, 2013 10:21 PM
  • I just tested this on a new Server 2012 and KB2749655 wasn't relevant.  There's a different hotfix for Windows 8 & Server 2012, cumulative update KB2756872.  I edited my post above to include this link:

    http://support.microsoft.com/kb/2756872

    Saturday, January 12, 2013 3:40 AM
  • The fix 2749655 does work when tested on 2008R2 and doing a manual installation of the sccm agent.

    The same patch is availible through WU and SU, and should then be able to use through offline patching in OSD.


    Monday, January 14, 2013 8:58 AM
  • Some notes how to get this thing working during task sequences without manually injecting the fix to the install.wim:

    1. Create a package of KB2749655
    2. Save the drive letter to a variable during partition disk 0 (advanced options, variable: OSDTargetDrive)
    3. After Apply Operating System Image -step, add additional step "Run Command Line" using the package created in step 1. The command line: cmd.exe /c dism.exe /image:%OSDTargetDrive%\ /add-package /packagepath:%CD% /scratchdir:%OSDTargetDrive\Windows\Temp /norestart

    The method above injects the hotfix to the image "Apply Operating System" installs to your hdd.

     

    • Marked as answer by Narcoticoo Tuesday, January 15, 2013 4:32 AM
    Monday, January 14, 2013 9:28 AM
  • Please note that there is now a SCCM 2012 hotfix for this issue:

    http://support.microsoft.com/kb/2801987

    Regards,

    Mark.

    • Proposed as answer by Benjamin Watt Monday, January 14, 2013 12:33 PM
    • Marked as answer by Narcoticoo Tuesday, January 15, 2013 4:32 AM
    Monday, January 14, 2013 11:11 AM
  • On which site systems do I need to install this Hotfix?
    Monday, January 14, 2013 11:40 AM
  • On which site systems do I need to install this Hotfix?

    This is a quote from the kb article: "This hotfix should be installed to all primary site servers". Also make sure to read the entire article closely. It contains all information needed.

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

    Monday, January 14, 2013 12:06 PM
  • The patch ruined our boot images/PE environment again. Just like the SP1 update. Will try to recreate the boot images to see if that solves the problem.....
    Monday, January 14, 2013 1:01 PM
  • I’ve downloaded the KB that fixes the client signature signing error.

    When I run it on my Primary site server, it makes a package for deployment.

    Does it also fully patch the Primary site server that I ran the hotfix on?  I wonder because my Primary site server is not an SCCM client.

    The only server this patch applies to, for me is the server I ran the patch on.

    Do I need to install the agent on that Primary, create a collection and advertisement for the new package, and then let the package apply to the Primary, or does running the hotfix on the Primary itself patch it? 

    Monday, January 14, 2013 3:15 PM
  • I’ve downloaded the KB that fixes the client signature signing error.

    When I run it on my Primary site server, it makes a package for deployment.

    Does it also fully patch the Primary site server that I ran the hotfix on?  I wonder because my Primary site server is not an SCCM client.

    The only server this patch applies to, for me is the server I ran the patch on.

    Do I need to install the agent on that Primary, create a collection and advertisement for the new package, and then let the package apply to the Primary, or does running the hotfix on the Primary itself patch it? 

    Hi Todd,

    just run the patch and it will be installed on your primary site server. You can check this afterwards by viewing the 'Installed windows updates' in control panel. The package is created to patch other site servers.

    Monday, January 14, 2013 3:32 PM
  • Quick follow-up. Is there any impact on clients that were upgraded to SP1 prior to signature expiration?  

    Monday, January 14, 2013 3:50 PM
  • The patch will update the microsoftpolicyplatformsetup.msi in the client source.  I think it will automatically update the default client package on your distribution points.  If you have created your own client package (eg. so you that can enable distribution to package share) then you will have to update this package on your DPs manually.

    The new cert expiry is 4th March 2013, but I assume the date is not relevant.  I guess we will find out on 5th March :-).

    Regards,

    Mark.

    Monday, January 14, 2013 3:50 PM
  • Quick follow-up. Is there any impact on clients that were upgraded to SP1 prior to signature expiration?  

    Hi Rob,

    From what I am understanding is that this problem is only affecting the install of the client. Once the client has been installed and has made it's connection to the Management Point then all should be good; so as long as they were installed and talking before January 10th then they should be OK now.

    Monday, January 14, 2013 5:07 PM
  • Thank you Mark and Newton for your responses. I was hoping and thought that was probably the case, but I just wanted to be safe and confirm.
    Monday, January 14, 2013 5:16 PM
  • I have now tested the patch when deploying new clients through OSD and it works. I did not patch the OS image with KB2749655 so it's definitely been fixed by the SCCM patch. Mark.
    Monday, January 14, 2013 8:29 PM
  • The patch will update the microsoftpolicyplatformsetup.msi in the client source.  I think it will automatically update the default client package on your distribution points.  If you have created your own client package (eg. so you that can enable distribution to package share) then you will have to update this package on your DPs manually.

    The new cert expiry is 4th March 2013, but I assume the date is not relevant.  I guess we will find out on 5th March :-).

    Regards,

    Mark.

    Mark,

    I am new to SCCM. How do I do this, exactly? Do I need to create a new package from definition? Just update my distribution points?

    My problem with this issue is regarding task sequences.  When my TS reaches the Setup Windows and ConfigMgr step, I get this error and the TS breaks.  How do I manually update the ConfigMgr package that is being installed in that step?


    Tuesday, January 15, 2013 6:36 PM
  • Does this hotfix only apply to Service Pack 1 RTM? I am running SCCM 2012 SP1 Beta and the hotfix would not run, it said:

    This update applies to product version 5.0.7804 but the version found locally is 5.0.7782.1000, this update is not applicable to this system.

    Some googling suggested that the BETA version is "5.0.7782.1000" and the RTM is 5.0.7804.1000.

    Tuesday, January 15, 2013 7:18 PM
  • Yes, this update is for SP1 final.

    Given the SP1 was announced as General Available today, I'd say doing anything with the beta is now completely unsupported so you should probably reinstall your lab (assuming you were running the beta in the lab).


    Jason | http://blog.configmgrftw.com

    Tuesday, January 15, 2013 7:26 PM
  • Hi,

    I tried this method and it fails running the command line.  I created a package containing the update file, added the OSDTargetDrive variable, and ran the command line starting in the KB package I created.  I cannot seem to get the F8 prompt to work so I can get the logs, work in progress, but any idea why that line might fail?

    Thanks,

    Edit: I found 2 things.  1 I mistyped the variable.  Fixed that and and added another % to the last %OSDTargetDrive% variable in the above string.

    Thanks for the great workaround.




    • Edited by Adam Eaddy Tuesday, January 15, 2013 10:07 PM
    Tuesday, January 15, 2013 8:28 PM
  • To see what packages your task Sequence uses, click on Software Library, Operating Systems, Task Sequences.  Then select your task sequence.  At the bottom of the window there is a tab marked "References" (in addition to Summary and Deployments).  Click the References tab.  This lists all the packages that are directly referenced in you Task Sequence. One of the packages is going to be for your SCCM client.  That is the package you need to update on your DPs.

    Alternately, you can Right Click on your Task Sequence and choose "Edit"  Find the step "Setup Windows and ConfigMgr" in the Post-Install section.  The package used to install the SCCM Client will be shown there.  This also shows the package that needs to be updated.

    Tuesday, January 15, 2013 9:54 PM
  • Thanks for the great workaround.


    This workaround is not needed after applying http://support.microsoft.com/kb/2801987

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

    • Proposed as answer by MartyList Wednesday, January 16, 2013 3:53 PM
    Wednesday, January 16, 2013 7:59 AM
  • Hotfix working fine and resolved issue. You just need consider time , since the client's files are distributed to DP's.
    Wednesday, January 16, 2013 9:46 AM