Windows Server CA: RPC Error 1722 & “Invalid Pointer” (0x80004003)

{:de}

In former Small Business Server (SBS) environments, many administrators encounter a seemingly mysterious problem: A freshly installed Certificate Authority (CA) on a new Windows Server refuses to issue certificates, even though the installation and setup went through without errors.

Especially in scenarios in which the old SBS structures still “reverberate” in Active Directory, the modern architecture of Windows Server 2025 can stumble.

In this article, we analyze the case where an RPC error 1722 and an invalid pointer (0x80004003) blocked the issuance of certificates, and why the solution lay in the detail of DCOM group membership.

The starting point

We operate in a domain that originated on a small business server.

• Old (Legacy): The SBS acted as an “all-in-one” solution: it was a domain controller (DC), Exchange server, and certificate authority (CA) all in one. Remnants of this configuration (groups, attributes, etc.) are still contained in Active Directory!
• New: A fresh Windows Server 2025 has been added to the domain as a member server. The role of the CA has been cleanly reinstalled there.

After setup, we tried to request a certificate via the classic CA web portal (/certsrv) as well as via the local MMC. The process broke off immediately. Instead of an issued certificate, we received the following error message:

“Error in request… Result: Invalid pointer 0x80004003 (E_POINTER) … CCertRequest::Submit: Invalid pointer 0x80004003.”

At the same time, event logs and tests (e.g. via certutil) pointed to an RPC error 1722 and missing DCOM rights.

The analysis: Why “invalid pointer”?

The error code 0x80004003 (E_POINTER) is a generic COM error. It occurs when an application expects a pointer to an object, but null it is.

In the context of the CA, this means that the web enrollment form attempts to call the method CCertRequest::Submit on the CA service via DCOM (Distributed Component Object Model). If the security check for this DCOM call fails, the connection is blocked before the service can return a valid response object. The web application gets “nothing” back and interprets this as an invalid pointer.

So the actual cause is not a software error, but an authorization problem.

The “SBS Legacy” Effect

On the new CA server (Windows Server 2025), we checked the DCOM access groups. This is where the problem was buried, hidden in the legacy of the domain structure.

1. Default on member servers: Normally, a CA uses the local group “Certificate Service DCOM Access”. In a clean environment, the setup there often adds “Authenticated Users” and “Domain Computers”.
2. The problem: Due to the history of the domain or strict default settings, only “Domain Users” were included in the access group.
3. The gap: In an Active Directory domain, domain controllers (DCs) are not members of the Domain Computers group. They have their own organizational unit and group (“Domain Controllers”).

Since the CA consults with the AD (and thus the DCs) for certain checks, access failed due to the lack of authorization in the DCOM ACL.

The problem with “Authenticated Users”

In a clean environment, the Authenticated Users group is best practice and automatically includes the DCs.

SBS context: In old SBS domains, the right “Access this computer from the network” was often massively restricted via GPO or the group “Authenticated users” was removed for security reasons (hardening). Therefore, “Authenticated Users” often does not apply in this particular scenario.

Why not just add the Domain Controllers group?

This is where the peculiarity of the old SBS environment comes into play. In many cases, simply adding the Domain Controllers global group is not enough. Due to problems with GPO (User Rights Assignment) restrictions from SBS times, the permission via the group is often not resolved correctly or quickly enough.

The solution was therefore explicit: Authorize the computer accounts of the domain controllers individually.

The solution: step-by-step

To fix the error 0x80004003 and RPC 1722 , the DCOM rights on the CA server must be adjusted.

Important: Add the DCs’ computer accounts directly, don’t rely on group nesting in old domain structures!

1. On the new CA server, open Computer Management (compmgmt.msc).
2. Navigate to Local Users and Groups -> Groups.
3. Locate the Cert Service DCOM Access group (or “Certificate Services DCOM Access”).
4. Click Add, change the object type so that computers are also searched.
5. Now find and add each of your domain controllers individually (for example DC01$, , DC02$).
6. Optional, but recommended: Restart the server to ensure that all DCOM services load the new ACLs.

Certificate requests should now work immediately.

Note: In legacy SBS environments, it is often observed that the resolution of the Domain Controllers group is unreliable, which is why direct entry of the DC computer account is the most robust solution.

Background: Why this difference?

It helps to understand why SBS environments are so vulnerable here:

Recommendation for Windows Server

Never run a CA on a domain controller. The separation of roles increases security and facilitates later migrations. However, if you are migrating from an old structure, always check the memberships of the local DCOM group first in case of errors. The error 0x80004003 in Web Enrollment is almost always an “Access Denied” in the guise of DCOM.

In environments that were formerly based on Small Business Server (SBS), many administrators encounter a seemingly mysterious problem: A freshly installed Certificate Authority (CA) on a new Windows Server refuses to issue certificates, even though the installation and setup appeared to complete without errors.

Especially in scenarios where old SBS structures still “echo” within Active Directory, the modern security architecture of Windows Server 2025 can stumble.

In this article, we analyze a case where an RPC Error 1722 and an Invalid Pointer (0x80004003) blocked certificate issuance, and why the solution lay in the details of DCOM group membership.

The Situation

We are operating in a domain that originated on a Small Business Server.

• Old (Legacy): The SBS functioned as an “All-in-One” solution: It was the Domain Controller (DC), Exchange Server, and Certificate Authority (CA) all in one. Remnants of this configuration (groups, attributes, etc.) still exist in Active Directory!
• New: A fresh Windows Server 2025 was joined to the domain as a Member Server. The Certificate Authority role was cleanly installed on this new server.

After setup, we attempted to request a certificate via the classic CA Web Enrollment portal (/certsrv) as well as via the local MMC. The process aborted immediately. Instead of an issued certificate, we received the following error message:

“Error in request… Result: Invalid Pointer 0x80004003 (E_POINTER) … CCertRequest::Submit: Invalid Pointer 0x80004003.”

In parallel, Event Logs and connection tests (e.g., using certutil) pointed to an RPC Error 1722 and missing DCOM permissions.

The Analysis: Why “Invalid Pointer”?

The error code 0x80004003 (E_POINTER) is a generic COM error. It occurs when an application expects a pointer to an object, but the pointer is null.

In the context of the Certificate Authority, this means: The Web Enrollment form attempts to call the CCertRequest::Submit method on the CA service via DCOM (Distributed Component Object Model). If the security check for this DCOM call fails, the connection is blocked before the service can return a valid result object. The web application receives “nothing” back and interprets this as an invalid pointer.

The underlying cause is essentially not a software bug, but a permission issue.

The “SBS Legacy” Effect

We checked the DCOM access groups on the new CA server (Windows Server 2025). This is where the problem was buried, hidden within the legacy burdens of the domain structure.

1. Standard on Member Servers: Normally, a CA uses the local group “Cert Service DCOM Access”. In a clean environment, the setup often adds “Authenticated Users” and “Domain Computers” to this group.
2. The Problem: Due to the domain’s history or strict historical presets, the access group only contained “Domain Users”.
3. The Gap: In an Active Directory domain, Domain Controllers (DCs) are not members of the “Domain Computers” group. They have their own Organizational Unit and group (“Domain Controllers”).

Since the CA consults AD (and thus the DCs) for certain checks, or because the DC itself initiated the request, the access failed due to missing permissions in the DCOM ACL.

The Problem with “Authenticated Users”

In a clean environment, the “Authenticated Users” group is Best Practice and automatically includes DCs.

SBS Context: In old SBS domains, the user right “Access this computer from the network” was often massively restricted via GPO, or the “Authenticated Users” group was removed from permissions for hardening reasons. Therefore, “Authenticated Users” often does not apply in this specific scenario.

Why not simply add the “Domain Controllers” group?

This is where the peculiarity of the old SBS environment comes into play. In many cases, it is not sufficient to simply add the global “Domain Controllers” group. Due to issues with GPO restrictions (User Rights Assignment) dating back to SBS times, permissions via the group are often not resolved correctly or quickly enough.

The solution was therefore explicit: Authorize the computer accounts of the Domain Controllers individually.

The Solution: Step-by-Step

To fix error 0x80004003 and RPC 1722, the DCOM rights on the CA server must be adjusted.

Important: Add the computer accounts of the DCs directly; do not rely on group nesting in old domain structures!

1. Open Computer Management (compmgmt.msc) on the new CA server.
2. Navigate to Local Users and Groups -> Groups.
3. Locate the group Cert Service DCOM Access (or “Zertifikatsdienste DCOM-Zugang” in German systems).
4. Click on Add, change the Object Type so that Computers are also searched.
5. Search for and add each of your Domain Controllers individually (e.g., DC01$, DC02$).
6. Optional, but recommended: Restart the server to ensure that all DCOM services load the new ACLs.

Certificate requests should now function immediately.

Note: In old SBS environments, the resolution of the ‘Domain Controllers’ group is frequently observed to be unreliable. Therefore, explicitly adding the DC computer account represents the most robust solution.

Background: Why the Difference?

It helps to understand why SBS environments are so susceptible here:

Recommendation for Windows Server

Never operate your CA on a Domain Controller. Separating roles increases security and facilitates future migrations. However, if you are migrating from an old structure, always check the memberships of the local DCOM group first if errors occur. Error 0x80004003 in Web Enrollment is almost always an “Access Denied” in DCOM disguise.