The App-v Client software resides on a computer that also runs Terminal Server software.

This Guide does not concern itself with Terminal Server software, or with computers that are the Microsoft RDP or Citrix ICA Clients to which a Terminal Server displays App-v -enabled applications.

To make a Windows-compatible application (or a suite of Windows compatible applications) present itself to a User in familiar fashion, the App-v Client must have access to three files:

SFT file (that is, a SofGrid file; understood to take the form "*.sft" in the Windows file system, where "*" is a unique name you assign to a file with a ".sft" extension);

OSD file (that is, an Open Software Description; understood to take the form "*.osd" in the Windows file system, where "*" is a unique name you assign to a file with a ".osd" extension); and

ICO file (that is, an icon file; understood to take the form "*.ico" in the Windows file system, where "*" is a unique name you assign to a file with a ".ico" extension).

SFT files are stored on Virtual Application Servers and OSD and ICO files are distributed to App-v Clients (by way of various kinds of servers) before the applications they enable for App-v can be made available to Users

A fourth file, typically stored on an HTTP or UDDI server, may also be used if you configure the App-v Client to query automatically at login or manually after login for new applications and file type associations

Most of the App-v Client’ s activity deals with the preparation of an application for launch on the Terminal Server/ App-v Client computer, with its launching and presentation to the User, and, if essential parts of the application are not already in the Client’ s cache, with the streaming of those parts from a Virtual Application Server to the Client.

An HTTP, UDDI, or App-v Virtual Application Server can provide a App-v Client with information that describes where OSD and ICO files of applications can be found, and, in the case of HTTP and Virtual Application Servers, what file types these applications can open

This information is either generated automatically when you set up on a Virtual Application Server or a UDDI server the associations that exist between file types and the applications that can open them, or is created by you when you write desktop configuration information to an XML file on an HTTP server

Most of the App-v Client’ s activity deals with the preparation of an application for launch on the Terminal Server/ App-v Client computer, with its launching and presentation to the User, and, if essential parts of the application are not already in the Client’ s cache, with the streaming of those parts from a Virtual Application Server to the Client.

When a User attempts to launch a App-v-enabled application from an RDP or ICA client (by double-clicking on its shortcut or on a file that is associated with the application on the Terminal Server), the App-v Client retrieves the OSD file pertaining to that application. The App-v Client then opens the OSD file and verifies that the application can be launched on the Terminal Server/ App-v Client computer by checking requirements like the operating system and free disk space.

The App-v Client then creates an empty virtual environment for the application. This virtual environment will eventually be populated with registry settings, files, COM objects, and other virtualized components

If the application's OSD file specifies that the application should be run as part of a suite and another application from the same suite is already running, the App-v Client will simply insert a new instance of the requested application into the existing virtual environment without uploading that application’ s virtual environment (a step described below).

If the application's OSD file requires multiple instances of the same application to be combined and the User is already running another instance of this application, the App-v Client will not attempt to create another virtual environment. Instead, the App-v Client simply launches a new instance of the same application in the virtual environment for the existing instance of the application.

After the virtual environment has been created, the App-v Client will run any commands that have been scripted into the OSD file, or into a file pointed to by the OSD file, and identified in the OSD file with "EVENT=STREAM TIMING=PRE" attributes. A pre-stream script can be used, for example, to establish a VPN connection to a Virtual Application Server that will stream the application

Having completed these preliminaries, the App-v Client then establishes a connection to the Virtual Application Server that has been identified in the application’ s OSD file as the source of the application. This Server authenticates and authorizes the User requesting the application, then grants a license, if the application is subject to licensing, then gets a map of the application’ s native directories and files.

If the application is being requested for the first time, the Virtual Application Server then streams to the App-v Client those blocks, referred to collectively as the "launch size", that were sequenced to bring about the application’ s launch. Subsequent requests for this application will be hastened because the application’s launch size will have been cached locally.

You may want to know... You can store an application’s entirety in local cache to reduce delay even further.

After the launch size has streamed, or been found in cache, the App-v Client will run any commands that have been scripted into the OSD file, or into a file pointed to by the OSD file, and identified in the OSD file with "EVENT=STREAM TIMING=POST" attributes.

A post-stream script can be used, for example, to create an essential directory outside the virtual environment

Next, the App-v Client will extract virtual registry information, virtual file system information, virtual INI file information, and virtual COM file information, as well as other information, from the SFT file, and upload this information to the earlier created virtual environment. With the virtual environment created and populated, the application will now be able to run and will do so without endangering the stability of the Client’s operating system or other running applications.

After the data have been uploaded to the virtual environment, the App-v Client will run any commands that have been scripted into the OSD file, or into a file pointed to by the OSD file, and identified in the OSD file with "EVENT=LAUNCH TIMING=PRE" attributes. A pre-launch script can be used, for example, to mount a network share outside the virtual environment, or to alter a User’s personal settings inside the virtual environment.

Having populated the virtual environment, if not also run a pre-launch script, the App-v Client will start the application’s main executable file. Soon after the main executable file starts, the Terminal Server will present the application’s graphical user interface to the User at an RDP or ICA client

After the application’ s GUI has been presented to the User, the App-v Client will run any commands that have been scripted into the OSD file, or into a file pointed to by the OSD file, and identified in the OSD file with "EVENT=LAUNCH TIMING=POST" attributes. A post-launch script can be used, for example, to remove temporary files that the application created during launch. This entire process takes place rapidly and imperceptibly. Once done, the User is free to put the application to work

Having completed work with the application, the User closes the application in the manner required by the application.

Post-shutdown scripting

When the App-v Client detects the shutdown of a App-v-enabled application, it will run any  commands that have been scripted into the OSD file, or into a file pointed to by the OSD file, and identified in the OSD file with "EVENT=SHUTDOWN TIMING=POST" attributes. A post-shutdown script can be used, for example, to remove unwanted files or directories created during the User’ s interaction with the application, or to remove a history of the application’ s most recently used files.

Whether or not the App-v Client runs a post-shutdown script, it will save changes made to the virtual environment, whether these changes have been introduced by a group policy you have issued as part of your wider network’s administration, or have been introduced by the application’s OSD file, or have been introduced by a User’s actions that affect personal settings (such as a preferred template or window size). By default, these changes are saved in the User’s profile, but can be saved elsewhere

After the virtual environment’ s modifications have been saved, the App-v Client notifies the Virtual Application Server that the application has been closed and that the license to use it, if indeed a license has been granted, is no longer needed. The App-v Client then disconnects from the Virtual Application Server.

The only evidence that a App-v-enabled application once ran (or was at least configured to run) on a Terminal Server/ App-v Client computer will be a shortcut to the application on the Windows Desktop and/ or the Window Start menu, as well as various unreadable App-v files that stand ready to speed the application’ s next launch.

The Terminal Server/ App-v Client computer’s registry will store no settings for the application (such settings are kept in the Client’s cache). The Client’s file system will reveal no files of the application (such file are kept in the Client’s cache), except perhaps, those files created in the application by the User and saved to the Terminal Server/ App-v Client computer’s hard disk.