#Citrix #XenApp #Citrix XenApp #Citrix Concurrent License #Citrix Licensing #Citrix Policies
With Citrix, session limits have a significant impact on Citrix concurrent licensing. Concurrent licensing gives the ability to control licensing with simple Citrix policies to enforce session limits. I would like to share a scenario where I saved $3,000,000.00.
Session limits consist of:
- Idle Time to reset – session is inactive, the user has minimized or locked workstation.
- Idle Time to disconnect – session is inactive, the user has minimized or locked workstation.
- Disconnect to reset – session is emulating disconnected state and available for reconnecting.
Based on experience, it is possible to host 30,000 end-users with 20,000 Citrix licenses. This article will demonstrate how you can bring these cost savings to your organization. Once achieved, you carry this forward as the solution grows. This scenario assumes a single pool of licenses shared by all lines of the organization.
The goal is maximizing the return on investment in Citrix concurrent licensing. If a reset or disconnect interval is unlimited, the end-user session remains intact consuming a license at 3 AM or 3 PM. That license is “checked-out” for that user regardless. That license would remain consumed until the user logs back on or the hosting server reboots. Citrix policies allow a few simple settings that return that license to the pool for end-users logging in at various times. They allow for end-users at three shifts per site to leverage one license for three people due to shift differentials.
You can have one broad Citrix policy or several. The ability to assign policies a value and apply to users, servers, or other variables is a testament to the power of Citrix and only further empowers the cost save opportunity. That is $3,000,000.00, and the original cost per is below retail price on a 20,000 concurrent license purchase. When is your next SA renewal?
Consider that idle time is the interval where a user does not use the application. Here I have multiple options;
- Set the session to reset after 60 minutes returning that licensee to the pool
- Set the session to disconnect after 60 minutes allowing more time for the user
- On the disconnect to reset give the end-user another 10 minutes allowing for workstation reboots, power outages or Internet connectivity glitches
The key is here knowing when to reset and when to disconnect, what the intended purpose of those settings is, and how they apply to your organization.
The disconnected state serves multiple purposes in that a disconnected state might happen for users working from home before the 120-minute timeout. Most of us utilize this setting today to accommodate for the link, hardware, the Internet or other failures where the hosting Citrix server retains that session. During the “idle state” the sessions appear “active” regardless of use. During the “disconnect state,” the session shows “disconnected” allowing end-users to reconnect.
The delta here is how quickly that session emulates a disconnected state. If the user clicks on the application too soon, they start a new session versus connecting to the disconnected session, continuing where they left off. If the time is off, we now have two licenses used where we had only one.
To maximize licensing, set idle timeout to 120 minutes and disconnect not reset. If someone leaves for lunch or early, that returns that license to the general pool. Again, notice the term “idle timeout”; this is the amount of time the end-user can be away from their desktop or minimize the application. During this “idle time”, the session appears as “Active”. During the “disconnect state,” the session shows “disconnected.” allowing end-users to reconnect. I want that “disconnected” to remain so for 10 additional minutes for reasons mentioned above.
I further maximize by documenting all remote sites:
- Total number of end-users
- Number of shifts per site (this might be one, two or more)
- Shift differentials (vary from site to site)
- Precise hours of shift differentials
- Bandwidth usage per each site
- Geographic dispersion
- Time Zones
If remote site A has 300 users that work three work shifts at eight hours that is maximum 100 licenses. This is further maximized by site with the two-hour revert to disconnect state for 10 minutes and then reset.
The disconnect timeout is often misconfigured. The default time for “disconnected state” is ten minutes. Why not set the “disconnected idle” to 120 minutes? Leaving the “Idle time to disconnect” at 120 minutes gives the user two hours of having an “Idle session” on their workstation minimized to the task bar. At any point in that two hours if the end-user uses the Citrix hosted application the “Idle time to disconnect” timer is reset to 120 minutes. The “disconnected state” by comparison does not show on the taskbar but instead still active on the Citrix hosting server.
The “disconnected state” where the application disappears from the screen but still active on the Citrix hosting server fills a gap. This was intended to provide users enough time to reconnect after a network glitch or other random disconnect where the application seems to disappear. This timeout and modification of the “ICA KeepAlive” value is a further tweak to this setting. Users retain their work after a mishap, not a timeout based on usage. It is important to understand that the disconnected idle timeout is a stop gap for users connected and working in the hosted application.
If this setting is unset or unlimited, a user can disconnect their session instead of logging off, and that license never returns to the pool. With that said, you might have scenarios requiring an infinite disconnect. The goal here is to leverage policies by assigning just those users, not all users. This one change returns all licenses that were infinite in ten minutes. In my experience, ten minutes is the magic number that provides enough time to reboot, log on, launch the application and still retain the information. Otherwise, they fall under the 120 minute of “inactive state” and ten additional minutes would make no difference.
That disconnected state consumes a license for 10-minutes. The idle state for 120 minutes consumes a license. With a few simple settings, you can minimize your licenses used by end-users, using the application. Analysis of all variables mentioned above allows for maximizing these settings after identifying patterns and documenting every user, every site, for all of the criteria.
You can set it to allow for scenarios like a coffee break. Your first active state disconnect is two hours. If they work for an hour and take an hour break that session still has another hour before disconnect state. That covers 99% of your scenarios.
If you do not configure the post disconnected state what happens is a reset. You want that user to get their initial connection back after rebooting their ISP modem, logging in and that is ICA KeepAlive. If they login too quick, they have an active session, and now they have two sessions because the other session is still active.
The ICA KeepAlive helps you address scenarios where a user disconnected for other reasons out of his control. It has to be short enough to show disconnected state on the hosting Citrix server, or they cannot reconnect to that session. I use a 60 second ICA KeepAlive, with a 10-minute disconnect after 120 minutes of no activity.
If someone is gone two hours he most likely won't log in two hours and four minutes later. So where's the catch?
If you allow a session to sit for two hours as active, that session remains for 120 minutes, then reverts to a disconnected state. However, what about users that have worked for three hours and you have a network outage? To the hosting Citrix server, that session shows “active state”, and if that user logs on after disconnecting during two-hour window, they get a new
That is where policies help. Emphasize the define and discovery phases as part of the design strategy. The policies can also be included as an afterthought to streamline existing implementations; it's never too late.
This is where knowing the user interaction per application reduces licensing cost further.
Example - Call Center
Users at a remote site, three shifts in a call center with 30-minute breaks for lunch and a T1 line that is unstable. I would use a ten minute grace period for no activity. With 30 minutes for lunch and each shift disconnected twice a day but with fast recovery, those call center users need a session that reverts to a disconnected state faster. Alternatively, maybe that does not matter at all. In that case, there is no need for the active session so to force resets after one minute of no activity the system could go to the disconnected state.
The line goes down; everyone is disconnected, and by the time they log back in they get their session back and lose nothing, or alternatively the session is reset, so they get a new session every single time.
Citrix Policies are one of the key differences over Terminal Server. GPO is great and powerful but has limited enforcement options.
That is handy when you have a remote site with a private network and an Internet connection. Rather than drop in a Multiprotocol Label Switching (MPLS) 1] or Optical Carrier network line (OC-48) 2] one can use Netscaler in the DMZ and Secure Gateway LB VIP, enable the client header and enforce policies for users, whether they are in a workgroup or in a different forest in a recently acquired company.
In summary, if your Citrix licensing agreement is concurrent consider the cost savings of the holistic licensing methodology.