Windows session timeouts on Citrix – a brief guide

Wow, it’s been way too long since I wrote a blog article or recorded a video. Let’s start changing that!

Today we’re going to cover the subject of session timeouts in Citrix virtual desktop or app environments (you could easily extend this to RDSH, AVD, Parallels, in fact any Windows-based remoting). Securing your estate by setting appropriate timeouts to lock machines and/or disconnect/reset sessions is something that it’s important to get right but can often be misunderstood.

Let’s get some fundamentals in first so we understand our subject.

What can we configure?

You can configure the following timeout triggers in Windows environments:-

Machine inactivity limit – this is the amount of time that must elapse without any user input on the host VM (the virtual desktop or session host running the user’s desktop or app) before the session is considered inactive.
Active time limit – this is the amount of time that must elapse, even when the session is active, before the session is considered over threshold.
Idle time limit – this is the amount of time that must elapse without any user input from the client device to the session host before the session is considered idle.
Disconnection time limit – this the amount of time that must elapse when a session is in a disconnected state before it is considered over threshold.

When any of these thresholds or states are met, a configurable action can be taken. For inactive sessions, you can simply choose to lock it. For active, idle, or disconnected thresholds, you can choose to disconnect the session, or reset (end) it.

You can use a mixture of Group Policies and/or Citrix policies to configure various blends of policies, including doing different settings for different groups of users.

This means it is important, for each group or “persona” of users, to identify what settings they need applied. Often security mandates will drive the requirements which you will need to incorporate. As an example, here’s a set of settings for “basic” users:-

Machine inactivity limit – 15 minutes
Action on machine inactivity threshold – lock machine
Active session time limit – None
Action on active session time limit threshold – None
Idle session time limit – 2 hours
Action on idle session time limit threshold – Disconnect session
Disconnected session time limit – 2 hours
Action on disconnected session time limit threshold – Reset session

You would need to repeat this for each set of users. For this basic user persona, we have chosen to lock the virtual session after 15 minutes of inactivity, disconnect the session after two hours of idle time, and then reset the session after two hours of being in a disconnected state.

Machine inactivity limit

The “machine inactivity limit” GPO was introduced in Windows 8 and Server 2012 but is not simply limited to these OSes – it will work on any machine that can understand Group Policy (so Windows 2000 and up). It is a policy aimed at “interactive” sessions which used to mean “console” logins, but since Windows 8 all RDSH connections are considered “interactive” logins anyway, so this GPO will suffice.

It is found at Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Security Options | Interactive logon: Machine inactivity limit. You can enable this and then set the required amount of time (in seconds) before an inactive session on the session host will lock. Once the policy is applied for the first time, it generally requires a restart to take effect. Interestingly, the absolute maximum you can set for this policy is (as of Windows 11) 599,940 seconds (which is roughly 166 hours).

However, the “machine inactivity limit” GPO is a Computer level setting, so you cannot skin different inactivity limit timeouts for different groups of users on the same devices. If you did need different settings for this policy for different user groups on the same devices, you would need to use the method specified below.

If you needed to apply these settings on a per-user basis to shared machines, then you would probably need to leverage the old “screen saver” setting which is a User Configuration item. I would recommend that you should use the “machine inactivity limit” GPO wherever possible, and if different settings are required for different groups of users, keep the devices in separate OUs or filter the GPOs specifically to them. If you cannot avoid applying these per-user on the same machines, use the settings below

The path for the screen saver should be set as

%windir%\system32\rundll32.exe user32.dll,LockWorkStation

which means that the machine will simply lock, rather than running a screen saver.

But as I said previously, hopefully you are running up-to-date operating systems and not needing to push different user settings for this onto the same devices. As “machine inactivity lock” is fairly non-intrusive compared to the other policies, often a single blanket setting will suffice, so it should be good enough for most if not all environments.

Also, it is worth noting that if you are running Windows 10 or 11 virtual desktops via Citrix VDAs, the “machine inactivity limit” GPO (or the screensaver setting, for that matter) will not work unless you enforce the following Registry change first (also requires a reboot). I generally apply it as part of the same policy object that sets the machine inactivity limit.

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Graphics
SetDisplayRequiredMode
DWORD 0

Other session settings

Now this is where it starts to get a bit complicated 🙂 The other sets of settings we referred to earlier (active limits, idle limits, and disconnection limits) can be configured in different ways dependent on whether you are using RDSH, multi-session, or single-session instances.

RDSH refers to Remote Desktop Session Host which is available only on Server OS versions of Windows (so RDSH 2012, 2016, 2019, 2022, etc.)

Multi-session refers to hosts that can host multiple users, so this includes RDSH as above, but also includes Windows 10 and Windows 11 multi-session (which do not use RDSH, and therefore certain limitations apply).

Single-session refers to hosts that can host single users, so no RDSH or multi-session Windows, but old-style “client” Windows running Windows 11, Windows 10, 8.1 etc. Just to confuse you even more though, this could include some server operating systems but only if they had the Citrix VDA installed with the /SERVERVDI switch (which essentially turns Server OS into a single-session box).

The reason for the delineations is that the basic Microsoft GPOs dealing with session limits only apply to RDSH. If you need to apply these sets of settings to single-user OSes or Windows 10 and 11 Multi-User instances, you will need to leverage Citrix’s special policy settings that can apply the same settings to single-user or non-Server multi-user instances (or even the rarely-seen single-session /SERVERVDI instances that don’t use RDSH). Also (apologies as this is probably getting more and more complicated), you can also use Citrix’s policy settings to manage your RDSH systems. And you can even add your Citrix policies into AD if you choose to install the right extensions. And use Citrix’s filtering to target groups, or built-in AD security filtering.

Clear? Yeah, thought not.

RDSH-specific

Firstly, all the RDSH policy settings are available as both Computer and User GPOs. So if you need different sets of settings for different sets of users, use the User settings (with loopback applied as required). If you don’t need different sets, then just use Computer and save some processing time.

Also, the RDSH settings can be additionally configured on Active Directory user objects (as shown below) as well as via Group Policies. Do yourself a favour and don’t use the settings on the AD user objects, stick to policy.

There is one policy setting that you’d want to configure globally for RDSH, and it’s the one below –

This setting refers to the threshold for both Active and Idle limits and means that rather than disconnect a session that has breached either of these limits, it will end it completely (reset it). Unless you’re actively trying to annoy your users or you have a security mandate specifically demanding it, I’d leave this setting as Not Configured or Disabled.

Now let’s break out the other thresholds we can configure.

Active session limits

You can configure active session limits, so this is simply a maximum amount of time any user desktop or application session can last. Even if the user is slap-bang in the middle of something and beavering away on an important document, when this threshold is reached, their session will be disconnected or reset dependent on how you have configured it. For obvious reasons, this setting is not commonly used outside of high security environments. I have seen estates where admin RDP sessions have an active session limit configured, but even that seems to only succeed in annoying people.

If you did decide to configure active session limits, use the following policies:-

For RDSH only

Set the policy to Enabled and select a limit for active sessions.

For single-user OS, W10/11 MU or RDSH

Both of these settings simply enable the timer for an active session (on either single-user or multi-user/RDSH hosts).

Also, you need to configure the following policies as well, choose the one for the appropriate host type

Idle session limits

Idle session limits are much more likely to be used. This means the amount of time that the session (not the machine) is idle. For posterity, the first setting we showed “Machine inactivity limit” refers to inactivity on the host the user is connected to. So the screen will lock if there is no user input on the desktop or application they are using. If the user has a script or other long-running task executing on the desktop or app they are using, the screen will not lock.

Conversely, the idle time settings refer to lack of input from the user’s client device to the remote host running their desktop or app. So for these settings, if a user has a long-running task executing on the remote desktop or app and is not otherwise interacting with it, the session will be seen as idle and the threshold will be eventually met even if the user leaves the automated task running on their resource. If you have users (like devs, or RPA bots) that routinely have long-running tasks, you will need to configure their idle and disconnected settings to ensure that their tasks are not terminated when the thresholds are reached. Or they could download something like Andy Morgan’s Caffeine, which sends keep-alives down the virtual channel to the remote resource, preventing the idle timer from reaching threshold (security implications of this aside).

So, to configure your idle session limits, use the following policies as appropriate:-

For RDSH only

Add the value as required.

For single-user OS, W10/11 MU or RDSH

These two settings, as before, simply enable the timer as required for the idle interval, you also need to configure one (or both) of the following settings for the amount of time before a disconnection is processed.

Disconnected session limits

Finally, we come to the settings for disconnected session limits. If a user session is disconnected (either deliberately by the user, by a network outage, or by the idle or active thresholds being reached) then this specifies the amount of time that must elapse before the session will be totally ended. Again, you need to understand user requirements in order to make the appropriate calculations for the values you will use.

For RDSH only

Add the value to the policy as required.

For single-user OS, W10/11 MU or RDSH

These two settings, as before, simply enable the timer as required for the disconnection interval, you also need to configure one (or both) of the following settings for the amount of time before a reset of a disconnected session is processed.

Once these settings are configured as required, you should now be able to apply them to your target machines and see the appropriate timeout settings taking effect. Some of these policies require a restart of the target devices before they start working.

Additional settings

There are a couple of other settings maybe worth mentioning among these glut of policy objects:-

This, obviously, sets a timeout for any RemoteApp sessions which are generally left disconnected after the session ends, and not logged off. You can configure this to make sure they are appropriately closed off.

Remote PC instances have their own disconnected session timer for some reason – if you’re using RPC, then set the value here for disconnected sessions.

There is also this

Citrix Policies | Computer | ICA | Server limits | Server idle timer interval

This looks like a Computer-level setting for an idle timer disconnection interval, should you wish to use it instead of the Citrix user-level one specified above.

Summary

Session timeouts are a bit of a minefield, with the interplay between RDSH/multi-user/single-user making it difficult to decide which settings to use, as well as the obvious discrepancy between how the “machine inactivity limit” measures an inactive device compared to the policies that RDSH and Citrix use to measure idle time. This can make it challenging to come up with the right settings for your user environments in terms of security and usability, but hopefully this blog can unmuddy the waters ever so slightly.

Stay tuned – hopefully now my house renovation is nearing an endgame, I may have more time for blogging and vlogging, fingers crossed.

4 comments

Ray Davis says:

March 9, 2023 at 2:29 pm

Good Break down and very useful information.

Digital Archaeologist says:

August 11, 2023 at 1:44 pm

Perfect article to share with a Droplet Computing customer 🙂 Thanks

Matt says:

November 21, 2023 at 6:43 am

Hi James, great article!

For RDSH do you need to set both Group Policy and Citrix policy or will just GP suffice?

1. James Rankin says:
  
  November 21, 2023 at 8:29 am
  
  Either will do, I believe.

What can we configure?

Machine inactivity limit

Other session settings

RDSH-specific

Active session limits

For RDSH only

For single-user OS, W10/11 MU or RDSH

Idle session limits

For RDSH only

For single-user OS, W10/11 MU or RDSH

Disconnected session limits

For RDSH only

For single-user OS, W10/11 MU or RDSH

Additional settings

Summary

Leave a Reply to Ray Davis Cancel reply