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.

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

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 

"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.

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.

Application Streaming shares the publishing infrastructure with the rest of XenApp™ (the new name Presentation Server).  Whether the application is published as "Stream to Server", "Stream to Desktop"  or "Streamed for off-line usage",  the publishing infrastructure for Application Streaming is the same as for traditional server hosted applications.   It has been around for years, customers like it and it works. 

SoftGrid® (Microsoft Application Virtualization) can also be published for execution on a Citrix infrastructure.  The server side case is the most common, but SoftGrid can also be executed on a connected desktop system and published via Citrix.    One method of running SoftGrid streamed to desktop is by publishing the package as "content".

• Access Management Console: Publish application, application type as "content".   The ".SFT" file is the content. 
• User launches the Citrix published "app" and the SoftGrid client kicks in via File Type Association to run the sequence.
• There are some "gotchas" such as what if the SoftGrid client isn't available, but it works. 

Dual-mode is what makes things interesting.   Dual-mode streaming

A real value of the Citrix Application Streaming solution is dual-mode streaming.  Since the publishing system and execution system communicate, it is possible to attempt to stream, but automatically fallback to a server side execution if streaming is not possible.   If the client execution system includes the Streaming Client and if all the pre-launch requirements on that machine are met, the application will be streamed.  If client side launch requirements are not met, then the application will be delivered via ICA connection to XenApp.  The user get's their application delivered on the optimal execution platform. 

This capability is normally associated only with the Application Streaming feature of XenApp and is a good plus for administrators.  It is possible to implement dual-mode for SoftGrid as well and the remainder of this post describes how to do it.   The key is scripts. Scripts are your friends

Application Streaming scripts are powerful.   Scripts are not text - they are binary and are "anything" that can be run using the Win32 CreateProcess() API.   This includes BAT, CMD, VBS, EXE and perhaps even MSI, though I can't conclude a good use for that last one.    Scripts can be run BEFORE application execution or AFTER the application terminates and can be run inside or outside of isolation.  There can be numerous scripts per profile and scripts can even be stuff that is not directly executable such as data or DLLs.  The important item here is that scripts travel with the profile and can be run "outside isolation". 

To achieve dual-mode Citrix streaming with the SoftGrid agent, a few steps are needed.

1. A pre-launch script run outside of isolation to confirm the presence of the SoftGrid client
2. An application that does nothing should be used as the application to run.  A BAT file with "exit" in it would do the job though an improved version would be a Windows GUI .EXE which has no actual display and just terminates.   Being a GUI app, no command prompt window will come up and go away, so the flicker will be avoided.  For the remainder of this document, I will call this application "DoNothing.exe".
3. A post-exit script needs to be created that kicks off the SoftGrid client. 

The Streaming Client generally considers scripts to be a short lived operation.  The idea is that prelaunch scripts are quick, the application takes a long time to execute and then the post-exit clean up can occur, which is also quick.   To get dual-mode SoftGrid, we have to change that timeline so we spend almost no time on prelaunch ("1") and running the published application ("2")  and  then most of the time executing the post-exit script.   Conveniently, the streaming client is patient and places no time limits on how long a post-exit script can take to execute.   

The job of the pre-launch script is to verify the presence of the SoftGrid client.  If it's there, return code should be set to 0 and the Streaming Client will proceed to launch DoNothing.exe.   If the SoftGrid client is not present, the Pre-Launch script should return non-zero (aka one) and this will trigger a fallback for dual-mode streaming.  This assumes that the application was published for dual-mode in the Access Management Console. 

The last step is the post-exit script that actually triggers the execution of the SoftGrid agent to run the application.  This script would be added to the profile along with the pre-launch script and both would work to manage the SoftGrid based operation.  In a simple form, the post-exit script would be the .SFT file and file type association can take over to run the sequence.   

Making it elegant

A more elegant solution will pass the name of the sequence to run as a parameter during publishing in the Access Management Console.  This way, a single Application Streaming profile could be used to publish an unlimited number of softgrid sequences.  The name of the application shown to the user and the icon can be adjusted in the AMC and the parameter to specify the SoftGrid sequence to launch can be specified during publishing.  
When the parameter arrives at "DoNothing.exe", it must store the parameter away so it can be accessed during the post-exit script.   I haven't implemented this elegant version, but it should work. 

If sounds interesting please give it a go and post back your results, I'll watch this space to help cover the gotcha cases. 

Joe Nord

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

About once a month, I get asked: What are the GUIDs for?

Application Streaming uses GUIDs to identify execution targets of a profile.  These are most visible as the RadeCache sub-directory names that hold the execution image of an application. 

In this post, I'll remove some of the mystery and provide the rationale behind their use.

Background: 

GUID = Globally Unique IDentifier.  The more correct term is UUID = Universally Unique Identifer.  I'll stick with GUID. 

Application Streaming has a few components which are key for this discussion.

-          Streaming Profiler

-          Streaming Client

-          Application Hub (Fancy name for a file server)

The job of the Streaming Profiler is to create an application profile and store that profile on the file server where it can be seen by the clients for execution and where it can be referenced by the Access Management Console for publishing. 

Profile:               XML file that describes things that can be published.

Target:               CAB file that holds the content used to actually run an application.

The profile holds a list of application names and a set of icon data that go with the applications.  Notice that this is all the information that is needed by the Access Management Console when publishing applications. 

The target holds everything needed by the Streaming Client for purposes of actually running an application.  It holds the file system and registry data that was collected during the profiling process or more precisely, it holds the stuff that was intercepted when an installation program was run under the Streaming Profiler.

Notice that a single profile can support multiple execution targets.

Minimal number of icons

An Application Streaming design goal was that a single publishable application (name and icon), could support multiple execution images where the "correct" execution image could be runtime selected from a list that is carried along with the profile.

Consider creating a profile of the Mozilla Firefox browser and profiling the installer twice, once for 32-bit execution and a second time for 64-bit.  The following is a high level view of what is in the profile.

Profile: Firefox

• Application 1: Firefox
• Application 2: Firefox Safe Mode (right, we don't publish that one)
• Icons
• "Target 1": (The 32-bit target) and
• "Target 2": (The 64-bit target)

In theory, we could create a directory for the profile and then subdirectories for the execution images.  Example:

• Firefox\ 
• Firefox\Target 1
• Firefox\Target 2

It gets complicated when you consider that the association of Target 1 with the 32-bit systems and Target 2 with the 64 could actually change as the profile evolved.

Targets are associated with client execution machines on several factors, including:

• Boot drive letter
• Language of OS
• Operating System version

The target that is "correct" for Windows XP 32-bit English right now, may later be the correct target for Windows XP and Vista 32-bit English and German.   Then the following week, it may drop German and add Japanese or all languages and figure out that the Vista execution really needs to be in its own Target and have a 3^rd created.

Using numeric integer target names would work (1, 2, 3, 4), but this gets a bit strange when Targets are erased from a profile.  It also fails to satisify a second requirement of the isolation system.  By design SaveAs creates a new target that will never conflict with the target that was opened for editing.

A profile is "new" if it is created or if a file / SaveAs occurs.  The Targets in a profile that is saved retains their identifier and targets that are SavedAs, receive a new GUID.  This way, the caching system can use the GUID as the key to isolation and pretty much ignore the association of Targets to profiles.  Since GUIDs are defined to always be unique, using GUIDs eliminates the complication of supporting two different versions of the same named profile with the same named set of targets.

What the Streaming Client needed

1)     Target name must be unique and

2)     Target name must never change

GUIDs fit perfectly.

Evolution

Once the GUIDs were selected as the names of the execution targets, they also serve as the basis of the directory names of the system shared cache and the per-user execution spaces that back up the layers of isolation.  The GUIDs then also support unique identification of a specific Target associated with a specific profile. 

It is worth noting that we describe the GUIDs that identify a execution target.  Profiles also have a unique GUID and two profiles with the same name, but different GUIDs are ... different profiles.

This is why we did it.  Feel free to throw some rocks.

Joe Nord

Product Architect - Application Streaming

In the upcoming Delaware release of Presentation Server, the AIE feature will be removed.  AIE technology was introduced in Presentation Server 4.0 and has been replaced by the Application Streaming feature of Presentation Server 4.5.

Refresher on AIE: 

With AIE, you can run any locally installed application under isolation.  You can also "profile" an application installation using the command line tool aiesetup.exe.  Notice that all of this activity is server side and specifically, there is no client side aspect of AIE.   With Application Streaming by contrast, you must profile an application to run it and execution can be either on the server or on the client desktop system.   Application Streaming also allows streamed applications to be used when disconnected from the corporate network.

Most aspects of Application Streaming are a superset of AIE, but in deleting AIE, the ability to isolate a locally installed application on a Presentation Server will be "lost".   This post shows how to "get it back".  It also shows how to implement AIE function "client side".

Consider that AIE and Application Streaming share many components.  The disk filter driver that supports both is common code - common binary!  Other components have been replaced completely such as the COM virtualization and registry hooking mechanism.  I'll add that this is generally to an improved solution.  The technologies are similar enough that an AIE environment can be simulated via Application Streaming.

Customer example:

In a recent telephone conference call, I was presenting the Three-Ps of Application Streaming.  First, PROFILE using the Streaming Profiler, second PUBLISH using the Access Management Console and third PLAY using the Streaming Client.   The customer was interested in Stream to Desktop  to allow some highly graphic and CPU intensive applications to run on the desktop streamed - rather than be locally installed - allowing publishing and maintenance via Citrix and Application Streaming.  A 15 minute pitch - done.  Customer is thrilled.

It is here that I figure out why they are thrilled.  Client side CPU and Graphics are great, but the real winner is that the app can be managed centrally, updated everywhere with one update and, here's the kicker, published via the Citrix Web Interface!

Their users use the web interface as their portal to launch applications, period.  They do not use the Start Menu, they do not use desktop icons.  This makes locally installed applications a headache and Application Streaming solves that problem - for the applications that they move to streaming.  The rest of the locally installed applications are still a headache.

Customer comment:

"If only we could launch locally installed applications via Application Streaming"

My response: Yes, you can do that.

*Here's the tie back to AIE.*LIVE during the call, I created a small profile.  The example application was "notepad" run via Application Streaming.    Within a few minutes, AIE on the desktop was demonstrated via Application Streaming and the customer had centralized publishing. 

The steps for publishing local machine notepad.exe via Application Streaming for AIE execution:

a)      PROFILE - Create a profile via the Streaming Profiler

b)      Installer = "cmd" enter.

c)       Notepad c:\LaunchNotepad.bat.  Contents below.

a.       Start c:\windows\system32\notepad.exe

b.      Exit

d)      Back to the CMD prompt now, "Exit" (this completes the installer from the view of the Profiler)

e)      Profiler is now looking for what applications were "installed".  Nothing was added to the start menu, so you'll need to do this step manually. It's on the second screen that lists the applications that were discovered during install.  Add one, browse to Device\C (the virtual root), select LaunchNotepad.bat.  Give it a name:  LaunchNotepad (done). 

f)       Save the profile

g)      PUBLISH - Access Management Console

a.       Publish a new app. 

b.      Name it "Notepad".  Notice published name does not have to match App name during profiling.

c.       Streamed app, point the AMC at the profile saved during profiling

d.      App to launch is "LaunchNotepad".

h)      Include an icon.  There were no icons discovered during profiling, so you'll need to tell the AMC to go fetch one, conveniently from c:\windows\system32\notepad.exe on the AMC machine.

i)       Complete publishing the app

j)       PLAY - Run it on a client machine

a.       On the client system, refresh applications in PNAgent.

b.      Alternatively, web browse to the Web Interface site

c.       See "Notepad" as one of the applications that can be launched

d.      Launch it (DONE)

NOTICE that the local machine notepad.exe is running under application streaming.   The batch file was launched by the Streaming Client. The batch file itself had a short life, just issuing the start for the local notepad.exe.  Since the local notepad.exe was started by a process in isolation, notepad will also be in isolation.

Summary:

The above achieves AIE style execution of locally installed applications and this can be applied to both client side systems using PS 4.5 and the Streaming Client as well as server side execution on PS 4.5 and beyond.  Since AIE will "go away" in a next PS release, this technique can be used to keep AIE around.

Making it elegant:

A ShellExecute() non-graphical GUI launcher should be used.  Most of us have one of these hanging around from autorun CD-ROM kickers.  This prevents the flicker of a command prompt starting and quickly going away.

It would also be possible to build a single launcher profile that receives a parameter as the application to launch.  Then, the single profile could be published multiple times from the AMC - each time getting a command line parameter to tell it which local application to launch.

Pre-Launch scripts could be used as well to first identify that the local application is present. If it is not present or if something else would prevent successful execution, then return a non-zero return code from the pre-launch script and the Streaming Client will abort the launch and optionally trigger fallback to a ICA delivered equivalent application (dual mode streaming).

One last item to consider is that while the customer in this example was able to launch the application locally with centralized publishing, the end execution will be isolated and that may not be desired in all cases.  Look here for a future post on running desktop local applications via Application Streaming outside of isolation.