Forum Discussion

datafog87's avatar
datafog87
Copper Contributor
Aug 13, 2025

NgcSet stays NO despite working WHFB setup - RPC 0x800706ba error

Hi everyone,

I need help with a Windows Hello for Business certificate trust deployment that's almost working but stuck on the final step.

**What's Working:**
- Manual certificate enrollment works perfectly: `certreq -enroll -user -config "MyCA.domain.local\MyCA-CA" "MyWHFBTemplate"`
- TPM 2.0 is ready, enabled, and functional
- All Group Policies applied correctly (computer and user)
- CA server healthy, templates published

**What's NOT Working:**
- `dsregcmd /status` shows `NgcSet : NO` (should be YES)
- `NgcSvc` (Microsoft Passport) service is stopped on client
- Getting error: "RPC server is unavailable (0x800706ba)" during automatic certificate enrollment
- PIN setup fails because NGC containers won't create

**The Strange Part:**
Manual certificate enrollment works perfectly, but automatic enrollment fails with RPC errors. Both should use the same communication path to the CA.

**Environment:**
- On-premises certificate trust deployment (no Azure AD)
- Domain-joined Windows 11 clients
- Windows Server 2019/2022 infrastructure

**Questions:**
1. Should NgcSvc start automatically when WHFB policies are applied?
2. Why would manual cert enrollment work but automatic fail with RPC errors?
3. Is there a difference in how system context vs user context accesses the CA?

Has anyone seen this specific combination before? Any ideas what could cause this behavior?

Thanks for any help!

Authentication
Identity
Modern authentication
multi-factor authentication
On-Premises
security

3 Replies

Sort By
  • Kidd_Ip's avatar
    Kidd_Ip
    MVP
    Aug 14, 2025

    Consider below:

     

    Fix DCOM/RPC Permissions

    • Add NT AUTHORITY\Authenticated Users to Certificate Service DCOM Access
    • Ensure Remote Activation permissions are granted via dcomcnfg

     

    Restart NgcSvc and Dependencies

    Run these commands in an elevated PowerShell:

    sc config NgcSvc start= demand
sc start NgcSvc

    Also verify:

    Get-Service -Name RpcSs, DcomLaunch, NgcSvc | Format-Table Name, Status, StartType

     

    Check Autoenrollment Triggers

    Use certutil -user -pulse and certutil -pulse to manually trigger autoenrollment in both contexts.

     

    Event Viewer & Logs

    Check Event ID 10027 in the System log on the CA for DCOM permission issues. Also look for Event ID 82 in the Application log for autoenrollment failures.

    • datafog87's avatar
      datafog87
      Copper Contributor
      Aug 19, 2025

      *Current Status:*
      We have successfully deployed most of the WHFB infrastructure:

      ✅ *Working Components:*
      - AD FS service running with correct service account
      - All AD FS endpoints responding correctly:
        - /adfs/services/trust/mex returns 200 OK
        - /adfs/services/trust/13/windowstransport returns 401 (authentication required)
        - /adfs/services/trust/13/certificatemixed returns 400 (expected)
      - Service Connection Points (SCPs) created in AD Configuration partition
      - Tenant-specific SCP created: CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration
      - Certificate infrastructure functional (manual enrollment works)
      - Group Policies applied correctly

      ✅ *dsregcmd /status shows:*
      - AD Connectivity Test: PASS
      - AD Configuration Test: PASS  
      - PolicyEnabled: YES
      - DeviceEligible: YES
      - CertEnrollment: enrollment authority

      ❌ *Remaining Issue:*
      - DRS Discovery Test: FAIL [0x801c001d/0x801c000c]
      - AdfsRaIsReady: NO
      - PreReqResult: WillNotProvision

      *Previous Fixes Applied:*
      - Created all required SCPs (verified with LDAP queries)
      - Fixed AD FS service account logon issues
      - Configured certificate templates (ADFSEnrollmentAgent, WHFBAuthenticationv3)
      - Enabled device registration in AD FS: Enable-AdfsDeviceRegistration
      - Configured Certificate Registration Authority: Set-AdfsCertificateAuthority
      - Added AD FS to client's trusted sites and intranet zones
      - Forced AD replication across all domain controllers
      - Cleared device metadata caches

      *Current Investigation:*
      Based on community recommendations, we're now investigating these potential issues:

      1. *DCOM/RPC Permissions:* May need to add NT AUTHORITY\Authenticated Users to Certificate Service DCOM Access permissions

      2. *NgcSvc Service Dependencies:* Service may need manual restart with specific start type configuration

      3. *Certificate Autoenrollment:* May need to manually trigger autoenrollment using certutil -pulse

      4. *Event Log Analysis:* Looking for Event ID 10027 (DCOM issues) and Event ID 82 (autoenrollment failures)

      *Questions:*
      1. Has anyone encountered DRS Discovery failing despite all AD FS endpoints being functional?
      2. Are there specific DCOM permissions required for the Certificate Services that affect WHFB device registration?
      3. Should the NgcSvc service be configured with a specific start type for WHFB Certificate Trust scenarios?
      4. Are there any additional certificate autoenrollment triggers needed beyond standard Group Policy application?

      *Additional Context:*
      The infrastructure appears solid - we can manually query SCPs, AD FS responds to all endpoint tests appropriately, and the client can discover the federation service. The issue seems to be in the final device registration handshake between the client and AD FS DRS.

      Any insights on the DCOM/RPC permissions or NgcSvc configuration would be greatly appreciated!

Resources