www.citrix.com
Application Streaming
To
1 INTRODUCTION... 3
1.1App-V comes in two versions ... 5
2 HOW THE CONDUIT WORKS ... 6
2.1Pre-Launch Script... 6
2.2 Post-Exit Script... 7
2.3Publishing the conduit ... 7
2.4Command line parameter for App-V App specification ... 8
2.5What happens at runtime ... 9
2.6Why must the work be done by the post-exit batch file... 10
2.7Constructing the Conduit App Streaming profile... 10
1 Introduction
The AppStreamingToAppVConduit utility engages “dual mode” XenApp based execution for Microsoft App-V sequences.
The XenApp publishing system can publish Citrix Application Streaming based applications for both server side execution and client side execution. Application Streaming has always included the ability to run “dual mode”, or “fallback”, where the system attempts to run the application by streaming on the client, but if that cannot be accomplished, the execution can be configured to fallback to a server provided delivery, where the application can be locally installed on the XenApp server or streamed on-demand for server side execution.
Whether run on the client, or run on the server, the user gets the application. The criteria for triggering a fallback to server mode are varied; they include:
• Machine is not a Windows machine so cannot be running the streaming client. • Machine Operating System is not supported by the profile.
• Machine lacks a required local installation pre-requisite such as specific version of .NET or Java or a particular version of locally installed Internet Explorer.
• Administrator defined pre-launch script triggers fallback. This case is used by the conduit and is described in the sections that follow.
1.1 App-V comes in two versions
Microsoft Application Virtualization (App-V) comes in two configurations: 1.Microsoft Application Virtualization (App-V), the desktop version.
2.Microsoft Application Virtualization for Terminal Services (App-V for TS), the server version.
This document and the conduit that it describes are primarily concerned with using App-V to deliver applications to end-user personal computers. The delivery occurs using XenApp based publishing and engaging “dual mode” fallback to XenApp servers for App-V based stream to client applications.
2 How the conduit works
The conduit is an Application Streaming based profile whose sole purpose is to engage dual mode for App-V.
The streaming profile includes pre-launch and post-exit scripts; these scripts query the presence of the App-V agent, and based on found or not found, selectively trigger fallback to XenApp hosted, or when “found” run the App-V agent as a function of the App Streaming operation. XenApp publishing believes it has run a App Streaming based application, because, well it has. The App Streaming profile though exists as a conduit to the execution of the intended program, the App-V client.
To make it more complete, the conduit also supports command line parameters which are specified during XenApp publishing in the Access Management Console. The single Application Streaming profile can be published multiple times in the Access Management Console to publish different App-V based sequences, all from the same App Streaming profile and all the App-V stream to client will occur with fallback to server side delivery. Based on the administrators publishing the server side execution can be to a locally installed application, App Streaming based application or App-V for TS based application.
2.1 Pre-Launch Script
The Application Streaming profile which is the “conduit” has a pretty simple mission: • If the App-V agent is present, launch it to run the sequence
• If the App-V agent is not present, trigger fallback to XenApp server delivery Application Streaming supports Pre-Launch scripts which run before the first application of a profile executes and post-exit scripts which run after all of the isolated programs terminate. Scripts can be inside isolation or outside of isolation and there can be an unlimited number of scripts.
Scripts in Application Streaming are BINARY; they are assumed to be programs and .BAT files are treated exactly the same as .EXEs. The script in its entirety is copied into the App Streaming profile.
To implement the App-V conduit, two scripts are used. The prelaunch script queries the presence of the App-V client. If it is present, the script returns success and the App Streaming program launch proceeds. If the App-V client is missing, the script returns “failure” and the streaming client sees the failure return code and triggers “Fallback to hosted”.
Here is an abbreviated version of the Pre-Launch script: @echo off
if exist "%PROGRAMFILES%\Microsoft Application Virtualization Client\sfttray.exe" goto SoftGridPresent
echo No SoftGridPresent REM Trigger fallback exit 1 :SoftGridPresent echo SoftGridPresent exit 0 2.2 Post-Exit Script
The function of the post-exit script comes down to one line. The whole mission of the post exit script is to execute yet another script, which is created by the executable that the streaming system runs as the isolated application. This is the tricky part, but the trick is what enables one App.
Streaming based profile to support numerous App-V based applications published from a single App Streaming profile.
Here is an abbreviated version of the post-exit script that is used. @echo off
"%TEMP%\AppStreamingToAppVConduit.bat"
Notice that the post-exit script calls a BAT file which is not defined as a profile defined script. The called batch file is created at runtime by the executable described in the next sections. 2.3 Publishing the conduit
The mission of the conduit is to use a single app streaming profile to publish NUMEROUS App-V based applications. With this, we do not want to hard code the location of the App-V sequence nor the name of the application in that sequence which should be executed. We want this information to be provided as a function of XenApp publishing in the Access Management Console.
In this manner, a single Application Streaming conduit profile can be used to publish an unlimited number of App-V based applications.
In the Access Management Console, the administrator publishes a dual-mode streamed application.
This has execution “primarily” on the end user client machine with “fallback” to the XenApp hosted environment. The profile that is published is the conduit profile and the application to publish is the single application in the profile, the conduit executable. This conduit executable is written specifically for this use and is described in the sections that follow.
First, let’s see how dual-mode streamed application is defined in the Access Management Console.
Notice that the application is defined as “Streamed if possible, otherwise accessed from a server”.
The server application type is specified in the next steps of the Access Management Console publish application wizard. The server application type can be a server installed application as in traditional XenApp hosted publishing, or it may be the same or another streamed application. The conduit will not interfere with publishing on the server as the App-V agent will always “be present” on the server allowing the full set of application types to be published for the fallback case.
The server application type can also be the App-V agent installed on the server for an explicit call to launch the App-V for TS agent for XenApp server side execution.
The Access Management Console also allows the administrator to specify the ICON to use in publishing the application, even an icon that is not part of the App Streaming profile. This step is important for correct user view of the applications and requires that the administrator point the Access Management Console at a file with the correct icons at time of publishing. 2.4 Command line parameter for App-V App specification
The command line arguments specified in the Access Management Console field “Extra command line parameters” will arrive to the conduit executable as argument to the WinMain() function.
The program source for the conduit is a number of lines, one source file. This program source code and the source for all of the scripts are included in the Citrix Developer Network
The command line parameters specified in the Access Management Console arrive as a parameter to the “WinMain” function of the executed program.
int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow); 2.5 What happens at runtime
At runtime, the streaming system will be told to execute the program AppStreamingToAppVConduit.exe.
The prelaunch script will run first, which enables the trigger to fallback to server side delivery should the App-V client not be installed on the machine. Execution will also fallback to server side should the client machine not be Windows based (thin client or mac) or not have the App Streaming client installed. This is automatic and does not require programming in the profile scripts.
With the App-V client in place, execution will soon land in the conduit executable. It has one simple mission, hand the command line argument to the post-exit script.
In original thoughts, the post-exit script would use the command line argument to construct a call in the batch file call to trigger the App-V client. In practice, the parsing of strings to construct a full command line is easier in C++ code than it is in .BAT, so the entire post-exit logic is created from program code.
The post-exit script has a simple job, call the bat file that is created by the conduit. The important line of the conduit executable is:
wsprintf(szOut,
TEXT("start \"\" \"%s\\Microsoft Application
Virtualization Client\\sfttray.exe\" /launch \"%s\"\n"), szProgramFiles,
lpCmdLine); // Parm to this program is the .OSD file
fwprintf(Outfile, TEXT("\n%s\n"), szOut);
The created batch file is found by the post-exit script, who executes it. Since the post-exit script is configured to run “outside of isolation”, the App Streaming post-exit script can directly launch the App-V client with no issue of recursing isolation systems.
While the post-exit script is running, the streaming client will be waiting for it to terminate. The streaming system has no choice but to be patient for this to complete. Eventually, the launched program, sfttray.exe, will terminate as will all of the programs that it starts. When all of the App Streaming visible applications terminated, the post-exit script will be “complete” and the App Streaming system will declare the execution of the conduit “successful”.
Notice that this “success” per the conduit’s definition does not necessary mean that the App-V execution was successful, only that the launch was initiated.
2.6 Why must the work be done by the post-exit batch file
The conduit program itself is run as the streamed application. It is running INSIDE of isolation. We do not want to launch App-V as an App Streaming isolated application; instead, App-V must be run outside of isolation after we have used App-Streaming to potentially trigger fallback to XenApp hosted application delivery.
The post-exit script runs outside of isolation allowing App-V to be started without being run as an isolated application streaming application.
2.7 Constructing the Conduit App Streaming profile
The Application Streaming profile is created in the Streaming Profiler. The executable is added as new disk addition by copying the executable file onto the hard disk under the profiler. This is intercepted and the executable becomes part of the execution target. Profiling of the application “installer” is then complete.
The next step is to define the prelaunch and post-exit batch files. All scripts in App Streaming are “binary”, so the profiler copies the bat files into the profile from a source defined by the administrator.
Scripts should be defined at the Profile level. The screen capture below has the script at the Target level; this was correct until Streaming Client 5.2, but with this version, the correct location is at the Profile level. Profile level scripts are shared across all possible execution targets. In this case, there is only one, but if there were a need for two, putting the scripts at the profile level can save time in maintenance.
3 Conclusion
The AppStreamingToAppVConduit utility engages “dual mode” XenApp based execution for Microsoft Application Virtualization (App-V) sequenced applications.
The profile and conduit application are released in SOURCE form with the intent that