Fix EPT_S_CANT_PERFORM_OP 0x6D8 on Windows Server

What Is EPT_S_CANT_PERFORM_OP (0x000006D8)?

This error appears when a client machine tries to make a remote procedure call (RPC) to a server, but the server's endpoint mapper can't complete the operation. You'll usually see it in Event Viewer, in application logs, or when a management tool (like an RDP or a backup agent) tries to connect. The exact code is 0X000006D8, and it's part of the EPT_S error family.

The common trigger? A service on the target server has stopped or is misconfigured. Often it's the Remote Procedure Call (RPC) service itself, but it can also be a dependent service like DCOM Server Process Launcher or RPC Endpoint Mapper. I've seen this happen after a Windows Update, after a network policy change, or when a third-party firewall blocks dynamic ports.

Here's the plan. Start with the 30-second fix. If that doesn't work, move to the 5-minute fix. If you're still stuck, do the 15-minute one. You can stop as soon as the error clears.

Fix 1: The 30-Second Check

This fix takes under a minute. You're going to verify that the core RPC services are running and restart them if they're not.

1. Press Win + R, type services.msc, and hit Enter.
2. Look for these three services:
   • Remote Procedure Call (RPC)
   • RPC Endpoint Mapper
   • DCOM Server Process Launcher
3. Check the Status column. All three should say Running.
4. If any are stopped, right-click and select Start.

After starting them, try the operation that gave you the error. If it works, you're done. If not, proceed.

But here's a nuance: even if they're running, sometimes the RPC service gets stuck. So do this anyway:

1. Right-click Remote Procedure Call (RPC) and select Restart.
2. Wait 10 seconds.
3. Now restart DCOM Server Process Launcher the same way.

When you restart DCOM, the RPC service will also restart because it depends on it. That's normal. After that, check if the error is gone.

Fix 2: The 5-Minute Firewall Check

If the services are fine, the likely culprit is your firewall. Windows Firewall or a third-party firewall (like Symantec or McAfee) can block the dynamic ports that RPC uses. By default, RPC uses port 135 for the endpoint mapper, but the actual data transfer happens on random high ports (usually 49152-65535). If those are blocked, you'll get 0x6D8.

Here's how to check and fix it:

1. On the server, open Windows Defender Firewall with Advanced Security (search for it in Start).
2. Click Inbound Rules on the left.
3. Look for a rule named Windows Management Instrumentation (WMI) or Remote Event Log Management—those are common ones that depend on RPC. If they're disabled, enable them.

If you don't see a specific rule, you'll need to create one to allow RPC dynamic ports. Here's the command—run it in an elevated PowerShell (right-click, Run as Administrator):

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

That allows inbound traffic on the high port range. Then also add a rule for port 135:

netsh advfirewall firewall add rule name="RPC Port 135" dir=in action=allow protocol=TCP localport=135

After running those, test again. If the error persists, you might need to restrict the dynamic port range—some environments don't allow the full range. You can set a specific range in the registry (I'll show you in the next fix).

Another quick thing: check if the client and server are in the same domain or workgroup. If they're not, you might need to enable File and Printer Sharing exceptions, which also use RPC. Go to Control Panel > System and Security > Windows Defender Firewall > Allow an app or feature through Windows Defender Firewall, and make sure File and Printer Sharing is checked for Private and Public.

Fix 3: The 15-Minute Registry and DCOM Tweak

If you've gotten this far, the problem is likely a misconfiguration in the RPC settings or DCOM permissions. This fix takes longer because you'll edit the registry and possibly restart the server.

Step 1: Set a Fixed RPC Port Range

Sometimes the default dynamic port range is exhausted or blocked. Setting a fixed range can help. You do this in the registry.

1. Open Regedit (Win + R, type regedit, Enter).
2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy. If RpcProxy doesn't exist, create it (right-click on Rpc > New > Key, name it RpcProxy).
3. Inside RpcProxy, create a new DWORD (32-bit) value named Ports (if it's not there).
4. Set its value to something like 5000-5100 (choose a range you're comfortable with).
5. Also create a DWORD named PortsInternetAvailable and set it to 1.

After that, you need to add a firewall rule for that specific range:

netsh advfirewall firewall add rule name="RPC Fixed Ports" dir=in action=allow protocol=TCP localport=5000-5100

Now restart the Remote Procedure Call (RPC) service. You'll need to reboot the server for the registry change to fully take effect—don't skip this.

Step 2: Check DCOM Permissions

If you're still seeing the error, open Component Services and look at the default DCOM permissions.

1. Press Win + R, type dcomcnfg, and hit Enter.
2. Expand Component Services > Computers > My Computer.
3. Right-click My Computer and select Properties.
4. Go to the Default Properties tab. Make sure Enable Distributed COM on this computer is checked.
5. Go to the COM Security tab. Under Access Permissions, click Edit Limits. Make sure Everyone has Allow on both Local Access and Remote Access.

If Everyone isn't listed, add it. Apply and OK.

Step 3: Verify Time Sync

This is a sneaky one. If the server and client clocks are more than 5 minutes off, Kerberos authentication fails, which can cause RPC errors like this. Check the time on both machines:

w32tm /query /status

If they're off, resync with:

w32tm /resync
Then try the operation again.
When None of This Works
If you've tried all three fixes and the error still shows up, you might be dealing with a corrupted system file or a third-party service that's interfering. Run sfc /scannow in an elevated command prompt to check for corruption. Also look in Event Viewer under Windows Logs > System for any related errors (like DCOM 10005 or RPC 8003). Those will point you to the specific component that's failing.
I've seen cases where the fix was simply disabling IPv6 on the server's network adapter—RPC sometimes struggles with dual-stack networks. You can try that in Network Connections > Properties, uncheck Internet Protocol Version 6 (TCP/IPv6), and reboot.
Remember, this error is almost always about RPC connectivity. Be patient, go through the fixes in order, and you'll get it sorted.