certificate Auto enrollment is not working

Hi @SAIF WAEL

Thank you for the screenshots. They provide an important clue.

The Certificate Enrollment window shows that RDP-authentication succeeds, while BM_TIA_SCCM_Client fails with 0x800706BA (RPC_S_SERVER_UNAVAILABLE). Event ID 82 also confirms that the Local System account attempts enrollment but cannot successfully communicate with or authenticate to the enrollment endpoint.

This means auto-enrollment itself is being triggered. I would therefore shift the investigation away from gpupdate and toward the RPC/DCOM path between the affected clients and the CA.

Microsoft documents this exact 0x800706BA certificate-enrollment condition and lists several possible causes, including DCOM configuration, Certificate Service DCOM Access permissions, RPC restrictions, and security policies affecting RPC authentication.

First, from one affected machine, run:

certutil -config "CA-SERVER\CA-NAME" -ping

If that returns the same 0x800706BA, test the RPC Endpoint Mapper:

Test-NetConnection CA-SERVER -Port 135

However, TCP 135 succeeding does not prove that AD CS RPC enrollment is working. Port 135 locates the RPC service; subsequent communication can use dynamic RPC ports.

Since only some machines are affected, I would compare an affected client against a working client, particularly:

gpresult /scope computer /r

Look for differences in applied security GPOs involving:

Pay particular attention to Restrict Unauthenticated RPC clients and any recently introduced security-hardening policy.

On the CA, also verify that:

NT AUTHORITY\Authenticated Users

hasn't been removed from the required default permissions and that the Certificate Service DCOM Access configuration hasn't been changed. Microsoft specifically identifies both as possible causes of this enrollment error.

I would also compare the affected and working machines by OU, VLAN/firewall policy, security baseline, and applied GPOs. Because enrollment succeeds for at least one template and the issue affects only a subset of devices, that strongly suggests a client/template-specific path or policy difference rather than a general CA outage.

One additional test would be:

certutil -pulse
certreq -autoenroll -q

and then immediately review:

Microsoft's troubleshooting guidance for this exact error is here:

Microsoft – Error 0x800706BA during certificate enrollment

At this point, I would not modify the certificate template, disable Windows Firewall, or broadly loosen DCOM/RPC security. The screenshots show that enrollment is being initiated; the next step is to identify exactly where the RPC/DCOM communication for BM_TIA_SCCM_Client is failing.

If you can share the output of:

certutil -config "CA-SERVER\CA-NAME" -ping

from one affected machine and one working machine, that comparison should narrow the issue down considerably.

I’ve tried this certutil -pulse

certreq -autoenroll -q

and certificates have been installed silently so what else i can do

certutil -config "CA-SERVER\CA-NAME" -ping

i’ve tried this also then i got rpc server unavailable with same error code

Hi @SAIF WAEL

Thank you for testing both commands. This result actually helps narrow the issue considerably.

The fact that:

certutil -pulse

certreq -autoenroll -q

can install certificates indicates that the certificate template, enrollment permissions, and auto-enrollment configuration are fundamentally working.

However, this result is important:

certutil -config "CA-SERVER\CA-NAME" -ping

The RPC server is unavailable.

0x800706BA (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)

That means I would now concentrate on the RPC/DCOM communication path between the affected computer and the CA.

Microsoft specifically documents 0x800706BA during certificate enrollment as potentially being caused by DCOM configuration/permissions, RPC restrictions, or Certificate Service DCOM Access configuration.

Also, confirming that TCP 135 is reachable isn't sufficient. RPC initially contacts the RPC Endpoint Mapper on TCP 135, but the actual RPC session can then be assigned a dynamic RPC port. Microsoft notes that a common cause of RPC Server Unavailable is that the client reaches the endpoint mapper but cannot reach the dynamically allocated port afterward.

Since only some computers are affected, I suggest comparing an affected machine with a working machine.

First, from the affected machine:

Test-NetConnection CA-SERVER -Port 135

Then run:

certutil -config "CA-SERVER\CA-NAME" -ping

Run exactly the same commands from a working computer.

If TCP 135 succeeds on both machines but certutil -ping fails only on the affected machine, investigate the dynamic RPC connection next, not just port 135.

By default, modern Windows uses the dynamic RPC port range: TCP 49152-65535

Check whether a firewall, VLAN ACL, endpoint security product, Windows Filtering Platform rule, or other network/security control is treating the affected devices differently. Microsoft's RPC troubleshooting guidance specifically recommends checking the dynamically allocated port when TCP 135 succeeds, but the subsequent RPC connection fails.

I would also check the CA itself for Microsoft's documented AD CS/DCOM conditions.

On the CA, verify that Certificate Service DCOM Access contains NT AUTHORITY\Authenticated Users

Microsoft specifically identifies missing Authenticated Users membership in this group as one cause of certificate enrollment returning 0x800706BA.

Also verify on both the affected client and CA: HKEY_LOCAL_MACHINE\Software\Microsoft\OLE

and confirm: EnableDCOM = Y

Microsoft lists a disabled EnableDCOM as another documented cause of this enrollment error.

One more useful comparison would be:

gpresult /h C:\Temp\gpresult.html

on both a working and affected computer. Since only a subset of devices has the problem, look specifically for different security GPOs affecting DCOM, RPC, Windows Firewall, or endpoint hardening.

At this point, I wouldn't change the certificate templates or their permissions, because your forced enrollment is already succeeding. I also wouldn't broadly disable Windows Firewall or loosen DCOM security.

The most useful next test would be:

Working computer:

certutil -config "CA-SERVER\CA-NAME" -ping

Result: ?

Affected computer:

certutil -config "CA-SERVER\CA-NAME" -ping

Result: 0x800706BA

If the working computer succeeds while the affected one fails, that strongly indicates a client/network-specific RPC/DCOM restriction rather than an AD CS or certificate-template problem.

If you can provide the certutil -ping result from one working machine, that would be the best next comparison.