Fix RPC_S_NO_CONTEXT_AVAILABLE (0X000006E5) on Windows

What triggers this error

You get error 0X000006E5 when one program tries to act as you (impersonate) but Windows says "no security context is available". This usually happens with remote management tools like PowerShell Remoting, WinRM, or backup software that runs tasks on another computer. The real trigger? Some service or script tries to double-hop — connecting from PC A to PC B, then PC B trying to access PC C as you. Windows blocks that second hop unless you set up delegation.

Cause #1: Missing or broken constrained delegation

This is the most common cause. When a service account (like a SQL Server or backup agent) needs to access resources on another server as you, Active Directory must trust that service to do so. If delegation isn't configured, you get 0X000006E5.

How to fix it

1. Open Active Directory Users and Computers on your domain controller. You need Domain Admin rights for this.
2. Find the computer account that hosts the service (the one trying to impersonate you). Right-click it, choose Properties.
3. Go to the Delegation tab. You should see three radio buttons. If you don't see the button, your domain functional level is probably below Windows Server 2012 — you'll need to upgrade it first.
4. Select "Trust this computer for delegation to specified services only".
5. Choose "Use Kerberos only" unless you're told to use any protocol.
6. Click Add. In the dialog that pops up, click Users or Computers and type the target server name (the one the service needs to reach). Click OK.
7. Now pick the services this computer can delegate to. Common ones are cifs (file access), http (web), time (time sync), or host (many things). Select what matches your scenario. If you're unsure, select all that apply.
8. Click OK on all dialogs. After that, wait a few minutes for Active Directory replication to happen, or run gpupdate /force on the source computer.

Expected outcome: After delegation is set, the service should be able to impersonate you to the target server. Test by running the failing command again. If it still fails, move to cause #2.

Cause #2: CredSSP is not enabled (for PowerShell remoting)

If you're using Enter-PSSession or Invoke-Command to connect from one computer to another, and then from there to a third machine, PowerShell blocks the second hop unless you enable CredSSP. This is a common secure design, but it catches people off guard.

How to fix it

1. On the computer you're connecting from (the client), open PowerShell as Administrator.
2. Run: Enable-WSManCredSSP -Role Client -DelegateComputer "*" or specify a specific computer name like "SRV-BACKUP". The asterisk delegates to all, which is fine for testing. For production, be specific.
3. You'll see a message asking to confirm. Type Y and press Enter.
4. On the computer you're connecting to (the first remote server), run the same but as a server: Enable-WSManCredSSP -Role Server
5. Now you need to allow CredSSP through Group Policy. On the client machine, run gpedit.msc (or secpol.msc on some editions).
6. Go to Computer Configuration > Administrative Templates > System > Credentials Delegation.
7. Double-click "Allow delegating fresh credentials with NTLM-only server authentication". Set it to Enabled. In the options, click Show and add wsman/* (for WinRM) or * for all. Click OK.
8. Close Group Policy Editor. Reboot both machines, or run gpupdate /force on each.

Expected outcome: Now when you use Enter-PSSession with the -Credential parameter, you should be able to hop again. Test by running: Enter-PSSession -ComputerName SRV-BACKUP -Credential yourdomain\you -Authentication CredSSP. If it asks for a password, CredSSP is working.

Cause #3: Service account lacks permission to impersonate

Sometimes the error isn't about delegation or CredSSP. It's simpler: the service account running the program doesn't have the "Impersonate a client after authentication" user right. This is common with custom services or scheduled tasks that run as NT AUTHORITY\NETWORK SERVICE.

How to fix it

1. Open Local Security Policy on the machine where the service runs. You can type secpol.msc in Run (Win+R).
2. Go to Security Settings > Local Policies > User Rights Assignment.
3. Find the policy named "Impersonate a client after authentication". Double-click it.
4. Click Add User or Group. Type the name of the service account (e.g., NT AUTHORITY\NETWORK SERVICE or DOMAIN\SvcSQL). Check spelling — it's case-sensitive but not strict on spaces.
5. Click Check Names to verify it resolves. Then click OK.
6. Close the policy window. Then open an elevated Command Prompt and run gpupdate /force.
7. Restart the service that was failing. You can do this from Services.msc or with Restart-Service -Name "YourServiceName" in PowerShell.

Expected outcome: After restarting the service, test the operation that gave you error 0X000006E5. It should succeed now. If it doesn't, reboot the machine — some services cache the policy only at startup.

Quick reference summary table

Start with cause #1 if this happens in a domain environment. If it's a local machine or a script, go straight to cause #3. The CredSSP fix is only for PowerShell remoting scenarios. Don't guess — check the event logs for the source of the call (Event ID 1053 often helps identify the service).