Fix: Sending with Winhttp failed 80072f8f during SCCM OSD

After upgrading SCCM to the latest version, the OSD stopped working completely. The smsts.log revealed the error: “Sending with Winhttp failed 80072f8f.” I’ll show you how to fix the WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA error that occurs during SCCM OSD in this post.

This is my 100th SCCM troubleshooting post, and I feel delighted to have published so many posts just on troubleshooting Configuration Manager. Additionally, it demonstrates how comprehensive Configuration Manager is for resolving problems.

This week I decided to upgrade my lab running ConfigMgr version 2207 to SCCM version 2211. After this upgrade, something broke the operating system deployment. According to the SCCM upgrade log files, the update installed without any problems.

PatchMyPC HorizontalAD
Patch My PC Sponsored AD

My setup uses PKI, and both the management point and the distribution server are set up to operate over HTTPS. On the distribution point server, the PKI certificate was already imported and working correctly. In my previous posts on PKI, I mentioned the importance of the DP certificate. The certificate authenticates DP with an HTTPS-enabled management point.

On PXE-booting my test VM, I could see the boot image had downloaded fine. However, the task sequence never loaded, and I did not see anything on the screen. Check out the below image to understand what I am talking about.

Task Sequence not loaded
SCCM OSD Error – Task Sequence not loaded

Fix SCCM OSD Error Sending with Winhttp failed 80072f8f

The sending with Winhttp failed 80072f8f error occurs when your certificate authority issues the certificates that aren’t trusted and when the site server is not assigned with a Root CA.

During the OSD, when your SMSTS.log file contains WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA error, it means that the certificate authority that issued the certificates are not trusted. That’s why the SCCM task sequence doesn’t load after you PXE boot the machine.

In the below screenshot, we can see the smsts.log shows two errors: Sending with Winhttp failed 80072f8f and WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA.

Sending with Winhttp failed 80072f8f
Sending with Winhttp failed 80072f8f

Using the F8 key will start the command prompt if you’ve enabled command support in the boot image properties. Reviewing the smsts.log file using the CMTrace tool revealed the actual errors.

Sending with winhttp failed; 80072f8f. retrying Retrying and Ignoring date security failures. AsyncCallback() WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered dwstatusinformationlength is 4 WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA is set sending with winhttp failed; 80072f8f

Assign the Root CA under Site Server Properties

If you get the error 80072f8f during SCCM OSD, you should first check the site server properties to see if there is a root CA listed. If there is no root certificate specified, the PXE and media boot clients won’t trust the CA that issued the certs. This was precisely why I saw sending with Winhttp fail with error 80072f8f.

Launch the Configuration Manager console. Go to Administration\Overview\Site Configuration\Sites. Right-click your site and select Properties. Switch to Communication Security tab and click the Set button, select and assign the Root Certificate.

Assign the Root CA under Site Server Properties
Assign the Root CA under Site Server Properties

After the root CA has been specified, you must restart the WDS service once. If WDS isn’t installed for PXE, restart the ConfigMgr PXE Responder service.

Assign the Root CA under Site Server Properties
Assign the Root CA under Site Server Properties

Restarting the VM and PXE booting it loaded the task sequence correctly this time. You’ll notice that the certificates are the real cause of this problem if you’ve read the entire post. I sincerely hope the solutions in this post help you to resolve the issue. In case something else worked for you, please let me know in the comments section below.

Fix SCCM OSD Error Sending with Winhttp failed 80072f8f
Fix SCCM OSD Error Sending with Winhttp failed 80072f8f

Read Next

17 Comments

  1. Nice write up.
    Want to add “After the root CA has been specified, you must restart the WDS service once”, if anyone is using CA and SubCA. Please make sure you download the Certchain CA p7b then extract both the RootCA and SubCA and add them individually it to the SCCM.

  2. I recently migrated to a new CA, and thought I had caught all of the places. Turns out I wasn’t using the correct DP cert in the IIS manager, but it was correct everywhere else. Just in case this helps someone else out–was a bugger to track down!

  3. Thanks a lot, you saved my day !

  4. I’m getting this error as well trying to call the admin service but I don’t have PKI in my environment.

  5. Avatar photo Brett Vice says:

    Thanks Prajwal, amazing content as always.

  6. Thank you, this helped me, had a wrong root certificate at the beginning…

  7. I know little to nothing in regards of Certificates.
    What is the root CA exactly? Looking at the local cert under Trusted Root CA i have Microsoft Root CA which i tried to export and apply but that didn’t work.
    Is it something i need to create myself?

  8. I have the same issue and I can’t seem to boot using PXE. Getting the following error, “[TSMESSAGING] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered SMSPXE 04/02/2020 09:48:53 3596 (0x0E0C)
    [TSMESSAGING] : dwStatusInformationLength is 4
    SMSPXE 04/02/2020 09:48:53 3596 (0x0E0C)
    [TSMESSAGING] : *lpvStatusInformation is 0x20
    SMSPXE 04/02/2020 09:48:53 3596 (0x0E0C)
    [TSMESSAGING] : WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID is set
    SMSPXE 04/02/2020 09:48:53 3596 (0x0E0C)
    [TSMESSAGING] AsyncCallback(): —————————————————————– SMSPXE 04/02/2020 09:48:53 3596 (0x0E0C)

    Cert is specified and HTTPS only option is ticket.

    Anyone any ideas?

    Thanks

    1. Did you ever find a resolution to this? I am facing the same thing now.

  9. Hi Prajwal, thank you this worked fine.

  10. Avatar photo Manuel Pena says:

    Hello,
    My mistake was that I can see what I needed is to set a Trusted Root Cert but I wasn’t sure which cert I needed to use. I thought it was the IIS Cert or DP Cert or Client Cert that I created but none worked. So assumed that it was the Root Trusted Certificated Authority so when I exported it and set it that did the trick. Kinda confusing for me since this will be my first time changing my production from self signed cert to PKI and this was the only part on my test environment that was not working.

    Prajwal Desai thank you for all the procedures you have written its been very helpful. Happy New Year.

  11. Avatar photo Rene hansen says:

    Still getting the 80072f8f here – I wonder what the heck is going on.

    [TSMESSAGING] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered TSPxe 2019-12-30 18:54:47 1612 (0x064C)
    [TSMESSAGING] : dwStatusInformationLength is 4
    [TSMESSAGING] : *lpvStatusInformation is 0x8
    [TSMESSAGING] : WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA is set
    Error. Received 0x80072f8f from WinHttpSendRequest. TSPxe 2019-12-30 18:54:47 1612 (0x064C)

    1. I too have been fighting with this for a few days now. I’m not sure what is going on. I suspect that I have made a mistake with my certificates as I recently turned on HTTPS only. My end game is to be able to use The Bitlocker Feature in 1910.

      When I first set up my certs I was able to get PXE to work. It’s just the task sequence that I can’t access. Is there something I’m missing in my IIS setup?

      1. if you configured PKI certs correctly and assigned the right cert under IIS > HTTPS binding, the TS should load fine.

  12. I am getting the same error ,post updating from “Use PKI client ” to “Use Configuration manager generated certificate” .

    Question :- Do we still need to use Trusted root certificate with “config manager self signed certificate”

  13. Avatar photo MICHAEL COURVILLE says:

    I’ve been fighting this all morning with my OSD process. I put the root CA in place and was doing some more googling while waiting for my VM to download the boot image and THEN ran across this post, which would have saved me three hours this morning. LOL. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *