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

DirectAccess IPHTTPS and Let’s Encrypt 6-Day Certificates

I’ve written extensively about how public TLS certificate lifetimes will drop to just 47 days by March 2029. Before then, we’ll see certificate lifetimes gradually drop from the current 398 days to 200 days on March 15, 2026, and then to 100 days on March 15, 2027. In preparation for this, I’ve been working with many customers to deploy automated certificate enrollment and renewal solutions to eliminate the need for manual intervention. Interestingly, Let’s Encrypt now offers extremely short-lived certificates that are good for just 6 days! While they work just fine for Always On VPN, I discovered they will not work for DirectAccess.

6-Day Certificate

After successfully enrolling for a 6-day TLS certificate from Let’s Encrypt (I used CertKit, BTW!), I encountered an error when trying to assign the short-lived certificate to the IP-HTTPS listener in the DirectAccess configuration. Specifically, when running the Set-RemoteAccess PowerShell command, I received the following error.

Set-RemoteAccess: The parameter is incorrect.

Further investigation showed that I could install other public TLS certificates just fine. For some reason, though, DirectAccess did not like this new 6-day certificate.

Missing Subject Name

After digging a bit deeper, I realized the Subject field of the new 6-day Let’s Encrypt certificate was empty.

Subject vs. SAN in Modern TLS

Modern TLS clients rely entirely on the Subject Alternative Name (SAN) field for identity validation, and the older practice of matching against the certificate’s Subject field has been phased out for many years. Many certificate authorities, including Let’s Encrypt, now leave the Subject field empty because it no longer serves a functional purpose in current TLS implementations. DirectAccess still expects this field to contain data and does not properly fall back to SAN‑only validation. As a result, any certificate with an empty Subject field, such as the new 6‑day certificates from Let’s Encrypt, will fail when applied to the DirectAccess IP‑HTTPS listener.

Workaround

Admittedly, using 6-Day public TLS certificates for DirectAccess is extreme and likely overkill for this workload. The good news is that DirectAccess still works perfectly with 90-day Let’s Encrypt certificates, so the lack of 6-day certificate support should not be impactful.

CertKit

Have you heard about CertKit? CertKit, an online service for automating Let’s Encrypt certificate enrollment and renewal, has added support for Always On VPN and DirectAccess. Find details on leveraging it for public TLS certificates for these solutions here.

Additional Information

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN and 47-Day Public TLS Certificates

The Case for Short-Lived Certificates in Enterprise Environments

CertKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates

Entra Private Access Intelligent Local Access

Microsoft Entra Private Access, part of the Microsoft Global Secure Access (GSA) Security Service Edge (SSE), is a compelling new cloud-based Zero Trust Network Access (ZTNA) solution that offers enhanced security compared to traditional VPNs. Until recently, traffic for all defined applications flowed through the GSA tunnel regardless of the client’s location. This resulted in sub-optimal traffic flow when the client is on the same network as resources defined in Quick Access or Enterprise applications. Fortunately, Microsoft has introduced a new feature to address this crucial limitation.

Intelligent Local Access

Historically, DirectAccess used the Network Location Server (NLS) to determine network location. Always On VPN used Trusted Network Detection (TND) to accomplish this same task. GSA has lacked this critical feature since its initial release. Thankfully, Microsoft recently added Intelligent Local Access (ILA). This feature allows GSA to identify a trusted private network and bypass the client, routing traffic directly to the local resource.

How It Works

With GSA ILA, administrators define a Private Network in their GSA configuration. Administrators define a resource by FQDN along with DNS servers to use for name resolution. When the client resolves this FQDN to a matching IP address (CIDR or IP address range is accepted as well), the client will then bypass GSA for target resources defined in the policy.

Note: Authentication is still performed for access to GSA applications even when ILA indicates the client is on a private network. However, after successful authentication and the client satisfies any conditional access policies, traffic is forwarded directly to the resource rather than routed through the GSA tunnel.

Configure ILA

To configure ILA, open the Microsoft Entra admin center and follow these steps.

  1. Navigate to Global Secure Access > Connect > Private Networks.
  2. Select Add Private Network.
  3. Enter a name for the trusted network in the Name field.
  4. Enter the IPv4 address(es) of any DNS server(s) used for this network in the DNS servers field.
  5. Enter the fully qualified domain name (FQDN) of a resource on this network for name resolution in the Fully qualified domain name field (see below for additional information).
  6. Select an option from the Resolved to IP address type drop-down list. Options include IP address, IP address range (CIDR), and IP address range (IP to IP).
  7. Enter the expected name resolution result in the Resolved to IP address value field.
  8. Click Select applications below Target resource to exclude from GSA processing when on this network.
  9. Click Create.

ILA FQDN Recommendation

Technically speaking, the FQDN used by GSA for ILA can be any internal resource, even those included in Quick Access or Enterprise applications. Since the GSA client only attempts to resolve this name and doesn’t connect to it, administrators should configure a dedicated static DNS record with a dummy IP address for this purpose. A static DNS record ensures it won’t be overwritten, scavenged, or accidentally deleted. For example, administrators can create a DNS A record named ‘ILA’ that resolves to any IP address they choose, as long as it matches the IP address defined in the Private network configuration for GSA.

Troubleshooting

When confirming GSA client traffic bypass, using standard network troubleshooting tools isn’t sufficient. Here are a few examples.

Resolve-DnsName

Although the client is on a private network, Resolve-DnsName shows the IP address of the GSA address range of 6.6.x.x.

Ping (ICMP)

Interestingly, if you try to ping the FQDN, you’ll see that traffic bypasses the GSA client, as the response comes from the destination’s address.

By contrast, attempts to ping the FQDN outside the private network fail as the GSA client does not pass ICMP.

Advanced Diagnostics

The best way to confirm GSA client traffic bypass for private network resources is to use the Advanced diagnostics tool included with the GSA client. Click the GSA client icon in the notification area, then follow these steps to validate GSA client bypass when ILA is detected.

  1. Select the Troubleshooting tab in the navigation tree.
  2. Click Run Tool in the Advanced diagnostics tool section.
  3. Select the Traffic tab.
  4. Remove the Action == Tunnel filter.
  5. Click Start collecting.
  6. Initiate traffic to a Quick Access or Enterprise application configured for bypass when ILA detects a private network.
  7. Click Stop collecting.
  8. Review the log and note the Connection status for the traffic generated previously. It should indicate Bypassed when ILA detects a private network, as shown here.

Summary

With Intelligent Local Access now a feature of the Global Secure Access client, administrators can configure the client to bypass the GSA tunnel and access Quick Access and Enterprise applications directly for better performance, while still enforcing authentication and Conditional Access.

Additional Information

Enable Intelligent Local Access in Microsoft Entra Private Access

Entra Private Access Channels are Unreachable

Always On VPN vs. Entra Private Access: Choosing the Right Access Model for Your Organization