I was doing an implementation of Network Device Enrollment Services (NDES) recently to support a client who required unique device certificates on their Intune Managed Windows 10 build to support a 3rd party VPN product.

I’ve implemented NDES in conjunction with Mobile Iron and Intune on various occasions and have not had any issues; the setup was a Windows 2019 NDES server, Windows 2019 PKI including 2019 Issuing CAs, and the NDES URL published to Intune Clients via the Azure Application proxy. The Microsoft documentation around this setup and troubleshooting common errors is fairly comprehensive.

With everything in place, my final step was assigning the Intune SCEP profile to my test devices and forcing along a sync. At almost exactly the same time as the SCEP profile was applied I got the following errors on the NDES server application log (and no device certificate delivered to the device!)

NDES Server:

Application Error: 1000

Faulting application name: w3wp.exe, version: 10.0.17763.1, time stamp: 0xcfdb13d8
Faulting module name: ntdll.dll, version: 10.0.17763.592, time stamp: 0x0f1b8afd
Exception code: 0xc0000374
Fault offset: 0x00000000000fb049
Faulting process id: 0x1134
Faulting application start time: 0x01d563cd543c516c
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: bdb7af74-7eea-4e75-8e4a-22e6230e5760
Faulting package full name:
Faulting package-relative application ID:

And in the Windows 10 client application log, also at exactly the same time a trio of errors:

CertificateServicesClient-Autoenroll 87 Error (Application log)

SCEP Certificate enrollment for Local system via https://scep.client.domain.na,e/certsrv/mscep/mscep.dll/pkiclient.exe failed:

PkiStatus(2): SCEPDispositionFailure
FailInfo(2): SCEPFailBadRequest
EnrollStatus(256): EnrollDenied
Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)
ProcessResponseMessage
Submit(Request):
HTTP/1.1 200
Date: Thu, 05 Sep 2019 09:36:01 GMT
Content-Length: 759
Content-Type: application/x-pki-message
Server: Microsoft-IIS/10.0 Microsoft-HTTPAPI/2.0

[some Azure App Proxy Cookie Info-deleted]

Method: POST(4000ms)
Stage: ProcessResponseMessage
Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)

And also….

CertificateServicesClient-Autoenroll 87 Error (Application log)

SCEP Certificate enrolment for Local system via https://scep.client.domain.name/certsrv/mscep/mscep.dll/pkiclient.exe failed:

SubmitDone
Submit(Request): Bad Gateway
HTTP/1.1 502 Bad Gateway
Date: Thu, 05 Sep 2019 09:37:03 GMT
Content-Length: 30836
Content-Type: text/html
Server: Microsoft-HTTPAPI/2.0

[some Azure App Proxy Cookie Info-deleted]

path=/; domain=client.domain.name

Method: POST(5515ms)
Stage: SubmitDone
Bad gateway (502). 0x801901f6 (-2145844746 HTTP_E_STATUS_BAD_GATEWAY)

And finally….

CertificateServicesClient-Autoenroll 87 Error (Application log)

SCEP Certificate enrollment for Local system via https://scep.client.domain.name/certsrv/mscep/mscep.dll/pkiclient.exe failed:

SubmitDone
GetCACert:
HTTP/1.1 200
Date: Thu, 05 Sep 2019 10:05:01 GMT
Content-Length: 6107
Content-Type: application/x-x509-ca-ra-cert
Server: Microsoft-IIS/10.0 Microsoft-HTTPAPI/2.0

[some Azure App Proxy Cookie Info-deleted]

Method: POST(4047ms)
Stage: SubmitDone
The supplied variant structure contains invalid data. 0x8007025c (WIN32: 604 ERROR_INVALID_VARIANT)

The fix

I did a bit of research on this and there was a lot of mention of IIS and application issues/bugs; I did however find an MS article which summarised almost exactly the same issue

https://social.technet.microsoft.com/Forums/en-US/14c940dd-f5fb-4d55-9b8b-ff940630a157/ndes-scep-iis-appcrash-win-server-2012r2?forum=winservergen

It implied that deleting any misplaced certificates in the trusted root / intermediate stores on the NDES server would fix the issue. I ran this past our support team who have occasionally seen similar server “appcrash” errors in the event logs of Skype Servers that have IIS components installed who also thought this might well be a fix.

In short, running the following powershellcommands on the NDES server

Checking the Trusted Root Store:

Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Select Issuer, Subject, Thumbprint | fl

Cheking the Intermediate Store:

Get-ChildItem Cert:\localmachine\CA | Where-Object {$_.Issuer -eq $_.Subject} | Select Issuer, Subject, Thumbprint | fl

Using the outputs of these commands allowed me to identify the misplaced certificates in the stores (in this case added as part of the server build) and remove them; some of them were extremely old and out of date. Having simply removed them from the stores, I re-synced my Windows 10 client with Intune and saw no errors on server or client side event logs which was promising – and almost instantly checking in the local Certificates MMC my Windows 10 device had a unique device certificate which I could see had come via the Intune SCEP profile and untimately NDES template on the Internal Issuing CA.

The errors don’t really give much of an idea of the true issue, and there doesn’t seem to be a lot out there on this; hope it helps or saves someone a bit of time if they come up against the same in their NDES implementation.