Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

In order to conserve server resources, I would like to enable a GPO which terminates disconnected RDP sessions after a certain time period. However, there are times when we might want to bypass this setting to accomplish a one-off task.

When connecting to Server 2003, this could be accomplished by using /console (or /admin depending on your RDP client version). As stated in the GPO settings information, this allows you to bypass the idle timeout settings: "If you have a console session, disconnected session time limits do not apply."

However, in Server 2008, there is no more console session available to RDP users, it's restricted to services only. Is there any work around for this? We would really like to avoid having disconnected sessions that sit around indefinitely, but want to retain the ability to bypass this for one-off processes, as you could in Server 2003.

share|improve this question

3 Answers 3

up vote 0 down vote accepted

I used to work in an environment that mandated a one minute disconnected session limit. It drove me crazy. I can't tell you how many times an install or config was killed in the middle when I lost my connection to the server. I did however eventually find a workaround. Change the following registry value as shown:

Key:   HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Value: MaxDisconnectionTime
Type:  DWORD
Data:  0

This is the value set by the policy "Set time limit for disconnected sessions". It's stored as a millisecond value. If you set it to zero before connecting to the server, your session will not be disconnected. You'll need to change it back when you are done, though. Also keep in mind that this generally requires you to have local administative rights on the subject server but it sounds like you ARE the admin there.

share|improve this answer

Look at creating a 'service' user account and put it in a security group.

apply a GPO to the security group with: Windows Components/Remote Desktop Services/Remote Desktop SEssion Host/Session Time Limits/ set to however much time it will need. I think that would solve your problem if you connect as said 'service' user.

share|improve this answer
    
This might work, although we might need to create several different accounts due to the variety of environments. Not at a bad approach though! –  user3208219 Jan 18 at 0:32
    
Plus, now you're sharing passwords... –  charleswj81 Jan 18 at 4:00

If you configure those settings under User Configuration rather than Computer Configuration then you can use Security Filtering on the GPO to make it apply only to specific users (members of a security group used as the filter in the GPO).

share|improve this answer
    
In this case we would actually be controlling the application of the GPO by membership in a group, however removing people from the group temporarily would be one way to approach it. –  user3208219 Jan 18 at 0:31
    
All users who SHOULD have the setting applied SHOULD be members of the group. All users who SHOULD NOT have the setting applied SHOULD NOT be members of the group. When users who ARE members of the group log on to the server the session time limits WILL be applied. When users who ARE NOT members of the group log on to the server the session time limits WILL NOT be applied. You can adjust the membership of the group as needed to apply or not apply the setting to the appropriate users. –  joeqwerty Jan 18 at 0:39
    
Right, but ultimately it requires administrative intervention, which we wanted to avoid. With 2003 servers, using /console gave the user an easy way to bypass the GPO and keep a session going for one-off tasks. I don't see any easy way to mimic this bypass with 2008. –  user3208219 Jan 18 at 0:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.