Troubleshooting NDES Error 0x80070003 Path Not Found on Windows Server 2025

When deploying enterprise PKI certificates with Microsoft Intune using SCEP, administrators must deploy one or more on-premises Network Device Enrollment Service (NDES) servers together with the Intune Certificate Connector. Installing and configuring NDES can be challenging because the solution includes multiple dependencies and has many moving parts. Troubleshooting installation failures can be difficult, particularly on Windows Server 2025 where I have observed installation issues more frequently than on earlier Windows Server releases.

Path Not Found

As I work with customers to migrate their existing NDES services to Windows Server 2025, I frequently encounter installation errors. Specifically, the ‘Path Not Found’ error is increasingly common. Using PowerShell or the Server Manager, administrators may encounter a failed NDES installation that returns the following error message.

CMSCEPSetup::Install: The system cannot find the path specified. 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND)

Investigation

Reviewing the NDES installation log at C:\Windows\certocm.log yields an important clue.

Microsoft Active Directory Certificate Services: Failed to add the web virtual directory. The system cannot find the path specified. 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND): The system cannot find the path specified. 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND)

Root Cause

This error occurs after a failed installation attempt which corrupts the IIS configuration on the NDES server. This prevents the NDES installer from configuring applications in the default web site. Fortunately, the problem is easy to resolve.

Recovery Steps

To recover from this error, first uninstall the NDES service (not the role) by opening an elevated PowerShell command window and running the following command.

Uninstall-AdccsNetworkDeviceEnrollmentService -Force

Next, remove the corrupt IIS configuration file.

Remove-Item C:\Windows\System32\inetsrv\config\applicationHost.config -Force

Copy a known-good IIS configuration file from the WinSxS folder.

$WinSxSConfig = Get-ChildItem C:\Windows\WinSxS -Recurse -Filter applicationHost.config -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 1
Copy-Item -Path $WinSxSConfig.FullName "C:\Windows\System32\inetsrv\config\applicationHost.config" -Force

And finally, recreate the default website.

& "$env:SystemRoot\System32\inetsrv\appcmd.exe" add site /name:"Default Web Site" /bindings:http/*:80: /physicalPath:"%SystemDrive%\inetpub\wwwroot"

Once complete, proceed with the NDES configuration.

Pro Tip

Because this issue occurs frequently enough in my experience, I recommend backing up the IIS configuration immediately after installing the NDES role and before beginning configuration. You can backup the IIS configuration by opening an elevated PowerShell command window and running the following command.

& "$env:SystemRoot\System32\inetsrv\appcmd.exe" add backup 'Backup Name'

If the NDES configuration subsequently fails, uninstall the configuration, then restore the backup using the following command.

& "$env:SystemRoot\System32\inetsrv\appcmd.exe" restore backup 'Backup Name'

Once complete, proceed with the NDES configuration once again.

Summary

NDES installation failures on Windows Server 2025 can leave IIS in an inconsistent state and trigger 0x80070003 ERROR_PATH_NOT_FOUND errors during configuration. Restoring a known-good IIS configuration and recreating the default web site resolves the issue quickly. Backing up the IIS configuration before beginning NDES configuration can significantly reduce recovery time if installation problems occur.

Additional Information

Troubleshooting NDES Error 0x80094800 Unsupported Cert Type on Windows Server 2025

Intune PKCS and SCEP Certificate Validity Period

TRAINING: Mastering Enterprise PKI Certificates with Microsoft Intune

Microsoft AD CS Adds Post-Quantum Cryptography Support with ML-DSA

Despite predictions of its decline, Microsoft Active Directory Certificate Services (AD CS) continues to evolve. Following significant enhancements introduced in late 2025, including CRL partitioning and support for 16K database pages, the May 2026 update adds another important capability: support for Post-Quantum Cryptography (PQC).

ML-DSA

Specifically, the May 2026 update adds support for ML-DSA-44, ML-DSA-65, and ML-DSA-87 in Windows Server 2025 for AD CS. This enables administrators to begin evaluating post-quantum cryptographic algorithms and assessing PQC readiness in enterprise PKI environments

Configuration

After applying the May 2026 update to an issuing Certification Authority (CA), administrators will find new PQC algorithms under the Algorithm name drop-down list, as shown here.

Note: If you don’t see these new algorithms, ensure you have selected Key Storage Provider from the Provider Category drop-down list. In addition, ensure that you select Signature on the Request Handling tab.

Test Results

Initial testing across common enterprise certificate scenarios produced mixed results. While PQC works well in some scenarios, other workloads still show limitations.

Code Signing

Code signing with an ML-DSA-44 certificate issued by AD CS works perfectly. For example, I can use Set-AuthenticodeSignature to sign a PowerShell script, as shown here.

Viewing the file’s properties shows that the encryption algorithm used to sign the file was ML-DSA-44, as expected.

IIS

TLS-based workloads proved more challenging. Attempts to configure an HTTPS binding in IIS failed with the following error message.

There was an error while performing this operation. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520).

RRAS and SSTP

Similar limitations occurred when testing remote-access VPN scenarios using RRAS and SSTP. Specifically, configuring a PQC TLS certificate for SSTP in RRAS failed. Although I was able to assign the certificate using Set-RemoteAccess, the RemoteAccess service failed to start.

Remote Desktop

Unfortunately, using PQC certificates for RDP also fails. Although I could assign the PQC certificate to the RDP listener, clients fail to connect using RDP and return the following error message.

This computer can’t connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

Error code: 0x904
Extended error code: 0x7

Summary

The May 2026 update marks an important milestone for AD CS by introducing initial support for PQC algorithms, allowing organizations to begin evaluating ML-DSA certificates in enterprise environments. Early testing shows promising results for signing scenarios such as code signing; however, broader infrastructure workloads, including TLS, VPN, and Remote Desktop, remain limited today. Although PQC support is still in its early stages, these updates demonstrate Microsoft’s ongoing investment in AD CS and provide administrators with an opportunity to begin preparing their PKI environments for the post-quantum future. Additional PQC enhancements, including ML-KEM support and broader ecosystem integration, are anticipated in future Windows updates.

Additional Information

Microsoft May 2026 Security Updates (KB5087539)

Post Quantum Cryptography in the Enterprise

Always On VPN with PEAP Fails in Windows 11 26H1

Always On VPN RasMan Errors in Windows 10 1903

There appears to be a bug in the latest Windows 11 26H1 (no, that’s not a typo – 26H1) build affecting Protected Extensible Authentication Protocol (PEAP). In my testing, all VPN connection attempts (Always On VPN and manual/ad-hoc) failed when PEAP was used for authentication.

Windows 11 26H1

Recently, while reviewing downloads and product keys in Visual Studio, I noticed a new Windows 11 release listed: Windows 11 26H1 (business and consumer editions). I initially thought 26H1 would be ARM-only, but the download is available for x64 as well.

I’m not sure whether this is intended as a general release, because Microsoft describes it as an Insider Experimental Preview Build (28200.1873). I also don’t recall seeing Insider builds offered through Visual Studio downloads, so I’m not sure what to make of it. Either way, if you’re evaluating this build, the notes below document a VPN issue I was able to reproduce.

Troubleshooting

After preparing a Windows 11 26H1 test client, I found that the Always On VPN user tunnel would not connect. The same configuration worked on earlier Windows 11 versions. In the event log, I observed the following errors.

Error 619

When using SSTP, the event log records error code 619 (event ID 20227) from the RasClient event source, with the following error message.

The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is 619.

Error 691

When using IKEv2, the event log records error code 691 (event ID 20227) from the RasClient event source, with the following error message.

The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is 691.

Workaround

At the time of writing, the only workaround I’ve found to restore Always On VPN connectivity is to switch authentication from PEAP to EAP-TLS. This may not be a drop-in change for every environment, so evaluate the security and operational impact before rolling it out broadly. You’ll need to enable EAP-TLS on both the client and the NPS/RADIUS server.

Summary

I’m not convinced Windows 11 26H1 will be widely deployed soon, since it appears to be an experimental/Insider build rather than a general release. If you decide to evaluate it, plan to use the workaround above to maintain Always On VPN connectivity.

Feedback

Have you tested Always On VPN with Windows 11 26H1? If so, do you see the same behavior? Share your findings in the comments.

Additional Information

Windows 11 Insider Experimental (26H1) Preview Build 28200.1873