none
Access Denied trying to Remote Control a user session

    Question

  • Brand new Win2k8 SP2 server that is also a domain controller. From an administrator session or any user who is a domain admin I can right click any other users session in the Terminal Services Manager and the Remote Control menu item is available however, no matter what state they are in, the icon shows a little red arrow pointing down. Once I click on Remote Control I get the Remote Control hot key assignment box. When I click on the OK button I get a dialog box with a header of Terminal Services Manager, in the body of the dialog box it says "Access is denied" and you have an OK button. There are no messages in the event logs. The session I am trying to remote control is a RemoteApp sitting on another workstation 3 feet away. The login it is using works fine with RemoteApp or a full RDP session either way. I currently am having NO problems connecting from any client to the server. Only from a remote session trying to remote control any other session.

    I can do CMD, shadow (id number), and take control of any valid session that way but since this will be used by managers to train others that's not an option for them.

    In the Default Domain Policy GPO and the Default Domain Controllers Policy I have enabled:

    Computer Configuration/Administrative Templates/Windows Components/Terminal Services/Terminal Server/Connections
    Policy: Set rules for remote control of Terminal Services user sessions
    Setting: Full Control without user's permission

    User Configuration/Administrative Templates/Windows Components/Terminal Services/Terminal Server/Connections
    Policy: Set rules for remote control of Terminal Services user sessions
    Setting: Full Control without user's permission

    In the Local Group Policy Editor (gpedit.msc) I enabled:

    Computer Configuration/Administrative Templates/Windows Components/Terminal Services/Terminal Server/Connections
    Policy: Set rules for remote control of Terminal Services user sessions
    Setting: Full Control without user's permission

    User Configuration/Administrative Templates/Windows Components/Terminal Services/Terminal Server/Connections
    Policy: Set rules for remote control of Terminal Services user sessions
    Setting: Full Control without user's permission

    In Terminal Services Configuration (properties for RDP-Tcp) I have permissions set on the Security tab for Domain Admins and Remote Dekstop Users. The users in question are all in the Remote Desktop Users group. The Remote Control tab shows the proper group policy setting of full control without user's permission.

    Local Security Policy user rights assignments are all good for actually connecting as users. Nothing there that I can tell that allows or disallows the remote control sessions.

    Each user I have tried this with I have edited their ADUC properties to be sure that Enable remote control is checked, require user's permission is not checked, and interact with the sesson is checked.

    Any ideas?

    Sunday, December 20, 2009 6:23 AM

All replies

  • Hi,

    The red down arrow icon next to each session is normal, although it is not intuitive.  Green up arrow icon indicates the current session, whereas red down arrow icon indicates other sessions.

    Remote Control of RemoteApp sessions is not supported.

    Are you able to successfully remote control a full desktop session using Terminal Services Manager?

    What is the OS version and Remote Desktop Client version of the client device you used to attempt to Remote Control another session (the Remote Controller or shadower)?

    What is the OS version and Remote Desktop Client version of the client device that you were attempting to Remote Control its session (the Remote Controllee or shadowee)?

    By default a Domain Admin has the ability to Remote Control other users, so you would only need to modify permissions if you wanted another group to have the ability to remote control.  After making changes to RDP-Tcp permissions you need to logoff/logon any user sessions that you intend to have the ability to remote control so that the change will take effect.

    Thanks.

    -TP
    Monday, December 21, 2009 5:52 AM
    Moderator
  • Are you able to successfully remote control a full desktop session using Terminal Services Manager?

    No, I am not able to remote control any session from either an administrator or Remote Desktop user.

    What is the OS version and Remote Desktop Client version of the client device you used to attempt to Remote Control another session (the Remote Controller or shadower)?

    Microsoft Windows Server 2008 Standard Version 6.0 Build 6002: Service Pack2 logged in as administrator.

    What is the OS version and Remote Desktop Client version of the client device that you were attempting to Remote Control its session (the Remote Controllee or shadowee)?

    OS Versions I have attempted to control: Windows XP Build 2600.xpsp_sp3_gdr.090804-1435 SP3, Windows Vista Build 6002 SP2, Microsoft Windows Server 2008 Standard Version 6.0 Build 6002: Service Pack2

    I can shadow ANY session successfully. I cannot Remote Control (right click session, select Remote Control) any session no matter who the user is or what operating system they are using.

    Monday, December 21, 2009 4:49 PM
  • Hello,

    I would start by removing all the settings from all places and start of by setting the shadow permission only in AD GPO. This should be sufficient to get it to work. From there I would start troubleshooting this issue and see if various settings would have different behaviours.

    Just a suggestion.........

    Robert
    Tuesday, December 22, 2009 3:46 PM
  • I don't know if this helps any but are you using dual monitors by chance?  Apparently that can be a problem.  See this thread:  http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2rds/thread/4d06278f-e0f4-4f8e-a8e1-3697ee967ef4

    Good luck,
    Tom

    Tuesday, December 22, 2009 4:25 PM
  • Hello,

    I would start by removing all the settings from all places and start of by setting the shadow permission only in AD GPO. This should be sufficient to get it to work. From there I would start troubleshooting this issue and see if various settings would have different behaviours.

    Just a suggestion.........

    Robert


    I have removed every Terminal Server setting in GPO, LGPE, Term Serv Configuration, and ADUC Users so that there are no policies in effect, run GPUPDATE, and then rebooted the server. After doing that I enabled only the Computer Configuration->Terminal Server settings for remote control. Still doesn't work, but I am still able to remote control ANY session using SHADOW (session ID).

    Windows Components/Terminal Services/Terminal Server/Connection

    Allow users to connect remotely using Terminal Services Enabled 
    Limit number of connections Enabled 
    TS Maximum Connections allowed 25

    Windows Components/Terminal Services/Terminal Server/Printer Redirection

    Redirect only the default client printer Enabled 
    Specify terminal server fallback printer driver behavior Enabled 
    When attempting to find a suitable driver: Default to PCL if one is not found. 
    Use Terminal Services Easy Print printer driver first Disabled 

    Windows Components/Terminal Services/Terminal Server/Profiles

    Set TS User Home Directory Enabled 
    Location: On the Local machine
    Home Dir Root Path: D:\Users
    If home path is on the network, specify drive letter for the mapped drive.
    Drive Letter Z:

    Windows Components/Terminal Services/Terminal Server/Session Time Limits

    Set time limit for disconnected sessions Enabled 
    End a disconnected session 8 hours 
    Set time limit for logoff of RemoteApp sessions Enabled 
    RemoteApp session logoff delay: 8 hours

    Currently I have ADUC enabled for the source of the individual user as to whether or not to allow Remote Control.

    Tuesday, December 22, 2009 7:53 PM
  • I don't know if this helps any but are you using dual monitors by chance?  Apparently that can be a problem.  See this thread:  http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2rds/thread/4d06278f-e0f4-4f8e-a8e1-3697ee967ef4

    Good luck,
    Tom


    I do indeed have dual monitors but I tried this on a single monitor system with the same result. I have three other servers configured exactly this way and none of them have this issue. I have compared them side by side and still no luck.
    Tuesday, December 22, 2009 7:57 PM
  • Well, since the same settings are working on other servers, I'd try removing and re-adding the Terminal Server roles.

    Good luck,
    Tom
    Tuesday, December 22, 2009 8:51 PM
  • I have exactly the same problem. I have been troubleshooting some time now, but haven't got a solution yet.

    Have you found a solution yet?

    Regards,

    Winzi
    Tuesday, January 5, 2010 1:29 PM
  • I'm in the same boat. Access is denied. Single monitors, all permissions set correctly. Removed and reinstalled the TS Role. Server 2008 Std. SP2. I have an identical system at another customer's site that works perfectly. Not Using remote app. Firewall is off. Has anyone found a solution to this?

    Kris Vanmoerkerque
    Thursday, June 10, 2010 12:50 PM
  • We've also the same issues. Recently we've installed Windows 2008 64bit terminal server with service pack to see if Microsoft has resolved the multiple monitor remote control issue. But it still doesn't work. Still the error Access Denied and also when you use the shadow.exe command no remote control.
    Tuesday, July 20, 2010 8:08 AM
  • How are you trying to control users session?

    Assuming you have your GPOs set up correctly, the issue may be with elevated rights.

    Try to do it through elevated command prompt (right click>Run as administrator), using "shadow <sessionid>" or through task manager (again has to be elevated, start it through elevated command prompt by typing "taskmgr" or find taskmgr.exe and right-click it and select Run as administrator) and on the users tab, right click the user's name and click Remote Control.

    You can also use Terminal services manager which will ask for elevated privileges on start.

    Good luck!

    Wednesday, July 21, 2010 9:27 AM
  • We are having the same issue, I have set permissions on two seperate Terminal Servers on one the user can remote control a user and on the other they get access is denied.  If however I add the user to the local administrator group on the one that they get the error on it then works.

    I have double and triple checked the settings are the same on both servers but this has been my only workaround to date.

    Regards

    Peter

    Wednesday, August 18, 2010 2:50 PM
  • Did you started Task Managed with administrative privileges? For me it helped. I simply created a shortcut on desktop and started over right click and selecting the Run as administrator.
    • Proposed as answer by Carbooja Friday, March 4, 2011 3:38 PM
    Wednesday, December 15, 2010 10:40 AM
  • Hey Guys,

    I'm having the same issue on a Terminal server farm that used to be quite stable and that operated without issue, Only during the last week has this started.

    All profiles except the one I'm logged on with shows "Red Arrow" and whenever I try to control a session I just get a black screen until the user accepts the session, then he gets diconnected and I get chucked back into my session. All the users can log in normally onto the farm however.

    What is strange is that I don't get "Access Denied" on every attempt, most of the time I don't get any indication as to what could be causing the error. I have tried running Terminal Services Manager with elevated privileges with the same result. I have found that when I try to log off a user using the users tab in task manager I get "Access is denied", so it would seem to be a permission issue. I am however a domain admin and had all the correct privileges as I was able to do this in the past, the event logs seem clear. Could this be an issue introduced in a new update?

    When running CMD and running "shadow ID" , I sometimes get an access denied, but most of the time I just black screen and then get dropped back into my session.

    Friday, March 18, 2011 6:20 AM
  • Hello I have a work around that isn't that great, but I RDP into the server, then I use the server RDP to localhost- admin, with this I can Remote Control the computers.  I am using Windows 7 32 bit, and this is happening because of the service pack install that happened.  I install the service pack with the new RDP 7 and now I can not Terminal Servies - Remote Control a session - into any server, unless it is a windows 2K server then the RDP 7 client works through the Terminal Services.
    Friday, March 18, 2011 11:27 PM
  • Any update on this ?

    Thanks

    • Proposed as answer by Niels adf Thursday, April 21, 2011 8:35 AM
    • Unproposed as answer by Niels adf Thursday, April 21, 2011 8:35 AM
    Thursday, April 14, 2011 12:51 PM
  • I have the exact same problem as described below.

    Nothing (settings) has been changed and now I cannot shadow anymore.

     

    Hey Guys,

    I'm having the same issue on a Terminal server farm that used to be quite stable and that operated without issue, Only during the last week has this started.

    All profiles except the one I'm logged on with shows "Red Arrow" and whenever I try to control a session I just get a black screen until the user accepts the session, then he gets diconnected and I get chucked back into my session. All the users can log in normally onto the farm however.

    What is strange is that I don't get "Access Denied" on every attempt, most of the time I don't get any indication as to what could be causing the error. I have tried running Terminal Services Manager with elevated privileges with the same result. I have found that when I try to log off a user using the users tab in task manager I get "Access is denied", so it would seem to be a permission issue. I am however a domain admin and had all the correct privileges as I was able to do this in the past, the event logs seem clear. Could this be an issue introduced in a new update?

    When running CMD and running "shadow ID" , I sometimes get an access denied, but most of the time I just black screen and then get dropped back into my session.

     

    Thursday, April 21, 2011 8:36 AM
  • What I've ended up doing  is setting up a virtual XP PC that I remote control, from there I then RDP to my terminal servers, I'm then able to shadow session and work as normal.
    Thursday, April 21, 2011 8:46 AM
  • Same problem

    Server 08r2 fully patched as a member of a forest and a domain controller.

    RDP onto the server as an administrator. Try to take remote control of a users rdp session on the same box and it fails except as CMD run as administrator or task manager run as administrator. Remote Desktop Services Manager fails with access denied even if run as administrator.

    Any ideas how to fix this, it is driving me crazy?

    Sunday, June 5, 2011 12:21 AM
  • Hi Everyone I have the exact same problem and after reading your comments i went to the help in Remote desktop Session Host Configuration and did a bit of reading, long story short i think the issue is very simple, well it has fixed it for me.

    Open Remote desktop Session Host Configuration right click on RDP-Tcp properties and go to the Remote Control Tab and change the level of control from View to Interact exactly how it is in AD properties of the User. Seems stupid that you have to change it in two places for it to work but that is Microsoft for you. Note it wont work for any users who have logged in so they will need to fully logoff and then back on for you to now be able to Remote control their sessions. Hope this sorts the issues out for everyone, good luck.

    • Proposed as answer by Mickmate Thursday, June 9, 2011 2:18 AM
    Thursday, June 9, 2011 2:16 AM
  • Hi,

    I am also getting this issue, not just on our server but most of our customer's server that we do not support, but reley on windows remote desktop remote control to shadow the session to support out software running on these servers.  the problem is always with windows 2008 R2 64 bit.  I have searched the web for a solution and none found.  Tried the fixes above and they do not work.  It is a major issue.  Does anyone know if microsft acknowledged this as a problem yet? is there a fix?

    Thursday, August 25, 2011 10:47 AM
  • pjflan i don't know if you already found a fix but this is from microsoft

     

    http://support.microsoft.com/kb/2273487/en-us

    Thursday, September 1, 2011 1:14 PM
  • ***********SOLVED :]

    Was having a similar issue where administrators could perform remote control but regular users get "Access Denied".

    Here are the steps I took to get it working:

    1. Open "Remote Desktop Session Host Configuration"
    2. Double click on "RDR-Tcp" in Connections box
    3. Set your remote control setting in "Remote Control" tab
    4. Click "Security" tab
    5. Click "Advance"
    6. Double click on "Remote Desktop Users"
    7. Check Allow "Remote Control" and "Messages" checkboxes
    8. Click OK -> OK then Reboot

    I wanted to give all Remote Desktop Users ability to remote control, but if you want to give specific user or group remote control access, just add them and set the same access.

    • Proposed as answer by mperez.ecoc Saturday, October 1, 2011 5:11 PM
    Saturday, October 1, 2011 5:08 PM
  • This worked for me, thanks!
    Drew Cain
    Monday, November 28, 2011 4:47 PM
  • This works for RDP connected sessions. But you can now publish an RDP connection that automatically executes an application. This new method is called "Remote Application". To my knowledge remote control of these sessions is not yet supported. Any knowledge if this has been changed or resolved yet?

     

    For more information on "Remote Application", see http://blogs.technet.com/b/askperf/archive/2008/02/22/ws2008-terminal-services-remoteapps.aspx

    Thursday, December 15, 2011 7:06 PM
  • Worked like a charm. I would never have figured this particular one out at the office as every system around here has multiple monitors.
    Thursday, December 29, 2011 9:28 PM
  • I was having a problem where even administrators could not control a users session. This was a progressive issue where it work for a long time and then ceased working on different servers at different times. This fixed the problem for me.

    Why the setting become overridden I do not know, must be a Microsoft patch / service pack.

    Thursday, December 29, 2011 10:40 PM
  • I have a problem where at times I can not remote control users and at other times it works fine, I have noticed that mostly I can not remote control them when when users are away (idle or desktop locked, something like that). 

    I have also noticed that after some time when I am connecting to different users from Remote Desktop Services Manager, user sessions start to get disconnected on my attempt to connect. To fix this I need to relogin to the server from which I am connecting. This server from which I am connecting to users is a dedicated session broker server for RDSH farm.


    RDSH 2008 R2.

    • Edited by Aurimas N Wednesday, October 31, 2012 8:52 AM
    Wednesday, October 31, 2012 8:48 AM
  • Not sure this is still relevant for you, but for future googlers, here is what i found. I had this issue, couldnt take remote control of anyones sessions (on any of my 12 servers) and a box coming up saying "access denied" after a while i found that the problem was my duel monitors, so logging off the RDC session, changed the settings to only use 1 monitor, logged back in and it worked! so simple, but a weird bug.
    Monday, September 15, 2014 5:06 AM
  • This is not a bug.  It is just another in the long list of failures by Microsoft to support their management applications in the real world. If the session user you are trying to shadow has dual monitors, it will not work under any circumstances regardless of how many monitors you may have. While other remote support applications have the ability to shadow multiple monitor sessions, Microsoft's tools do not.  This makes them basically useless, which is what you could say about all of Microsoft's products.

    Have you noticed that no configuration in any management console will ever carry over from one session to another?  Open any management console and configure columns widths, or turn off the action pane, then close the management console and start it again. Nothing is saved. You have to configure your view every time you start the tool.  This is not the behavior the snap-ins used to demonstrate, but Microsoft has now deemed this unimportant.  It just is another in the incredibly long list of abuses Microsoft perpetrates on their users who are tasked with managing Windows environments on a day to day basis.

    Microsoft just does not get it.  They have completely lost what it is they do and as a result will eventually be binned because management personnel will look for alternatives to make their lives easier and it is no longer going to be Microsoft.  Since Microsoft has made a conscious decision to abandon the GUI for management (a GUI which actually built their monopoly), they are no longer relevant.  They are just another megalithic and abusive thorn in the side of IT.

    Thursday, January 8, 2015 3:17 PM