0X00001B8B

Fix ERROR_CTX_SHADOW_DISABLED (0X00001B8B) Remote Control

Remote control fails with 0X00001B8B when shadowing is off in RDS settings or Group Policy. Quick fixes: enable shadowing per session or via GPO.

I've seen this error pop up more times than I'd like to admit. You're trying to remote control a user's session to help them out, and instead you get hit with ERROR_CTX_SHADOW_DISABLED (0X00001B8B). The message says: "The requested session is not configured to allow remote control." Infuriating, right? Especially when you've got a user on the line waiting for help.

The good news is that this error is almost always a configuration issue, not a broken system. I'll walk you through the three most common causes and the exact fixes. Start with the first one—it's the culprit in about 80% of the cases I've handled.

Cause 1: Remote Control is Disabled on the Session or Server

By default, Windows Server (2016, 2019, 2022) doesn't allow remote control of user sessions unless you turn it on. This is the #1 cause of 0X00001B8B. The setting is buried, and most admins forget about it until they need it.

How to Fix It

On the RDS host (the server hosting the sessions), open Remote Desktop Services Manager. Right-click the server name in the left pane, select Properties, then go to the Remote Control tab. You'll see a drop-down—make sure it's set to Full Control without the user's permission or Full Control with user's permission, depending on your policy. I'd recommend without permission for internal IT staff, but check your org's rules.

Click OK, and try connecting again. If you're still getting the error, the setting might be overridden by Group Policy—move on to Cause 2.

Also, if you're dealing with a Citrix environment, the same logic applies. In Citrix Studio, go to the Policy settings and look for Shadowing. Sometimes Citrix has its own shadowing policy that overrides the RDS setting.

Cause 2: Group Policy Overrides Shadowing Settings

If you've enabled shadowing on the server and it still fails, a Group Policy Object (GPO) is probably overriding it. This is sneaky because the GPO can apply at the domain level or local level, and it might not be obvious which one is winning.

The Fix

Open the Group Policy Management Console (gpmc.msc) and check the GPOs that apply to your RDS host. Look for this policy path:

Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Connections

Find Set rules for remote control of Remote Desktop user sessions. If it's set to Disabled, that's your problem. Set it to Enabled and choose the level of control (Full Control without user's permission is typical for help desk).

Then run gpupdate /force on the server and test again. You might need to reboot the server in rare cases if the policy doesn't take effect immediately. I've seen that happen on Server 2016—annoying, but a quick reboot sorts it.

One more thing: if you have multiple GPOs, check the precedence. The last one applied wins. So if you have a GPO that sets it to Disabled at a higher level, that will win over a lower-level GPO that enables it.

Cause 3: User Account or Session Permissions

Even if shadowing is enabled at the server and policy level, the specific user session might have restrictions. This is less common, but I've seen it when users are members of protected groups or when the RDS host has custom permissions.

What to Check

First, make sure you have the right permissions. You need to be in the Remote Desktop Users group or have the Remote Control permission on the RDS host. If you're an admin, you're likely fine, but don't assume—check.

Second, if the user is a local admin on their machine, sometimes the session gets elevated privileges that block shadowing. Try connecting to the session as the same user or use the mstsc /shadow:<sessionID> command to specify the session ID directly.

For Citrix, check if the user is in a delivery group with shadowing disabled. Citrix policies can restrict shadowing per user or group, so you might have to adjust the policy.

Also, verify that the session is in an active state. You can't shadow a disconnected session unless you allow it in the settings. In the Remote Desktop Services Manager, right-click the session, go to Properties, and check the Remote Control tab for that specific session. Some GPOs can force a level that doesn't apply to disconnected sessions.

Quick Reference Table

CauseSymptomFixTime to Apply
Remote control disabled on serverError on all sessionsEnable in RDS Manager > Server Properties > Remote Control2 minutes
Group Policy overridesError persists after enabling server settingEdit GPO to enable shadowing, run gpupdate /force5 minutes + GPO refresh
Session permissions or stateError only on specific sessions/usersCheck permissions, session state, session-specific settings10 minutes

I know this error is annoying, but the fixes are straightforward. Most of the time it's the server setting, so start there. If you've tried all three and still get the error, double-check your RDS version—older versions like Server 2008 R2 have quirks with shadowing, and you might need to apply a hotfix. But for modern servers, these steps will get you back to helping users without the headache.

Related Errors in Database Errors
0X000013DF Fix 0X000013DF: Corrupt Cluster Database Backup HY000 / 2006 SQLSTATE HY000 General Error 2006 — The MySQL server has gone away 0XC0190019 STATUS_LOG_GROWTH_FAILED 0XC0190019: Log space creation failed SQL Server does not exist or access denied Fix 'SQL Server does not exist or access denied' error on login

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.