A new feature, regardless of how stunning or life changing it may be, is only useful if you can put it into practice. I had this issue with one of the new features of XenApp 6.5 and I thought you might like to see how I’ve put this together in my own deployments and why I think it should be one of the first things you do for your own builds. I’m more of a visual learner so hopefully this will help a few of you out too.
A bit of background
Before we go forward, lets take a few steps back over some familiar technology.
Remember in the old days when you would launch a Presentation Server app with a click of an icon and…wait…wait…logon script fires up…profile loads…wait a moment more…ta-dahh, you’re app is ready? Well we, and a few other clever partners, managed to reduce application launch time by doing clever things with the user profile or just trimming the fat that was the traditional roaming profile. But it was never going to be ‘like-local,’ which is really the end-goal of any virtual desktop solution.
In XenApp 6.5 we’ve cracked this launch delay by using a combination of the latest Windows Receiver and a new feature called Session Pre-Launch. Using this feature will mean than any application will start up immediately, without any delay.
For the end user , they will log on to their desktop session and launch their apps as usual. These might be icons on the desktop or in the start menu, it doesn’t really matter. What differs from the older versions of XenApp (and Presentation Server) is that as soon as their desktop has fired up, a silent connection is immediately made to the XenApp farm. Why is this good? Well, as a session is already loaded onto the XenApp farm and all the logon procedures like the profiles loading, logon scripts running and the commitment of policies has already taken place, when the user clicks on their application it launches without any hesitation. Straight away. Immediately. Just like local. Result!
For the end user, who we care about the most at Citrix, this is a big leap forward because they can do more, more quickly which should mean more time for tea breaks. I mean, they’ll be more productive
For the admin there are a few things to consider and this is where I thought this article might help a few of you out, as the documentation, while being easy to understand, isn’t full of examples which are how I tend to learn more easily.
Licensing and Resource Implications
The main architectural considerations around this are quite minimal but do need to be understood. Even though this session isn’t running an application in the usual context, it is a session on a XenApp farm and as such it will take a XenApp/XenDesktop licence and a RDS CAL. The first reaction to hearing this is something like “you are @&$@$!£ joking!” but bear with me. Yes this takes a licence before any real work is done but your user has a Receiver, is logged into a desktop, and will be using a Citrix resource soon (unless they’re a complete slacker on a long tea break) so this isn’t really a big deal, in my opinion. If they’ve already logged on to a Hosted VDI or Hosted Shared Desktop then they’ve already taken a licence anyway.
A few people have raised concerns about how their CCU and user/device licensing will be affected if they implement Session Pre-Launch. The good news is that it will not consume any more licences than before.
Let’s take the CCU model first as that’s the most obvious one for existing XenApp customers. The way this works is that a new user will initially be given a device licence which is basically glued to the device they first log in from. Let’s say the first time I connect I use a Macbook Air. When I launch my virtual desktop I have taken a single CCU licence with the device ID of my Mac. When the Receiver inside my virtual desktop starts up a Pre-Launch Session it’s using pass-through (not pass-through authentication, pass-through for the licensing) and the licence server still only uses a single CCU licence because we pass through that initial device ID into the application connection. When I open up a few applications I’m still only using one licence. If I use a thin client in the afternoon, the licence server knows I’m using a different device but I’m still only taking up one CCU licence, even though I’m doing a bunch of different things from different devices. This assumes you don’t have two individual sessions open from those devices. Workspace control is your friend in this situation and doesn’t change to the way CCU has always worked.
The difference will come from me logging on to a physical Windows desktop with a Receiver installed on it. Now pay attention because I think this sparked off most of the fears. In this example the Receiver on my PC will make the first connection to the XenApp farm and start a Pre-Launch Session as soon as I’m logged into my physical Windows desktop. I may log into my PC at 8:30am but won’t actually start up any XenApp apps until 9am. In this case the first licence would be consumed at 9am. With Session-Pre Launch configured the licence would be checked out at 8:30am because it is the Receiver making that silent connection on it’s own, without user interaction.
For those of you on a user/device model for XenApp or XenDesktop your users will already have been assigned a licence (or perhaps just your devices have been licensed) based on their behaviour patterns. So even if you had one user making 100 connections from 10 different devices to your farm, they will only ever take up 1 user licence.
So really what are you losing? Not much really. Your licences will be taken up in the same quantity as they would be before but just a little earlier in the day.
As for resources consumed on the server, the Pre-Launch Session will take up a very small amount of memory and CPU by running the pre-launch exe, but hardly enough to even notice as it’s not really doing anything after launch. Besides, when the user actually launches an application, the Pre-Launch exe is killed off and your ‘real’ applications take over so you’re always going to be running on a very shallow level of resource consumption. Think of it like putting a traffic cone on your parking space. It’s small, takes up no room and is a lot smaller than the car you’re going to park there shortly anyway.
Life Cycle of a Pre-Launch Session
Firstly lets talk about how the Pre-launch Session works because it does differ slightly to what you might be used to.
When the Receiver starts up and passes through the user credentials to the XenApp server, if a Pre-Launch session is in that users application set, a Pre-Launch session is created on a XenApp server. The exact server it goes to is defined by load balancing in the usual way.
If you look at your management console you’ll see the session look like this:
Nothing is displayed to the end user. This is a silent, invisible connection.
To take away the admin worry of hundreds of sessions sitting there all day doing nothing we have policies that can disconnect them after a set period too. More on policies later when I show you how I’ve set it up.
Once this pre-launch session has been created by the Receiver we’re in familiar territory for those you who already use XenApp as we’re using session sharing. As you may already know, if I log onto a XenApp server and launch an application, Word 2010 for example, I’ll create one ICA connection to that box. If I then chose to open Excel 2010 the XenApp server can use the same session and Excel will start up straight away. It does this because I’ve already authenticated, logged in, ran my logon scripts and loaded my profile when I started up Word. Sound familiar? Yes, same underlying technology, just tweaked a little bit for the new Session Pre-Launch feature.
Anyway, when the user starts a application we use the invisible session created by the Pre-Launch Session on the XenApp server. After the application has appeared on the user’s desktop, the Pre-Launch Session on the XenApp server is gone. This is because that session is now used by the application that just started, as you can see from this screen shot below. The session that was called Pre-Launch is now used by the user’s application. Notice the session ID is the same. This is the key thing to understand.
Subsequent launches of other applications will also start straight away as we will use good old session sharing, but what happens if a user closes down that first application before firing up another one 10, 20 or 30 minutes later? No problem, we have that covered too.
In the example I’m showing you Word has taken the session from the Pre-Launch Session and is running fine. If I close down Word it doesn’t go into a disconnected state as you would normally experience. The session now goes into what is called a Lingering State.
What this means is that the session on the XA server that I’ve just closed down is now running in the background, waiting for the user to fire up another application. This performs the same function as the first Pre-Launch Session. It is a session that’s already been logged into, but it’s waiting to be connected to again. Just because it happens to be from an application doesn’t matter one bit, it’s job now is to maintain a connection to the Receiver so that when the end user does want to run another application like Excel, it will launch immediately using that existing session. I’m saying ‘session’ a lot so I do hope this makes sense to you!
Session Pre-Launch Policies
As with most things in XenApp, this function is controlled by using policies. The Pre-Launch Session is started by the Receiver and can be set to stay alive for a set period of time if an application isn’t started up to consume it. In the example below I’ve allowed my user to log in and then walk away for a coffee but so long as they start an application up within 60 minutes they’ll experience no delay in the application starting up. If they take any longer than 60 mintues my policy will drop the Pre-Launch Session into a disconnected state and 30 minutes after that I will terminate it. Ideally you should set this in line with your users’ behaviour patterns and lunch breaks to maintain a level of performance and expectation so 60 mins is probably a sweet spot.
If they’ve launched an application and then closed it the session will go into a Lingering State. As mentioned before, this is session that can be quickly used by any new application launch too. You’ll likely still want to control this in the same way as the pre-launch session and I’ve done the same thing here. A policy has been set up to disconnect the Lingering session after 30 minutes and terminate it after another 15 minutes. Don’t worry too much about reconnecting to disconnected sessions as our excellent engineers have reduce the time taken to do this by 50%, but if you get the policies right this will be your backup plan for worst case users.
I tend to set these timings the same as the Pre-Launch ones to keep a consistant experience for the users. Users don’t like change but they love performance. Two other important things to keep in mind.
How do I actually make a Pre-Launch Session?
Now that we have our policies in place I can take you through actually setting up the Pre-Launch Session. A Pre-Launch Session is based on an existing published application on your XenApp farm. To create one pick an app, any app for now, and right click on it in the AppCenter console. Go down to ‘Other Tasks’ and select ‘Create Session Pre-Launch Application.’ This will create something called ‘Pre-Launch MyAppName.’
This is not your published application and will not be accessed by a user. It also has no bearing on the .exe that the application was pointing at either, despite the name it will be given. To avoid confusion, if you’re doing this as you read this, rename this to ‘My Pre-Launcher.’ I tend to put it in its own folder too, just to humour my admin OCD.
So what have we actually created and why have we created it from an existing published app? ‘My Pre-Launcher’ has taken the configuration from your published app for things like configured servers, users and advanced features like the colour depth and encryption. Think of it as a configuration template with just the bare bones. This is important because for Session Pre-Launch to work, the applications have to use the same settings. This is why it’s easiest to base the Session Pre-Launch on existing apps. Notice that the actual .exe this uses is now CtxPreLaunch.exe.
If you have a flat XenApp farm where any application can launch on any server then you can get away with just a single Pre-Launch Session leaving that to load balance awaiting the user to begin work. However if you have specific apps on certain servers you can use another method to ensure all yours apps will fire up right away.
I work a lot with Worker Groups in XenApp as it’s a flexible way of chopping up a farm rather than silo’ing servers manually. In my example I’ve got a farm with three servers in it split over two Worker Groups. Two servers host the common apps like Office and Adobe Reader but the third server is a physical server with a powerful GPU card in it for 3D work. I’ve created two worker groups to reflect this, one called SE Production and one called SE HDX3D.
Because I have two Pre-Launch apps, one for each Worker Group, this means that when I log into my desktop I will get a Pre-Launch Session started on both worker groups. To the end user it means that regardless of whether I start a regular app published on my SE Production Worker Group or the HDX3D one, ALL of my apps will start right away. And because I’m using load balancing across my farm I don’t need to worry about which server the Pre-Launch Session starts on, only that it is going to launch on something in the worker groups. It just works.
And that’s it. Zero wait for end users.
Ok that was a lot to read through, but I really do hope it either made it a bit clearer or pushed you to use this in the future, because it’s something that the end users will really notice.
I’m looking for some good honest comments from this so please put yours below. If I’m way off the mark with how you do it, lets get some ideas out there on how to improve it.