A new feature, regardless stunning or life changes, it may be, is only useful if you can the practice. I had this problem with one of the new features in XenApp 6.5 and I thought you'd like to see how I put it together in my own deployments and why I think it should be one of the first things you do for your own built. I'm more of a visual learner so we hope this will help some of you too.
A little history
Before moving forward, lets take a few steps back on a familiar technology.
Remember in the old days where you want to launch an application Presentation Server with a click of an icon and ... wait ... wait ... ... ignites login script load profile ... wait a moment ... ta-dahh, you're app is ready? Well, we and some other smart partners, managed to reduce application launch time by doing smart things with the user profile or just trim the fat that was the traditional roaming profiles. But it was never going to be "like local", which is really the ultimate goal of any virtual desktop solution.
In XenApp 6.5, we cracked this launch delay using a combination of the latest version of Windows receiver and a new feature called pre-launch session. Using this feature means that any application will start immediately without any delay.
For the end user, they will connect to their desktop session and launch their applications as usual. These could be icons on the desktop or in the start menu, it did not really matter. This differs from previous versions of XenApp (Presentation Server and) is that once their office has fired a silent connection is immediately set to the XenApp farm. Why is this good? Well, as a session is already loaded on the XenApp farm and all login procedures such as load profile, the logon scripts running and the political commitment has already occurred when the user clicks on their application, it launches without hesitation. Right now. At once. Just as local. Result!
For the end user, which concerns us most to Citrix, this is a great 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 administration, there are a few things to consider, which is where I thought this article might help some of you, documentation, while being easy to understand, is not full of examples are how I tend to learn more easily.
Licensing and Resource Implications
The main architectural considerations around that are quite minimal, but should not be included. While this session is not running an application in the usual context, there is a session on a XenApp farm and as such, it will take a XenApp / XenDesktop license and an RDS CAL. The first reaction to hearing this is something like " you @ $ & @ $! £ kidding! " but bear with me. Yes, it takes a license before the actual work is done, but your user has a receiver is connected to a desktop computer, and will be using a Citrix resource soon (unless they are a complete slacker on a long tea break) so it does not really a big deal, in my opinion. If they are already connected to a hosted VDI and Hosted Shared Desktop when they have already taken a license anyway.
concerns Some people have raised about how their CCU licenses and user / device will be affected if they implement pre-launch session. The good news is that it will not consume more licenses than previously.
Take the first CCU model as is most obvious for existing XenApp customers. The way it works is that a new user will first be given a device license is essentially stuck to the device of their first connection from. Let's say the first time I connect I use a Macbook Air. When I run my virtual office I took a single CCU license with my Mac device ID. When the receiver inside my virtual desktop starts a pre-launch session uses pass-through ( not authentication pass-through, pass-through for licensing ) and the License Server still uses only one license CCU because we go through this initial device ID in the application's connection. When I open some applications that I'm still using only one license. If I use a thin client in the afternoon, the license server knows I'm on another device, but I'm still just taking a CCU license, even if I do a lot of different things to different devices. This assumes that you do not have two individual sessions open from these devices. the workspace control is your friend in this situation and does not change how CCU has always worked.
The difference will come to connect to a physical Windows desktop with a receiver installed. Now, pay attention because I think this has triggered fears most. In this example, the receiver to my PC will make the first connection to the XenApp farm and start a pre-launch session as soon as I am connected to my physical Windows desktop. I can connect to my PC at 8:30, but does start XenApp applications until 9am. In this case, the first license is consumed at 9am. With pre-launch session-configured license would be checked at 8:30 because it is the receiver making this silent connection on its own, without user interaction.
For those of you on a model user / device for XenApp or XenDesktop your users have already been awarded a license (or maybe just your devices were allowed) according to their behavior. So even if you had a user performing 100 connections from 10 different devices to your farm, they never take up one user license.
So really what you lose? Not much really. Your license will be taken in the same amount as they would before, but just a little earlier in the day.
Regarding the resources consumed on the server, the pre-launch session will take a very small amount of memory and CPU running the exe pre-launch, but barely enough to notice that does not really do anything after launch. In addition, when the user actually launches an application, the pre-launch exe is killed and your "real" applications take over so that you will always be running at a very low level of consumption Resource. Think of it as putting a traffic cone on your parking space. It is small, takes up no space and is much smaller than the car you are going to park there soon anyway.
Cycle of a pre-launch session Life
lets first talk about how the pre-launch session works because it differs slightly what you may be used.
When the receiver starts and passes through the user's credentials to the XenApp server, if a pre -Launch session is that application users Overall, a pre-launch session is created on a server XenApp. The exact server it runs is defined by load balancing as usual
If you look at your management console, you will see the eyes of the session like this :.
Nothing is displayed to the end user. This is a silent invisible connection.
To remove the concern of Directors of hundreds of sessions sitting there all day doing nothing, we have policies that can disconnect after a set period too. More information on the latest political when I show you how I made.
Once this pre-launch session was created by the recipient, we are familiar territory for those who already use XenApp you as we re using session sharing. As you may know, if I log on to a XenApp server and launch an application, Word 2010, for example, I'll create an ICA connection to the box. If I chose to open Excel 2010 the XenApp server can use the same Excel session and starts immediately. He did this because I have already authenticated, logged, ran my logon scripts and loaded my profile when I got up Word. Sound familiar? Yes, the same underlying technology, all twisted a bit for the new pre-launch session functionality.
Anyway, when the user starts an 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. Indeed, this session is now used by the application that has just begun, as you can see from the screenshot below. The session was called pre-launch is now used by the application to the user. Notice the session ID is the same. This is the key to understanding.
subsequent launches other applications will also start right away we'll use a good old session sharing, but what happens if a user closes this first application before shooting each other 10, 20 or 30 minutes later? No problem, we covered that too.
In the example I show you took the Word session of the pre-launch session and works very well. If I close down word, it is not going in a disconnected state as you would normally experience. The session is now in what is called a Lingering State.
What this means is that the session on the server XA I just closed is now running in the background, waiting for the user to take another application. This performs the same function as the first pre-launch session. It is a session that has already been logged, but is waiting to be connected again. Just because it happens to be an application does not matter a bit, it is the job now is to maintain a connection with the receiver so that when the end user does not want to run another application as Excel, it will immediately start to use existing session. I say 'session' a lot so I hope this makes sense to you!
Political Session Pre-Launch
as with most things in XenApp, this feature is controlled through policies. the pre-launch session is started by the recipient and can be set to stay alive for a set period of time if an application starts not to consume. in the example below, I allowed my users to connect, and then walk for a coffee, but as long as they launch an application within 60 minutes, they will experience no delay in startup application. If they take longer than 60 mintues my political will drop the pre-launch session in a disconnected state and 30 minutes after that I'll end it. Ideally, you should set it in line with the models behavior of your users and lunch breaks to maintain a level of performance and therefore waiting 60 minutes is probably a sweet spot.
If they 've launched an application, and then closed the session will go into a Lingering State. As mentioned earlier, this is the session that can be quickly used by any new application launch also. You will probably still want to control it in the same way as the pre-launch session and I did the same thing here. A policy has been implemented to disconnect the session Lingering after 30 minutes and end after 15 minutes. Do not worry too to reconnect to disconnected sessions that our excellent engineers reduce the time required to do this 50%, but if you get the right policies that will be your backup plan for the worst case users.
I tend to define these timings the same as pre-launch to keep a consistent experience for users. Users do not like change, but they love the 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 effective implementation of the pre-launch session. A pre-launch session is based on a published application on your existing XenApp farm. To create a pick an application, any application for now, and right-click it in the AppCenter console. Go down to "other tasks" and select "Create session pre-launch application. This will create something called "MyAppName pre-launch.
This is not your published application and will not be accessible by a user. It also has no impact on the .exe file that pointed the application is, despite its name, it will be given. To avoid confusion, if you do what you're reading this, rename this' My Pre-Launcher. "I tend to put in its own folder too, just to humor my OCD administration.
So what have we actually created and why have we created from an existing published application? "My Pre-Launcher has taken the configuration of your published application for things such as configured servers, users and advanced features such as color depth and encryption. Think of it as a model configuration with only the bare bones. This is important because, for the pre-launch work session, applications must use the same settings. This is why it is easier to base the pre-launch session on existing applications. Note that the actual .exe file it uses is now CtxPreLaunch.exe.
If you have a XenApp platform where any application can run on a server, you can get away with only one session of pre-launch leaving that to balance the charge pending the user to start to work. However, if you have specific applications on some servers, you can use another method to ensure that all applications will pull yours right away.
I work a lot with workers groups in XenApp because it is a flexible way to chop a farm rather than silo'ing servers manually. In my example, I have a farm with her three servers over two groups of workers. Two servers host common applications such as Office and Adobe Reader, but the third server is a physical server with a powerful GPU for 3D work. I have created two working groups to consider this, we called Production SE and SE called HDX3D.
Because I have two pre-launch applications, one for each group of workers, it means that when I connect to my office, I will get a pre-launch session began on the two groups of workers. For end users, this means that no matter if I start a regular application published on my SE Group Production worker or a HDX3D ALL my applications will begin immediately. And because I'm using load balancing on my farm, I should not worry about which server the pre-launch session begins, only that it will launch something in groups of workers. It works exactly.
There you go. No waiting for the end users.
Ok that was a lot to read through, but I really hope to be made a little clearer or pushed you to use in the future, because it is something that end users will really notice.
I'm looking for some good honest feedback in this way please put yours below. If I'm off the mark with how you do it, lets get some ideas out there on how to improve it.
Cheers all,
David
@davidjgaunt
0 Komentar