Check out this video excerpt from Citrix Summit 08 of Citrix Delivery Center and its amazingly fast and easy provisioning of application workloads to virtual and physical servers. Presented by Pete Downing and Brad Peterson.

Learn hands down how to implement Citrix XenApp with NetScaler.

Here's a paper that can show you how.

Download

Citrix Fast Launch is an application/extension that expedites the launching of applications virtualized with Citrix XenApp.
We will be releasing it soon as a freeware on the CDN site.

Stay tuned for more!
Gus Pinto

*Check out the latest video with the creators of Citrix Fast Launch!

Find and meet up with other Citrix Technology Professionals like yourself who are interested in personal collaboration, creating a Citrix Community, or hosting a Citrix User Group.

MeetUp is a site dedicated to getting people to meet. How does it work? You have an interest, Citrix, find a local group, and meet up with people who share in your interest of Citrix. You can either start a meet up or you can find people who have started a meet up in your area or the world if you wish.

You can also go to http://citrix.meetup.com to Find Citrix Users and Citrix MeetUps near you...

Here is a map showing meet up possibilities for Citrix

Here is a list of areas to choose meet up possibilities from by City for Citrix

Here is a user in Bedford, MA, USA who is looking for a Citrix MeetUp

I would love for everyone to be able to attend Citrix Synergy, Citrix Geek Speak, and Citrix BarCamp, but I also know that this is not always possible for many reasons. If you are one who cannot attend, don't think that because you can't go that you can't be a part of it all. It is you and the many other great Citrix Technology Professionals who make this industry the greatest one to be a part of. You can now find other Citrix Technology Professionals wishing to MeetUp and start your own TechTalk, GeekSpeak, or BarCamp in which you and your peers can pick the topics and agenda, and who knows maybe we can grow the Citrix Community in many new directions we never thought possible.

Here is a list of links to some upcoming Citrix Community Events:

Citrix Synergy
Geek Speak at Citrix Synergy
BarCamp at Geek Speak

Here is a list of Citrix Community sites:

Citrix Community
Citrix Community Blogs
Citrix Community Forums
Citrix Developer Forums Citrix Support Forums
Frameworkx Community Blogs

Project Delaware is the code name for the next major release of Citrix XenApp™ (the new name for Presentation Server) and it will include some major improvements in application virtualization.You can pre-register for the upcoming Delaware early release program and try out all the new capabilities for yourself. The program will begin in late April, so don't miss out. You will receive an email as soon as the code is available for download from MyCitrix. Please note that in order to participate, you will need to have access to Windows Server 2008 RTM code from Microsoft.

I'd love to hear what you think about the new Delaware features after you try to them out.

Supporting administrators using Application Streaming, one of the items that comes up from time to time is RadeRunSwitches.  They can be a good tool for running applications and even more important, for debugging the operation of a streamed application. 

This post describes the undocumented switches...

The Application Streaming client exists as part of Presentation Server 4.5 and later versions.  It works in conjunction with the PNAgent Win32 ICA Client as well as the Web Interface clients that run on the Windows platforms.  This is true both on user machine "client side" as well as server hosted, stream to server.

The icon placement and decision to launch an application happen in PNAgent and/or the Web Interface. These two components eventually toss the execution over the wall to the Streaming Client who does the actual work of running the Streamed application.  In the diagram below, the Streaming Client components are in green and the publishing components are in blue.

.

The executable that receives the launch request is RadeRun.exe.    RadeRun's mission is to carry out the launch request, via a single set of code that may be called from multiple sources.  Classic computer science stuff here; implement the launch logic once and you can be confident that if it works for one, it will work for the other and you get a single point of maintenance.    The "true" flow between the various components is a bit more involved than the above, but in principle, this is how it works.

Back to the beginning

In the earliest days of Application Streaming development, the PNAgent and Web Interface teams were not yet engaged.   All execution of applications started with RadeRun.   Early programming, testing and proof of concept were all done using RadeRun.exe as a command line utility to trigger the execution of streamed applications.  Some of this legacy remains even though PNAgent and the Web Interface are now quite capable of communicating with the streaming service without an intermediary. 

Isolation layers

In a minute, I will go through each of the switches to RadeRun - but first it helps to have an understanding of the isolation layers used in Application Streaming.

The application views the machine from above looking down.  The higher levels are like panes of glass laid on top of a business desk. The desk represents the true disk and true registry of the execution machine.  The application is above looking down and the layers of isolation glass "mask" the application's view of the true machine.    The layer of glass in the middle is read only at application execution, but was writable during profiling.  This layer represents the execution image for the application and is sometimes called the "InstallRoot" in documents describing Application Streaming.

The top layer is a per-user image and is writable at application runtime.  The application view of the true machine is masked from top to bottom, first by the per-user space and then by the installation image.   The application runs from above, looking down through the panes of isolation glass and since the middle layer represents what was written during profiling and since the top layer of glass starts clear, the initial application view of the machine is what existed at profiling.  The application believes it is installed - when it is not.  Each user gets their own top layer of glass and it is this layer that is writable at runtime.  This way, if an application writes to isolated spaces at runtime, that write is held in the per-user space.  Put it all together and applications not written for clean execution on a multi-user system can run without conflict.  More, the per-user pane of glass stays with the user's profile and can follow them from session to session.

The above applies to both disk and registry.  It also applies to COM objects and the systems named addressable items like PIPES and named semaphores.  

Lies, damn lies and statisticians:

The execution image (middle layer) is not really there.  Instead the isolation system lies and tells the application that the installation image is present on the machine and this reduces the amount of stuff that has to be brought down to the execution machine to run the application.  Many applications, particularly big ones, only reference a small portion of the stuff they install.  More classic computer science stuff says that if you can put off copying that data to the execution machine long enough, maybe you can avoid it permanently. 

Now - you'll notice a few important things.  Files that need to be there aren't and the isolation system has to do stuff to make them look like they are there and eventually, when actually needed, it has to make them really there, pausing and resuming the executing application while filling the missing content.  Worse, complicated things like Short File Names exist on the profiling machine and these names need to be maintained all the way to execution machine even if the TRUE short file name on the execution machine doesn't match the one that was used during profiling.  The application must see the SAME name no matter what and there is no reliable system API to make this happen.  The list goes on - bottom line is that there's lots of work to make these layers work and this means that there is lots of testing needed to prove that it works.

Proving it works

Once the execution cache becomes "full", very few runtime cache fills occur.  If you're in the business of testing the cache fill logic, this is no good.   Consider "stress" test in one of the Citrix labs.  The test is 100s of servers, 30 users on each server with all the users all running a variety of streamed applications.   The test then runs for about 24 hours and if anything ever fails, the test stops and your phone rings.  "They don't call it the stress lab for nothing!".

How can testers get the cache empty when the cache is being filled?

Answer: Backdoor logic to tell the streaming service to purge the cache before the application starts. Variations of this exist to control flushing all of the layers in the isolation system and to control "when" the flushing occurs.    This backdoor logic is controlled via command line arguments to RadeRun.exe.  There's one trick.  RadeRun.exe is not directly used for testers or users to launch applications. Instead, the applications launch via the web interface or PNAgent.   

Quandary:  If you don't "run" RadeRun directly, then how do you give it command line arguments? 

Answer: Registry key

HKLM\Software\Citrix\Rade\RadeRunSwitches (Reg_SZ)

RadeRun still accepts directly provided command line parameters, but it also checks a registry key for additional parameters.  With this, you can give command line arguments to the Streaming Client launcher even though you're not directly using RadeRun to trigger the execution of an application.

Evertything so far has discussed "why" RadeRunSwitches exist.  We can finally get to what they are. RadeRun.exe command line parameters

Specify using registry: HKLM\Software\Citrix\Rade\RadeRunSwitches (Reg_SZ)

c    clear execution cache before app opens

C   clear execution cache and per-user cache before app opens

d    clear execution cache after app closes

D    clear execution cache and per-user cache after app closes

e    Pre-fill everything into the execution cache

x    launch cmd.exe inside of isolation when launch the streamed application

Example contents: "-C -x"

*Are they documented or undocumented?

Now that I've written this, they are documented.  That said, in theory, with the exception of -x, they aren't needed much or more precisely - shouldn't be needed much.   The sections below will give more color to each of the switches;  what they do and where they should be used.

-c

Useful for the Citrix test groups to cause high-exercise for the isolation systems cache fill logic. Not really useful for customers as it results in all application launches being a first time launch, and first time launches are "slow" compared to a second time launch.  

-C

Same as the lowercase version, but clears BOTH the execution cache and the per-user cache.  People still tend to code this as -c -C when running the switches.  It actually makes more sense to me that -c should control the execution cache and -C control the per-user cache, but that isn't how it is.

-d

Useful for the Citrix test groups to cause high-exercise for the isolation systems cache fill logic.  In some cases, this one is useful for customers. If you have "secret" stuff that is part of your execution image and you want it "gone" after the application terminates, then -d can be an answer.  I'll add that the execution cache is DACL protected and users who are not running the application "right now" can't see it.  That said, some folks have good reason to be paranoid and this switch tells the streaming client to purge the cache when application terminates.  Notice that -d, like -c will cause the next launch to be "a first time launch" every time, and first time launches are "slow" compared to a second time launch.  

I normally recommend avoiding -c and -d and instead using a post-exit script to delete the just the smallest amount of secret stuff.  This way, the application launches are not first time penalized and the secret stuff is gone after execution.   The post exit script deletes the secret stuff and the next launch brings it back with a runtime cache fill.  Presumably, the secret stuff is small compared to the whole app.

-C

Same as the lowercase version, but clears BOTH the execution cache and the per-user cache.

-e

No longer needed.   In my first rounds of "documenting" RadeRunSwitches, I didn't even put this one on the list.  -e was created during development to allow the isolation system to run applications even before the cache fill logic was coded.   Today, it is sometimes used to diagnose a suspected cache fill error - or more precisely, a suspected "escape" from isolation.  If an application "works" with -e and doesn't work without it, then it implies that something isn't being isolated right and needs to be diagnosed. I do not recommend the use of -e in production systems but it can be useful in debugging applications.

UPDATE (04-Apr-08): I have been told of a worthy use of -e.   If an application is run with -e enabled as a part of a maintenance activity, then the entire cache can be filled; and then -e turned off.  This as a means of ensuring fastest possible launch time for users even if no user has ever logged on that client machine or server.  Application Streaming still does all the central publishing and applicaiton isolation stuff, but the streaming part not really used.  Interestly in this scenario, RadeRun.exe can be used directly.  Its fun to see how stuff gets used.

-x

This is my absolute favorite of the bunch and the real reason for documenting the switches. 

Notice that -x has nothing to do with cache management.   When profiling and testing profiled applications, it is often useful to have a command prompt or other utility running next to the streamed application and "seeing what the app sees".   Adding CMD.exe to the application profile and then publishing it is one way to get this accomplished.  This was common during the early days of Application Streaming development - until the developers got tired of repeatedly publishing a command prompt with every created profile.   Adding a switch to the RadeRunSwitches allows very quick addition of an in-sandbox command prompt for any streamed application.  This simplifies diagnosis of failing systems because you don't have to ask the person that created the profile to go back and change it to add debugging information.  Regedit to add the switch, launch the application and "poof!" a command prompt inside the same isolation environment as the launched application.

TIP: If you're debugging more than one application at a time, it is useful to use the "title" command to label your command prompts.

If you run regedit, from the command prompt, then regedit will see the view of the system that the isolated application sees, handy.  Do know though that you need to not have regedit already running for this to work because a second instance of regedit kicks the execution over to the first and then terminates.

Killing sandboxes: If you're running applications and particularly if you're writing scripts for your profile, you need to know that the sandbox does not terminate until all of the isolated applications in that sandbox terminate.  The started command prompt is "part of the sandbox" so it too must close for the sandbox to end. 

Wrap up

I hope this information is useful.  If you have comments or ideas for other switches, post here or let me know.

Joe  Nord
Product Architect Application Streaming, Citrix Systems, Fort Lauderdale, FL

It's been a month and a half since I suggested here using the respective Citrix and Microsoft application virtualization together on client devices and I curious what's on people's minds. I know, the idea sounds counter-intuitive, but my colleague Joe Nord explains how exactly it works in his post on the subject, so the mechanics are clear

People are picking up on it, including Ruben Spruijt who pointed it on in an article on BrianMadden.com. So did Chad Jones, the Product Manager for Microsoft Application Virtualization in a post on TechNet. In the last week alone, I've fielded questions from a couple of customers on the subject and the first question both times was why?

There are limitations for both solutions. MAV can't handle 64-bit environments and as I noted in my post on which applications not to virtualize, Application Streaming can't isolate all services. Both of these customers had these requirements so it makes perfect sense to leverage both solutions, especially if they can work together.

So why not try it? I'd love for somebody to prove me wrong.

In my last post, I talked about our plans of moving XenApp farm settings, server settings and session policies into Group Policy Objects. This time, I want to describe our plans on a related topic: how to migrate XenApp 4.x farms into this new management model.
XenApp 4.5 Administrators have two options to migrate their farms: either upgrade the existing farm over time, running the farm in mixed-mode; or create a new farm and move users and applications over time. 
The mixed-farm approach seems to be the easier of the two, but it has an important drawback: the migration cannot be staged. The recommended first step is to upgrade the Zone Data Collectors, which in turn affects all users and applications in the farm. If anything wrong happens - which is usually detected once users start to login and use their applications - there is no way to rollback without creating a farm outage.
The new farm approach is safer, as it allows Administrators to perform an "in-production" validation, migrating users and applications to the new version over time. The old production farm is not touched, which allows quick rollback of users to the previous farm if anything wrong is detected.

However, creating a new farm from scratch is not realistic in many environments. The reasons:

• Farm configuration documents may not exist, or be out-dated.
• Not sufficient hardware to maintain both farms in parallel. Servers have to move from one farm to other over time.
• The migration is not transparent to end-users. If a single Web Interface is used, it will list applications as "Application (Old Farm)" and "Application (New Farm)". If a separated WI is used, then users must configure browser and PNA to use another URL.

We do not plan to support mixed-farm migrations when we move XenApp configuration to Group Policy. Instead, we will focus on the issues above, creating the necessary tools to facilitate the transfer of configurations, users and servers from farm to farm.
This is the plan:
The first step is to create a new farm, installing a new Data Collector and creating a new IMA database. Infrastructure servers (License, Database, Edgesight, etc) may be shared between the old and new farm. The next step is to launch the Migration Wizard and go through the following steps:

• The migration tool wizard will ask information about the old farm (address, authentication). You may chose to export all the old farm data into an XML file and modify it before importing the data in the next steps.
• The wizard will ask the new farm information. It will then convert session policies, farm and server settings into Group Policies, and automatically associate GPOs with the new farm Organizational Units.
• If the old farm contained multiple application silos, the wizard will ask for a server that represents the old farm silo, and create a Group Policy Object containing that server configuration. The wizard will then associate that GPO with the OU representing the Application Silo in the new farm configuration.
• You will be able to select a list of "in-production" test users. The new farm will only enumerate applications to users in that filter list, regardless of the Application object configuration.
• Add the new farm in your Web Interface sites. Web Interface will suppress enumeration of applications coming from multiple farms, based on configuration. This change will make the migration process completely transparent to end users.

At this point, you will have a fully configured, although empty new farm. Over time, you will:

• Add more users to the new farm filter
• Remove servers from the old farm
• Upgrade XenApp software in the server (or re-image)
• Assign the server to the new farm Organizational Unit.

This method is very flexible, you may stage the process based on application silos, zones, users, or any combination of these. The migration tools provided here are also very useful for other use-cases, such as replication of settings between test and production environments.

This plan is still on the drawing board, please feel free to comment and raise scenarios where you believe it wouldn't meet your needs. Note that this is planned for the next major release after project Delaware, therefore still a long way in the future.

Application Streaming stores stuff isolation layers.   The main one that holds the executable content is stored in the "RadeCache" directory below the Citrix Streaming Client installation directory.  The sub-directory name is a GUID that uniquely identifies the execution image.  There is a corresponding user layer that is sandwiched on top and the application at runtime views the machine through the 3 layers of isolation. 

Here's a picture of the layers.  
The majority of the applications installation image is in the middle layer.  This layer is "actually" stored below the RadeCache directory, below the installed to directory for the Streaming Client.

It can be big - Customers commonly want to "move it". 

Setting the location of this directory is easy; run the ClientCache.exe utility that is included with the streaming client; done.   It's even documented in KB article: http://support.citrix.com/article/CTX115137

The ClientCache utility does a few jobs

-          Sets a registry string to tell the Streaming Service where the Cache is located

-          Creates the directory

-          Adds a DACL to the directory to give the Streaming Service privilege to write stuff to the cache.

-          Note that the streaming client service actually runs on a dumbed down account and without this DACL, even though it's a service, it lacks privilege to write to anything important.

Deploy folder

Consider offline "streaming".  How do you "Stream" when disconnected from the company network?

Answer: Everything that would normally be on a central store to support the streamed execution of the app, is actually copied onto the execution machine.  At runtime, execution content is "streamed" from this local copy into the execution cache, as it is needed - just like the online case.

The directory, \Program Files\Citrix\Deploy holds all the profiles copied to the execution machine to support offline execution.  Neatly, the streaming client core doesn't distinguish between online and offline.  It just knows where the execution cache is located (Installation/Execution image) and runtime populates stuff into the cache.  The source for the runtime populate when offline is actually a CAB file local to the execution machine; a nit.  It keeps the architecture simple when the client doesn't have to worry about online vs. offline. 

Changing the location of the deploy folder

We already covered changing the location of the RadeCache, this is easy.  Use the ClientCache.exe utility, done.   

Imagine my surprise when someone asked me about setting the location of the Pre-Deploy folder; there's no ClientDeploy.exe utility!  Hum.

Can it be done?  Sure.  There's no utility to do it for you, so it becomes a manual process - documented below.

Configuring the location of the directories

Key directories:

-          The RadeCache location defaults to \Program Files\Citrix\RadeCache.

-          The PreDeploy location defaults to \Program Files\Citrix\Deploy.

The Streaming Service (RadeSvc.exe) queries the location of each of these key directories by reading strings from the registry as part of its startup logic.   

Here are the registry keys that set the location of the RadeCache and PreDeploy folders.  These are both stored below HKLM\Software\Citrix\Rade.

-          CacheLocation

-          PreDeploy

Changing the location of the Deploy folder can also be done, but it is a manual process.

How to change the location of the Deploy directory:

1)      Create a directory

2)      Fix the registry string to point to the new location

3)      Give the Streaming Service Full rights to the created directory

4)      Terminate all presently streamed applications

5)      Unload and Reload the streaming service

Example steps from a command prompt:

-          net stop radesvc

-          Mkdir C:\NewLocation

-          cacls c:\NewLocation /E /G Ctx_StreamingSvc:F

           Alternate to above is to MOVE the existing folder, and its contents.

-          reg add hklm\software\citrix\rade /v PreDeployDir /t REG_SZ /d C:\NewLocation

-          echo y| reg delete hkcu\Software\Citrix\Rade\Offline

-          net start radesvc

Finally, PNAgent  - Right Mouse Button, refresh applications - and the new location will be used for the Deploy folder.  Depending on how the administrator has published the application, it may be necessary to actually run an application before the "bring it to deploy folder" logic kicks off. 

The above will work with Streaming Client 1.0 (Presentation Server 4.5) and with Streaming Client 1.1 (Presentation Server 4.5 HRP1).   There will be some changes in this logic going forward and when we get there, I can update this post with the particulars.
Joe Nord

Product Architect - Application Streaming.  Citrix Systems, Fort Lauderdale, FL

We are in the process of planning the next version of the new Mac client for XenApp. This new client will be focused on creating a transparent integrated desktop experience for the Mac platform. The concept is much the same as "Citrix Applications" (formerly PNAgent). Our goal is create an environment where users can move seamlessly between their locally installed apps and those being delivered by XenApp. Or, at least as seamless as you can get when you are running Windows apps on a Mac

 

We are running a survey for the next two weeks to gather feedback on the enhancements that will make the XenApp Mac experience world class. If you are interested in taking part in the survey just click here.

Thanks

Al Grandville

Citrix Product Management

    OK. So I'm airing some rather grungy laundry here but, for good reasons I'm sure, our internal implementation of XenApp serves up some 80 + apps to every user.  It's a pretty tough list to manage but, believe it or not, I've heard horror stories that some folks out there are dealing with hundreds and sometimes thousands (yes thousands) of published apps. You can just imagine how painful it must be for users to sort through such a cumbersome list every time they want to launch an app. XenApp provides tools to publish apps to only the subset of users who need them. This, of course, implies that the folks who set up XenApp had the time, resource and the information available to make these decisions. It's difficult to know how many user actually struggle with this problem but it still seems like an obvious place to uplift the users experience. The question is how we go about it.

Option 1 - Fine Tune Citrix Applications

    Citrix Applications allows users to move shortcuts to their desktop, quick launch bar, Vista gadget, etc ... Users can take advantage of all the methods that the OS provides to allow for quick access to his/her most commonly launched applications. There are some areas that still call for refinement like  full support for the recently used apps list in the Start Menu (right now we only show the last app launched ).

Option 2 - Favorites

    We could provide a method that allows users to create a list of favorite  apps. Once the list exists it would act as a filter and the users would only see their list of favorites. We would provide an interface to configure the list and to show the entire list again if the user needs to access an infrequently used app.

Option 3 - Most Recently Used

    A Most Recently Used or MRU list would build as users launched applications. When a user accessed the list their MRU entries would be their primary view with an easy way to expand the entire list if the user needs to access an infrequently used app. The size of the MRU list would be restricted to a small set of apps but could be made configurable by the user and/or the administrator.

    Back in the days of Windows 9.X Microsoft had "Network Neighborhood" on everyone's desktop. It made sense for us to place an icon on the desktop and call it "Program Neighborhood". From there is wasn't much of a leap to get to "Program Neighborhood Agent" when we decided to create a less conspicuous way to integrate applications into the Windows Start Menu and Desktop. Of course, Microsoft has long ago done away with the "Neighborhood" concept leaving us with a very cool program that no longer had a clear and meaningful name.

    Late last year we embarked on a project called "Pineapple". So named as it was charged with identifying the "low hanging fruit" in the users experience. It probably shouldn't be all that surprising that XenApp with its 13 year legacy doesn't have too much that's easy to  change. There's more to the story but for now let's say that Pineapple settled on crafting a consistent user experience across our products. As a result "Program Neighborhood Agent" became "Citrix Applications". We were shooting for something simple and obvious and I think we nailed it. And, yes, in case anyone was wondering we are considering making it possible to change "Citrix Applications" to something that makes even more sense depending on the implementation.

    These days there is a lot of emphasis at Citrix around End User Experience. You may have heard about "App Receiver" which has been highlighted during the keynote at "App Delivery Expo" back in October of 2007 and at our "Partner Summit" this past January.  App Receiver is our vision for a new user experience that will bring together multiple Citrix technologies in a way that is intuitive and easy to use. Imagine client software that is downloaded, installed and configured with little user interaction. An intelligent system that delivers the right components to the user without revealing any of the complexity involved. We will be talking more and more about App Receiver in the coming months so keep watching this space. I bring up App Receiver now only to point out that it is not simply "Program Neighborhood Agent" rebranded. The new "Citrix Applications" is a part of the larger vision and will play a key role in success of App Receiver but it is only a part of a much bigger plan to provide an awesome experience to the folks who use Citrix products every day to get theirs jobs done.

                So how about a few screen shots of the new "Citrix Applications" .....

Al Grandville

Citrix Product Management 

 So I was thinking a demonstration of XenApp desktop integration might be in order. "Citrix Applications" formerly known as "Program Neighborhood Agent" allows you to deliver Citrix applications seamlessly to the Windows Start Menu, Desktop, Quick Launch bar, Sidebar and the Windows Notification Area (AKA The Systray). Virtually everywhere you can place a Windows shortcut you can place a Citrix delivered app shortcut. Check it out ...

These were created on my Vista desktop but this all works equally well in Windows XP with the exception of the Sidebar which isn't available. The important take away is that users can interact with Citrix delivered apps in the same way they do with local apps.

 Our Motto - "If we do this right users wont know we've done anything at all."

 Al-

Some customers want to store the RadeCache on USB sticks.    Is it possible?  The answer is: Yes, but it requires jumping through a few hoops.  The background on the problem and the steps to pull it off are described below.

Background 

With Application Streaming, the general idea is to runtime populate execution material onto the machine - and to execute that content from the runtime populated cache.  The cache is called "RadeCache" as that is the base directory where all execution content is stored.  There are actually two; a main one which is shared across all users on the machine and another that holds the per-user isolation layer.  For this discussion, we are most interested in the common one that holds the majority of the execution material.

How is the runtime cache populated?  The execution content is held centrally on a file share, or if you prefer the fancy word, the "Application Hub".  There is no Citrix code running on the file share.

Here's a picture that conveys the general architecture.   The highlighted pieces are specific to Application Streaming.  The rest of the components are the publishing infrastructure common with XenApp (new name for Presentation Server).

Challenge:

Some customers want to store the RadeCache on USB sticks.   

The primary reason I've heard for doing this is to use Citrix for application publishing and as the central point of application updates, but the customer is more interested in isolation than they are in streaming and, here's the kicker, the network link to the home office is a 1200 baud 1985 vintage modem and they don't want to move execution content across that link!  Publishing information is okay, just no gigabyte execution images.   More: They also do not want a file share (Application Hub) at each remote office.  Another possible reason is to have the execution content for an application follow a user as they - and their USB stick - move from machine to machine at the office.  Whatever the reason, folks want to do it, the rest of this post describes the "how".

How to store RadeCache on USB StickFirst thing to know is that most USB sticks pre-formatted when you buy them and are prepared for the FAT32 file system.   This makes them ready to use right out of the box and makes them compatible with the largest set of computer systems. 

The Application Streaming code will not isolate anything formatted FAT32.  It assumes this is user document space and leaves it alone.  If it doesn't isolate that space, it can't store the execution image there and from a "before" view, this means that you can't store the RadeCache on removable media - but that's not the complete story.  The steps below show how to format a USB stick for NTFS and how to tell the streaming system to use that stick for storage of the RadeCache.  Interestingly, even when formatted NTFS, the isolation system will still not isolate user documents stored to the stick as the media is removable and the isolation system leaves removable media alone.

Back on subject - what has to happen to store the RadeCache on a USB stick? 

Step 1:

Format the USB stick NTFS.  The steps to do it are documented rather nicely, here.

Step 2:

Tell the Streaming Client that the RadeCache location is on the USB stick.  Note: This must be done using the utility below and not with registry edits.  A DACL is applied to the directory that gives the Streaming Service user account permission to write to the directory.  Without the DACL, runtime cache populates will not occur and you'll get an error messages on failed cache fills.   The "why" is that the streaming service actually runs on a pretty dumbed-down user account as compared to local system.  It can only write to certain places, like the RadeCache.

Start / Run: C:\Program Files\Citrix\Streaming Client\ClientCache.exe

Browse to the USB stick. Tell it where to create the directory. The utility must CREATE the directory.

Step 3:

Reboot to have the change take effect. 

If you're impatient for reboots, terminate all running streamed applications and from a command prompt issue "net stop radesvc" and "net start radesvc".

That's it!

If you find this useful or can describe other use cases where this can be of value, I'd like to know of them.  Append here for all to share.

Joe Nord

Product Architect - Application Streaming Citrix Systems, Fort Lauderdale, FL 

I'm currently working on a new Web site project that aims to shed some light on Application Delivery Infrastructure (ADI) and provides best practices for using ADI technologies to deliver applications and desktops. In short, the site will have sections on:

• Introduction to ADI:  Content explaining the technologies, products, and approaches used to deliver applications to users.
• ADI Best Practices:  Content generated by Citrix and the ADI community about the best way to deliver applications for specific scenarios and use cases.
• Citrix Product Architecture:  Content describing how the products that make up the CitrixDeliveryCenter work from an architectural perspective.

First of all, let me explain that ADI is the category of technologies that most of you reading this blog will already be familiar with. They include Server Virtualization, Application Virtualization, WAN Optimization, End User Experience Monitoring, Application Acceleration, and Application Traffic Control. These technologies have one thing in common:  they can be used to deliver applications, both Windows and Web, and desktops to users in a multitude of access scenarios. The Web site I am working on will contain content that explains these different technologies that make up an ADI, as well as descriptions of Citrix product architectures that are part of the ADI.

Over the years, these technologies and their applications (I'm talking about how they are applied, not software apps J) have developed largely in isolation from each other. Vendors of these technologies, and their communities, have been applying them individually as solutions to virtually every type of use case scenario. In most cases, they have been very successful in addressing the scenarios encountered; however, they don't meet all of the requirements for all of the scenarios. Some scenarios in which all of the requirements are not met would be considered "edge cases," but others are pretty common.

Once organizations realize that the technologies can be combined into one infrastructure category, they can then apply the technologies in combinations that can address the requirements of every scenario. The challenge then becomes what technologies to use for what scenarios. I have read some good commentary on this subject (an article from Brian Madden, for example) that has roused some passionate discussions. Another function of this new site will be to provide a place for the community to discuss what technologies can or should be applied in what circumstances. To help this discussion along, the site will contain a number of best practices for using ADI as solutions to deliver applications in specific scenarios---scenarios that include the type of application, location of users, business need (such as business continuity), and other factors. The community will be welcome to add their own best practices based on their experiences.

I'll keep you posted on our progress with this effort. In the meantime, if you have any suggestions for additional features and information that you would like to see on this site, please let me know by posting your comments on this blog entry.

 
The XenApp User Experience breaks down into two camps:

1: The Transparent Integrated Desktop Experience -- In this model the users primary interface is either a Windows or Mac desktop. Some of their applications are locally installed and some are being delivered by XenApp. The best experience that Citrix could provide is one that completely obscures the apps mode of delivery. In short, users shouldn't be able to tell the difference between locally installed and Citrix delivered apps.

2: The Web Everywhere Experience- The Web based model is a story of consistency and ubiquity. Regardless of whether a user is connecting from their PC at work, at home or at a public kiosk the experience is always the same. Browse to a URL, enter your credentials and launch your apps.

Citrix covers these scenarios today with Program Neighborhood Agent and The XenApp Web Interface respectively. While it's difficult for us to measure the exact numbers the balance seems to lean toward the Web everywhere experience. The question is why ? There is a big focus on enhancing the transparent experience and a strong belief that If we get it right the Web UI will become virtually unnecessary.

So, Are we right ? What's stopping you from moving over to Program Neighborhood Agent and the Transparent Desktop Experience ?

It's been a long long time since my last post, and much has happened since then in the desktop virtualization space, both for Citrix and in the wider industry. At the time of my last posting (December 2006, no less!) we were seeing the first attempts to virtualize Windows-based desktops, using home-grown and relatively simple "brokers". Typically, they would use straight-forward one-to-one mappings between end users and their virtual desktop, perhaps based on the user's login identity and their virtual desktop's IP address.

Since then, we have made great strides to deliver more sophisticated solutions for desktop virtualization, and a first batch of products have been released from vendors such as VMware (VDM, courtesy of their acquisition of Propero), Quest (via ProvisionNetworks), Leostream, and others (there's a good overview available from it2.0). And of course we delivered Desktop Server 1.0 last year, and have now just made a beta version of XenDesktop 2.0 available for download.

A great deal has happened here beyond the obvious name change, and our vision for this product has undergone major shifts over the past year or so. I'd like to use this post to bring you up to speed on how XenDesktop differs from Desktop Server and also many of the other desktop virtualization products.

First and foremost, while Desktop Server 1.0 was a broker that mapped end users to virtual desktops, XenDesktop provides a much more comprehensive approach to delivering desktops. A broker by itself is all very well. It allows you to migrate desktops into the data center, with all the benefits this brings in terms of preventing data loss (remember all those news stories about stolen laptops and hard drives and optical discs getting lost in the post?), reducing downtime, and gaining visibility and manageability - provided you have appropriate tools and processes in place to manage the sprawl of what will typically be VMs that host your virtual desktops.

Of course a desktop virtualization strategy can also introduce new headaches. For instance, you need to think hard about what moving your end users' desktops into the data center means for the security of other assets in the data center - you'll probably want to consider a strategy that fences off virtual desktops from other services and data hosted in the data center. More than that, though, moving desktops into the data center by itself doesn't solve some of the big management problems - you still need to worry about image management, patches, anti-virus, and on top of that you have to keep an eye on the health of the desktop virtualization infrastructure, whether this be XenServer, VMware, blade PCs, or other desktop hosting technologies. Finally, all the images for your virtual desktops need to be stored somewhere, and with multi-GB disk images, this quickly adds up to a substantial storage cost.

XenDesktop includes technology that will help you to tackle these complications, and help you get a long way towards reaping the promised benefits of desktop virtualization (well, that's my sincere hope anyway). Here's how we envisage a successful desktop virtualization strategy to play out:

1. Lock down your end user's endpoint devices, or better yet, replace them by Desktop Appliances (the new term for thin clients that are specifically designed to take advantage of desktop virtualization). This minimizes the maintenance overhead and reduces the risk of end users misconfiguring or otherwise breaking their devices. We've designed XenDesktop's end-user UI so that this step becomes as painless as possible for end users: after switching on their device, end users enter their credentials and XenDesktop takes over, connecting them straight to their virtual desktop. Depending on your deployment, this uses a combination of Web Interface and Program Neighborhood Agent technology under the covers, but this is entirely transparent to end users.
2. Take advantage of the migration to centrally hosted desktops and consolidate and rationalize the OS images for your end users. Ideally, you should end up with a small number of "golden images" that contain only the base operating system, as well as perhaps a few universal applications that all your users need, e.g. a standard browser or email client. The idea here is to separate the base OS from applications and user data, and hence make it an entity that can be maintained and managed independently and separately, and hence more effectively. Citrix Provisioning Server (also known as PVS - you may be familiar with it under its previous label of "Ardence") provides the required technology here, and is conveniently included in XenDesktop.
3. PVS is used to create and store golden images, which are then shared among VMs, or even blade PCs. In other words, if you have 100 users all using the same base OS, you only need to store the image on disk once and PVS will stream it to the VMs hosting your virtual desktops, on demand. The VMs (or blade PCs) themselves can be entirely diskless, and this can add up to a tremendous saving in storage cost. What's more, PVS makes managing golden images is made a lot easier as well: if you need to patch your base OS with the latest service pack, you only do this to the golden image. Restarting the VMs suffices to apply the new image across the board. And if the service pack update goes wrong - no problem, it's trivial to switch back to the previous version of the image. PVS and XenDesktop will also automate the management of AD computer accounts, hence there's no need for sysprep or other tools, and adding a new virtual desktop is done in seconds: create a new diskless VM, add it to PVS' client list, and let PVS manage the new desktop's AD account.
4. So now you have a very manageable environment that you can use to deliver generic desktops based on golden OS images to your end users. But your end users will need applications to carry out their daily work (remember, don't include too many apps into the base OS image, because then you need to manipulate that image every time you need to change or update one of these apps). This is where application streaming or "client side virtualization" comes into play; I've briefly touched upon this in my previous post: using XenApp technology, you can deliver applications transparently to your end users, without having to touch or "pollute" the golden image. This allows you to get away with a small number of golden images, even if your users have differing needs with respect to the applications they access: just let XenApp (or alternative technologies) deliver applications to users based on demand.
5. Finally, users also need to store data and configuration or personalization settings. Again, these must be separated from the base OS and also the applications, in order to make the entire system manageable and effective. Right now, you'll have to use off-the-shelf solutions like Windows roaming profiles to store and manage data and settings separately, but naturally we recognize this as a gap and are working towards offering a solution that's integrated with XenDesktop in the not too distant future.

To recap, XenDesktop has evolved significantly from a broker into a fully fledged desktop virtualization solution that combines a broker, ICA's high-performance remoting protocol (courtesy of PortICA), virtualization infrastructure (and before you ask: yes, XenDesktop works well with a VMware and Microsoft virtualization infrastructure as well, although of course we'd prefer you to use the XenServer technology that's included in XenDesktop), image management and OS streaming, a set-up tool for wizard-driven provisioning of diskless VMs with OS streaming, and more. If you want to dig deeper, check out the official XenDesktop product site where you can also download the beta, and join the discussion forums for support.

For my next post I'm planning to go a bit more technical and describe one of the areas that has generated many questions for the beta: how XenDesktop works with AD.

"When are you going to publish the list of applications Citrix XenApp can virtualize with Application Streaming?"

It's a simple question, but the answer is not. There's just no way to test all of the applications that are out there, especially when you consider that some of the best candidates for virtualization are those troublesome homegrown apps that only exist in customers' environments.

The Application Streaming feature of Citrix XenApp (the new name for Presentation Server) is designed to support all Windows applications and most run just fine when virtualized on desktop machines. We'll do everything we can to make a Windows app run in isolation and there's a great article on the Citrix Knowledge Base with tips and tricks on troubleshooting problems, but there are exceptions.

It's a simple fact that certain kinds of applications cannot be isolated and therefore are not good candidates for client-side application virtualization. These applications contain components that cannot be successfully isolated, such as:

•         Device or kernel drivers: We are working on this, but as of today, isolation environments cannot isolate device or kernel drivers. For example, if the application installs and depends on a driver to function, it does not work in an isolation environment.

•         Windows services: Some applications install and rely on a Windows service to function correctly. These applications cannot be isolated. (We are also working on this. Stay tuned. To verify whether an application attempted to install a service, examine the Event Viewer's Application Log. Look for messages with source CtxSbxAppMsg)

•         Windows class names or window names: Isolation environments do not isolate Window class names or Window names. Applications that use Windows messages as an inter-process communication (IPC) mechanism will not work correctly with the Application Streaming feature.

•         COM+ applications: Support for COM+ is limited, but fortunately, this isn't a big hindrance to most applications. There's another Knowledge Base article on this. COM and OLE are fully supported.

Just because an application installs things in the above list does not necessarily mean that the application will not work to the customer's satisfaction.  One way to get around these limitations is to install the problematic component locally. The isolation environment in which the apps are virtualized can be tuned to allow communication between the application and local environment. This works with some license services that run in applications, for instance. When the service is installed locally, the application can be virtualized without a problem. Another workaround is to just turn the component off, if this can be done without impacting the application itself.

We can't guarantee that these will work for every application, but they will for many. Just be sure to test thoroughly to make sure that the application isn't adversely affected. And let me know what you find out. Some of the best feedback comes from people in the field under the gun to make something work.

Like most techie geeks, our developers like to play with the latest technology and explore what's possible.  Sometimes they even get the chance to do it as part of their job...

Folks who have seen Thomas Koetzing's peek at the upcoming version of the XenApp Web Interface component will be aware that we've made some fairly major changes to the look and feel.  Certainly this is the most significant design uplift since WI (originally known as NFuse) was first released in 1999.  As you can imagine we're really excited by this, and we hope you'll not only like the new sleek look, but find the usability improvements we've made genuinely useful.  It's been in the works for a good long time (getting on for 2 years).

However that isn't what I wanted to highlight just yet (I'm hoping to get the people who were deeply involved in doing the usability work and defining and refining the design to talk about it).  Instead I'd like to show you something else we prototyped late last year, as part of some work to explore new user interface concepts and technologies.  If you follow developments in the web development world at all, you will have heard about Silverlight, the new cross platform browser-base rich internet application framework Microsoft is creating.  Derek Thorslund linked to the blog announcement this week from the Microsoft team busy working on Silverlight 2.0.

From our perspective, this is pretty neat stuff.  Citrix is already a very heavy user of Microsoft technologies, and our UI and Visual design teams have been eagerly following what Microsoft has been doing in building a strong design/code separation into WPF and now Silverlight.  For them, the ability to easily and safely update our product UIs without disrupting the code (oh I don't know, because someone wanted to change the look and names of a few products let's say...) - THAT would be the holy grail for them.

But WPF and Silverlight also offer a great chance to start being more expressive and trying out fresh approaches to UI tasks.  As it happens, WI is the most commonly used interface for people to get access to Citrix delivered apps, so it is a natural one to focus on.  So we let a couple of developers loose with some simple instructions: learn about Silverlight and come up with something that looks cool.  Well, they didn't give us cool: they gave us bling - lots of bling!  Have a look...

If you like that, have a look at this short video clip to get a better sense for what else it can do.  (You'll need the Techsmith codec.)  By the way, something cool that you can't tell from just looking is that it's powered by a new set of web service interfaces we're prototyping, designed to allow custom UIs to be built by all sorts of people (including us).  Actually, they aren't totally new; the first generation shipped inside the Web Interface integration for Microsoft Office SharePoint Server - give that a try if you're using SharePoint, it works with the Windows SharePoint Services component of Windows Server 2003 as well.

Interestingly, our techie guys, along with a lot of other early adopter developers, gave Microsoft some pretty detailed feedback on what was good and what was missing from the early alpha.  With the 1.1 alpha lots of standard UI controls were missing, leaving fairly low-level drawing primitives as the main tool to use, which ironically forced us to be more creative and come up with something that looks really new.  However it's great to see Microsoft is addressing the many gaps in a very major way!  (See Scott Guthrie's post for a lot more detail on what is now going to be the 2.0 version.)

Now, is this really a good user interface?  I don't know - it was a learning exercise, and a nice way to test whether our service interfaces are good ones.  But will we really ever do a Silverlight front-end to XenApp though?  Now that's a very good question....

Would you like us to?

Cheers,
AndrewI

Since the acquisition of Softricity by Microsoft, Citrix and Microsoft have continued to enjoy a close strategic partnership. Citrix has created a billion dollar business building value on top of Microsoft platforms like Terminal Services and this symbiotic relationship remains strong. Citrix is committed to finding innovative ways to add value to the Microsoft Application Virtualization (the new name for SoftGrid) platform and is actively working with Microsoft on this important technology.

The first step in this cooperative effort is to understand how the two application virtualization technologies work together. There are several scenarios in which the application virtualization capabilities of both Citrix and Microsoft work together:
1.     Complementary in the XenApp Server farm - Prior to its acquisition by Microsoft, Softricity was a Citrix Partner. In fact, a significant number of customers still use SoftGrid in conjunction with their XenApp server farms for application delivery.  The acquisition and name change to Microsoft Application Virtualization, does not change how well the two solutions work together.
2.     Simultaneous coexistence on the same platform - Customers can use both XenApp and Microsoft Application Virtualization on the same machine at the same time. Both clients will co-exist in the same environment so that customers can use both solutions simultaneously.
3.     Publish MS App Virtualization sequences in XenApp - In addition, it is possible for Citrix XenApp and Microsoft Application Virtualization to work together. Microsoft Application Virtualization packages can be published in XenApp.
4.     Apply XenApp policies to Microsoft Application Virtualization packages - This interoperability can be taken a step further. Existing Microsoft Application Virtualization sequences can interoperate with the XenApp policy features like SmartAccess and the XenApp Profiler, further extending the overall manageability of the joint solution.

Joe Nord the Citrix Architect of Application Virtualization has written a definitive account of how to make options 3 & 4 work.  Read about it here.

The inter-operability of the two technologies makes it easier for customers to leverage their existing investments in both Citrix XenApp and Microsoft Application Virtualization. Customers who have already expended the effort to sequence applications for Microsoft Application Virtualization can use these same packages in a XenApp environment. This allows customers to take advantage of the management capabilities built-in to XenApp which seamlessly switches between Microsoft Application Virtualization on the local desktop and in Terminal Services via the granular access control policies of SmartAccess.

Supporting Microsoft Application Virtualization makes it easier for customers to fully leverage their XenApp environments and reinforces our commitment to working closely with Microsoft to help customers realize the value in application virtualization.