RPC_E_ACCESS_DENIED (0X8001011B): The Fix You Need

Why You're Seeing 0X8001011B

I know this error is infuriating. You're trying to run a remote management tool or connect to a server component, and bam — "Access is denied" with code 0X8001011B. I've seen this on Windows Server 2019 and 2022, especially when using PowerShell remoting or custom COM applications. The problem is almost always DCOM permissions. Let's fix it.

Cause #1: DCOM Launch and Access Permissions

This is the most common cause. The COM object you're calling doesn't have the right launch or access permissions for your user account. I've seen this happen with Exchange Management Console and SQL Server tools. The fix is in dcomcnfg.

Step-by-Step Fix

1. Press Win + R, type dcomcnfg, and hit Enter.
2. Expand Component Services > Computers > My Computer.
3. Right-click My Computer and choose Properties.
4. Go to the COM Security tab.
5. Under Launch and Activation Permissions, click Edit Limits.
6. Add the user or group that needs access (like NETWORK SERVICE or your domain user).
7. Check Remote Launch and Remote Activation permissions.
8. Under Access Permissions, click Edit Limits and add the same user with Remote Access.
9. Apply and restart the computer.

If the error happens with a specific application (like MMC or VBScript), you might need to find that COM object in the list and adjust its permissions individually. Search for the CLSID under DCOM Config.

Cause #2: User Account Control (UAC) Blocking Remote COM

Windows Server with UAC enabled can block remote DCOM calls for local accounts. This tripped me up the first time too. The fix is to either disable UAC or use a domain account with proper tokens.

Solution A: Disable UAC Temporarily

1. Open Local Security Policy (secpol.msc).
2. Go to Local Policies > Security Options.
3. Find User Account Control: Run all administrators in Admin Approval Mode.
4. Set it to Disabled. Reboot.

This is a blunt fix, but it works. For production, use a domain account instead.

Solution B: Use a Domain Account

Create a service account in Active Directory. Give it the same DCOM permissions as above. Run your call with that account. This avoids UAC issues cleanly.

Cause #3: Firewall Blocking RPC Ports

Sometimes the error isn't permission — it's the firewall dropping the RPC call. Windows uses a dynamic port range for RPC (often 49152–65535). If those ports are blocked, you get 0X8001011B.

Quick Check

netsh advfirewall firewall add rule name="RPC Endpoint Mapper" dir=in action=allow protocol=TCP localport=135
netsh advfirewall firewall add rule name="RPC Dynamic Ports" dir=in action=allow protocol=TCP localport=49152-65535

Run these commands on the server. Then test the connection again. I've seen this save hours of troubleshooting.

Quick-Reference Summary Table

One last tip: if you're still stuck, check the System and Application event logs. Look for event ID 10016 — that's the DCOM permission failure. It points you to the exact CLSID and user. That saved my bacon more than once.