- 0x80072f05 Error
- Error 0x80072f0c
- Wap 0x80072f0c
A little notes from the field, I recently saw this issue at a customer. Their ADFS Proxy (Active Directory Federation Service) was suddenly not working anymore, It had been running without issues for months.
When started to troubleshoot this, we looking at the Web Application Proxy (WAP) service on the ADFS Proxy server and the error we got was:
0X80072F0C: Unknown: 0x80070057: Invalid parameter or argument is passed. 0x80090020: NTEFAIL: 0x80090027: Caller provided a wrong parameter. If third-party code receives this error, they must change their code. 0x8009002D: NTEINTERNALERROR: 0x801C0001 ADRS server response is not in a valid format. 0x801C0002: Server failed to authenticate. Note: If the issue persists after removing and configuring the PIN again in the settings, then deleting everything from the NGC folder will normally resolve it - however this will usually require administrator rights on your system and is done at your own risk, as with any time you delete something - there is a risk involved if it's not carried out correctly.
The operation stopped due to an unknown general error. Error code 0x8007520C.
We confirmed that the Web Applicaton Proxy service was stopped and the service could not be started. I suspected an issue with the certificate, since the ADFS is highly dependent on certificates working correctly.
To get a list of the certificates installed on the server, use the command via PowerShell:
The public certificate needed for the ADFS and it’s thumbprint is highlighted above with yellow marker. The thumbprint is then used for installing and configuring the Web Application Proxy with the correct certificate, which it done using the following command in PowerShell:
The Web Application Proxy service was then checked and it was now started and running.
The we tested the ADFS to confirm everything was working, you can test ADFS logon using the URL:
Everything now worked.
We had an other opportunely for some tedious troubleshooting with Microsoft over enrolling a windows 10 device automatically into Intune using group policy. The Microsoft documented article guides you through what should be a fairly easy process, and we had plenty of success.
However, we also had our problem devices that didn’t want to play ball. It took some commitment to resist the always popular recommendation by Microsoft support personnel to ‘just reset’ the computer, or ‘try redeploying the machine’, since unlike some vendor support, company IT support staff know how productive and happy users are when we make them setup their user profile again from scratch (when you aren’t using roaming profiles).
This was the error message that was seen when a machine didn’t want to enroll properly. We supposed this was caused by the machine being previously enrolled in Intune manually, them removed. We thought it might have also resulted from being previously retired/wiped, but in any case, it was not happy.
Start Here: We found related articles or posts that give information for troubleshooting this issue. This one matched the error message exactly at the bottom, and gave us some really useful things to check about our tenant’s Intune setup and user UPNs. After ensuring our UPN and MDM authority configurations matched Microsoft’s recommendations, we had to keep looking.
Folks on TechNet have also been working through similar experiences. This GitHub post was very informative about the behind the scenes activities of Auto Enrollment.
Let’s checkout AD Sync
Using this article, we decided to double check our AD Connect setup and service connection point (SCP) just to be sure that wasn’t the problem. We were fairly confident in this being correct because newly deployed machines were enrolling correctly. If the machine account isn’t making it to Azure AD, that would explain why auto enrollment doesn’t work.
We checked the hybrid enrollment status, guided by this article, of the problem machines and found at least that part was working correctly.
Finally, A Fix
We found after ensuring the machine was shown as AzureAD joined, we could run this command while logged on the machine as an Office 365 user account with an Intune entitlement:
“deviceenroller.exe /c /autoenrollmdm”command to trigger enrollment process that seems to work.
We were able to repeat the solution for two machines experiencing the same problem by:
- Removing existing objects in Intune and Azure AD
- Allowing AD Connect to resync the machine account into a computer object in Azure AD
- Logging on the machine as an Intune entitled Office 365 user and running
“deviceenroller.exe /c /autoenrollmdm”
After waiting a few minutes, the user was prompted with a message about their account or the administrator modifying their computer. After authenticating with Office 365, the Windows device showed up in both Azure AD and Intune correctly.
It seems that under the right conditions, the GPO auto enrollment method isn’t happy every time. Whether it didn’t create some certificates on the local machine it uses to authenticate with Azure, or there was already a previous object in Intune that caused a mismatch, it might be resolved in some cases by the procedure above.
As much as I tried, at the time of writing, I couldn’t find much documentation about the device enroller application, or its switches. Maybe we’ll know more about it in the future when Microsoft documentation gets created or updated.
We hope this prevents a few people from giving up so many hours of their life.