When does this error show up?
You're running a Windows Server, maybe 2016 or 2019, and a client app tries to call a COM+ component on a remote machine. Or you have a script that uses DCOM to automate something like Excel, and boom – you get 0x8001011F. The full message says 'This operation returned because the time-out period expired'. The culprit here is almost always a firewall blocking the dynamic RPC ports, or the DCOM server is slow to respond.
I've seen this most often in two scenarios:
- When you move a COM+ app from one server to another and forget to open the firewall ports
- When a client machine has a stale DCOM identity (like a cached credential that doesn't match)
Root cause
DCOM uses RPC (Remote Procedure Call) to talk between machines. RPC first connects on port 135 (the endpoint mapper), then it negotiates a random high port (usually 49152-65535) for the actual data. If the firewall blocks those high ports, the call hangs until it times out – that's your 0x8001011F.
Another common cause: the RPC service itself is slow. Maybe the server is overloaded, or there's a DNS issue where the client can't resolve the server name quickly. Or the DCOM identity – the user account running the component – doesn't have the right permissions on the remote machine.
The fix – step by step
Step 1: Check firewall settings on the server
Open the Windows Firewall with Advanced Security on the server. Make sure you allow inbound traffic on port 135 (TCP) and a range of high ports for RPC. Here's the command to add the rule for the high ports:
netsh advfirewall firewall add rule name="RPC High Ports" dir=in action=allow protocol=TCP localport=49152-65535Don't bother with just port 135 – that's not enough. The real fix is opening the full range.
Step 2: Verify the RPC service is running
On both client and server, check if the Remote Procedure Call (RPC) service is running. Open services.msc, look for 'Remote Procedure Call (RPC)'. It should be running. If it's not, start it and set it to Automatic.
Step 3: Check DNS resolution
From the client, ping the server by its FQDN. If it resolves to a different IP or times out, fix your DNS. Use nslookup server.domain.local to see what's happening.
Step 4: Reset the DCOM identity
Sometimes the problem is a stale credential. Open dcomcnfg, go to Component Services > Computers > My Computer > DCOM Config. Find the component that's failing. Right-click, Properties, go to the Security tab, and set the Launch and Activation Permissions to 'Use Default'. Then restart the DCOM service:
net stop RpcSs && net start RpcSsStep 5: Increase RPC timeout (last resort)
If it's still failing, you can bump the timeout from the default 60 seconds. Create a registry key on the client:
HKLM\SOFTWARE\Microsoft\Rpc\Timeouts
Add DWORD: 'ConnectionTimeout' = 120000 (in milliseconds)Don't do this unless you've ruled out firewall and DNS – it's just masking a bigger problem.
If it still fails
Check the Application event log on the server. Look for DCOM errors with event ID 10010 or 10005. Those give you the exact CLSID of the failing component. Also check if the user account running the DCOM call has 'Log on as a batch job' and 'Log on as a service' rights on the server. You'd be surprised how often missing those causes this exact timeout.
One more thing: if you're using Windows Server Core (no GUI), you can't run dcomcnfg. Use dcomcnfg.exe from a remote admin console, or edit the registry directly. But honestly, 90% of the time it's the firewall ports. Open them, and it'll work.