Gus Pinto has blogged recently about a utility developed by the internal IT organization at Citrix that was used to assist in minimizing the amount of time required to get people into their Citrix apps. You can see a "veedio" [ LOL @Gus ;) ] of this in action here. Gus also did a follow up interview with the creators of the utility here.
One thing to know up front about this utility is that it will be released to the web as an unsupported utility on CDN. It won't be an "official" Citrix product.
Now before I comment on this, let me first state that I have no inside knowledge of how this thing was developed, nor am I an expert at the inner workings of it. That being said, let me state some assumptions about how I *think* this thing is working and some potential shortcomings of it. I'm certainly encouraging any/all corrections/clarifications to these assumptions.
First an overview of my understanding of the utility:
1) Windows boots up and the user logs in.
2) There's a Start Menu startup folder shortcut that links to this utility written by the Citrix IT guys.
3) The executable starts up and initializes a connection to a Citrix server. If the user had existing disconnected apps on that server, the apps would immediately show. If the user didn't have any apps running, they would just see their desktop.
4) Upon launching their next Citrix application, it would immediately appear via the magic of session sharing.
Ok, so what's the catch?
1) First of all, since this is a utility that runs in the startup menu of the client system, you've got to have some way to get it there. If you're using PN/Web client you're a bit SOL since you'd need some type of ESD or script solution for pushing the shortcut in their start menu. If you're using PNA, you could use the Citrix infrastructure and PNAgent to place the shortcut into the Start Menu, but you'd still need to stage the utility onto the machine. That means there needs to be some type of out of band management mechanism of getting it there. For most people with internal corporate desktops, this would be pretty easy through their existing ESD and/or Group Policy. For external users, you probably don't want sessions auto-launching in the background for security reasons.
2) What this utility is actually doing is automatically invoking an ICA session on a Presentation Server oops I mean XenApp server. This has implications in a few different areas:
a) Licensing. Unless Citrix has developed a way of not actually counting these "auto-launch sessions" you'll need to have enough licensing to accomodate every single user that has this utility deployed. At the client site I'm at right now, they have about 1500 ccus of PS4.5e, but a pool of about 6k total users. So if this is really an issue, then they would need to buy 4500 more licenses.
b) Server capacity. Everyone knows that one of the biggest hits to a Terminal Server environment is session initialization. All of the logon script processing, printer mapping, and process initialization is brutal on the Citrix server front. I see two issues here. One is major blackhole effect when shifts change. If you've suddenly got two to three thousand simulatanous Citrix logins vs normally seeing 500 max, that's a pretty significant rise that you might not be ready for. Secondly, does your Citrix farm have the capacity to accomodate the number of users that have FastLaunch deployed? Going back to my example of having 6k total users with 1500 max ccus. If the farm can handle 1500 total users, but you've just thrown 6k sessions at it are you going to stress it beyond it's capabilities?
c) Reliance on the magic of session sharing. Session sharing is a beautiful thing. It's a technology that in it's most basic form instructs the Citrix server to simply spawn a new user process for XYZ application within the existing TS/Citrix session instead of launching a whole new session. Now, there a many reasons why session sharing might fail. But the first (and most obvious) reason is that the application being requested isn't installed and published on the server that your session is running on. There are still many Citrix environments that are highly silo'd. The reason why an organization is in a silo situation may vary from company to company, but the bottom line here is that if your in a silo'd architecture, this FastLaunch may offer you no benefit on launch wait time if the application requested has to be fulfilled from an alternate server silo. Now, if your infrastructure is built such that you're using application virtualization (a.k.a. Citrix Streaming, Microsoft Softgrid, VMware Thinstall), then you might be able to get by with about 80% of your apps being serviced by the same server that you've initialized your startup session on.
Overall I think the concept behind FastLaunch is a good one. I think it could get even better if Citrix was to start tracking user experience patterns to know that XYZ user typically launches these applications initially and therefore we should spin up a session on XYZ silo, etc. But considering that this is an internally developed utility and is being provided for free, you can't exactly complain.
To wrap up I want to say the following things:
1) I'm not an expert on this particular utilty so I'm certain that at least 1-99% of this blog entry is completely wrong. :)
2) The type of thinking behind this utility is EXACTLY what Citrix needs to keep doing. There are tons of people out there with similar ideas/concepts. Citrix needs to find the ones that are game changing (or disruptive technology as they like to call it) and jump on them.
3) Offering this stuff for free is cool and all, but come on....this kind of stuff deserves real consideration for corporate backing. If the licensing, server performance, and session sharing issues are problematic then you just haven't thought hard enough about alternatives to make it better.