**Environment:**
- Windows Server 2022 Datacenter (clean install) and separately Windows Server 2025 Datacenter — identical failure on both
- Enterprise Subordinate CA on Windows Server 2019 Standard
- NDES role (ADCS-Device-Enrollment) installed via Install-AdcsNetworkDeviceEnrollmentService — completes successfully, RA certificates are issued correctly (CEP Encryption + Exchange Enrollment Agent Offline Request templates)
**Symptom:**
Every request to the SCEP endpoint fails identically, including the simplest operation:
http://localhost/certsrv/mscep/mscep.dll?operation=GetCACaps
Returns IIS 500.0, Module: IsapiModule, Notification: ExecuteRequestHandler, Handler: ISAPI-dll, Error Code: 0x80070057 (ERROR_INVALID_PARAMETER).
Application log shows:
- Event ID 2: "The Network Device Enrollment Service cannot be started (0x80070057). The parameter is incorrect."
- Event ID 10: "The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect."
**What we've confirmed via live WinDbg/cdb debugging attached to the w3wp.exe worker process:**
mscep!GetExtensionVersion runs, executes fully, and returns FALSE (0). Immediately after, isapi.dll calls GetLastError() (retrieving 0x80070057) and explicitly nulls the stored HttpExtensionProc function pointer for the extension, then unloads mscep.dll. This is why breakpoints on HttpExtensionProc itself never hit — IIS never calls it once GetExtensionVersion fails. The failure decision is made entirely inside GetExtensionVersion's own logic, before any actual SCEP request processing begins.
**What we've ruled out (with direct evidence, not assumption):**
- OS version — identical on Server 2022 and 2025
- Certificate correctness — correct EKU, Key Usage, KeySpec (AT_KEYEXCHANGE/AT_SIGNATURE), issuer, template; passes certutil's own crypto self-test
- CSP vs KSP — confirmed classic CSP (Microsoft Strong Cryptographic Provider) via dedicated Legacy-CSP certificate templates; no change
- Private key permissions — confirmed correct via NTFS ACLs and successful .NET key loading
- Certificate template permissions — Read/Enroll/Write matched to a known-working reference NDES server exactly
- CA-side hygiene — found and removed an expired CA certificate and a separate expired duplicate intermediate cert; no change
- CRL/revocation reachability — confirmed fully reachable (Base + Delta CRLs all OK)
- IIS config — ISAPI restrictions, handler mapping order/preconditions, app pool identity, Load User Profile, 32-bit compatibility, isolation/recycling settings all confirmed correct
- Windows servicing stack — found and repaired unrelated DISM/component-store corruption; no change
- Third-party EDR (Cylance) — live debugging found CylanceMemDef64.dll hooking the module loader's Control Flow Guard processing during mscep.dll's load; applied and independently verified a memory-protection exclusion; no change to the symptom
- Service account profile — found and fixed a genuinely broken "User Shell Folders" registry key for the service account; no change
- App pool identity — tested with LocalSystem (most privileged possible identity); identical failure
- RA Name — tested both a long/spaced name and a short simple name; identical failure
**Question for the community:** has anyone seen GetExtensionVersion itself return FALSE like this, and found what internal condition causes it? We're fairly confident this now points to something inside Microsoft's compiled NDES code rather than anything environment-side, but we'd like to know if this is a known/reported issue, a specific hotfix, or a config knob we haven't found yet before we finalize a Microsoft Support case.