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.
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.
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.
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.
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.
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.
Thought id throw 2 cents in here, Brilliant mark up Prajwal, been a fan for awhile.
if your running an earlier version of SCCM – Ver 2107
MS came back with a workaround (and officially confirmed it as a bug still present in 2107). In IIS, on each DP, change the SSL settings of the SMS_DP_SMSPKG$ folder to IGNORE. Clients will still download content via SSL.”
IE theres a bug in the version.
even after applying the change to the iis sites to ignore the certs. we are still having the issue, and i can only lean towards the version is bugged and hopefully an upgrade will fix it.
hope this helps someone.
happy admining peeps.
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.
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!
Thanks a lot, you saved my day !
I’m getting this error as well trying to call the admin service but I don’t have PKI in my environment.
Thanks Prajwal, amazing content as always.
Thank you, this helped me, had a wrong root certificate at the beginning…
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?
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
Did you ever find a resolution to this? I am facing the same thing now.
Not sure if you and Jesse B were ever able to resolve this, but I wanted to follow up in the event anyone else has a similar issue, specifically for the “Cert Date Invalid”
For my environment the issue was the web server certificate that the reporting server uses. After requesting a new web server cert, and adding it into the report server configuration manager settings, everything started to work again.
Hi Prajwal, thank you this worked fine.
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.
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)
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?
if you configured PKI certs correctly and assigned the right cert under IIS > HTTPS binding, the TS should load fine.
Not sure if you and Nate were ever able to resolve this, but I wanted to follow up in the event anyone else has a similar issue.
For my environment the issue was the web server certificate that the reporting server uses. After requesting a new web server cert, and adding it into the report server configuration manager settings, everything started to work again.
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”
So have you moved from PKI certs to configmgr self signed certs ?.
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!