Understanding the App-V client and publishing interaction

Having a deep understanding about the client-server communication is vital for every administrator.

The publishing interaction among clients and servers occurs in the Full Infrastructure model (even though we can configure the IIS server with a publishing configuration; for more information, take a look into Chapter 3, Deploying Applications in Complex Environments), where the database stores the list of the applications available and generates an XML file that is delivered to the App-V client and then the applications are streamed down.

In this section, we are going to take a good look at each step involved in the client and server processes regarding publication and refresh, and when an application is launched.

Understanding the publishing refresh process

The publishing refresh process occurs, by default, when the user logs in or when the refresh is manually triggered using the App-V client or SFTMIME.

This process contains several steps to validate the applications available for each user. Let's take a look at this as soon as the publishing refresh is launched:

1. The client computer sends the user's Kerberos ticket, which contains all the Security Identifiers (SIDs) for the groups that this user belongs to, to the management server for authentication.

2. After a successful authentication, the client computer establishes a connection to the Management Server. The App-V client supports connections between the client and the server to commence using RTSP/RTSPS or a web-based provisioning service.

3. Next, the client will send a request for publishing information to the Management Server over RTSP or RTSPS, depending on the client configuration.

4. The Management Server will contact the data store and retrieve a list of the application records and build an XML file, named applist.xml, containing the applications that have been published for the requesting user.

   • Internally, the App-V management server works with an XML cache prior to sending a request to the database for the applications' information. Working with this XML cache is highly important for optimizing the workload in the App-V management server (consider the scenario with thousands of requests per hour; generating this XML every time could be very expensive).

   • If the XML cache is invalid (after a long period of time where the server did not receive any update) or if this is the first request, the process will continue normally.

5. The client computer will process the XML file from the Management Server that contains the location of the ICO and OSD files. These files will be copied to the client computer and populated into the OSD cache and icon cache directories.

6. The client computer creates the appropriate shortcuts and registers file type associations based on the publishing information from the server.

7. Finally, any offline reporting information will be sent to the management server to be placed in the data store for reporting.

Understanding the application launch/load process

When a user double-clicks a published icon, the launch/load process occurs. This is a complementary workflow with the publishing refresh process.

Prior to the launch/load process, the publishing refresh process needs to be completed in order for the client to receive the icon in the desktop or the start menu.

We are going to examine the steps involved in this process, considering only the Full Infrastructure model where the client continues interacting with the App-V management server:

1. A user first double-clicks the application icon, or tries to open a file with an FTA associated to a virtual application.

2. The App-V client sends the initiating user's ticket to the management server for authorization to launch the application. The client will also send the GUID of the application to verify that the most current version of the package is delivered. Licensing will be checked if enforced by the assigned provider policy.

3. After successful authorization and licensing, the client will verify the cache space required for primary and secondary feature blocks of the package that is present.

   • This applies when we are launching the application for the first time or any other situation when the streaming process needs to occur.

   • If the application is already hosted in the App-V client cache, the application can continue the process within the client's cache.

   Note

   The phases of authorization, verifying a package's latest version, and the licensing enforcement still occur even when the application is completely loaded into the cache.

4. After ensuring that disk space is available, the client will stream the primary feature block of the package (SFT file) from a server with the appropriate package. App-V supports streaming package files from the following locations:

   • Using SFTMIME ADD or CONFIGURE PACKAGE with the /OVERRIDEURL switch allows an administrator to change the Streaming Server on an individual package.

   • This OVERRIDEURL is used in SCCM integration to let the client be able to interact directly with the SCCM client instead of a server pre-configured by the App-V client.

5. When the primary feature block is streamed to the App-V client, the application's virtual environment will be built and the client will attempt to launch the application.

6. The secondary feature block will be streamed to the App-V client when a user requests information from it on a block-by-block basis, called an Out of Sequence Operation , unless autoload settings are enabled.

AutoLoad options

AutoLoad is a client runtime policy configuration parameter that enables the secondary feature block of a virtualized application to be streamed to the client automatically in the background.

We can modify this behavior by using the registry or Group Policy:

• Using registry, we can find the AutoLoad option in HKEY_LOCAL_MACHINE\SOFTWARE\[ \Wow6432Node\]Microsoft\SoftGrid\4.5\Configuration

• Using the App-V Group Policy ADM template inside Microsoft Application Virtualization Client | Communication, we can find two options to configure these parameters:

  • Set Background Loading Triggers = AutoLoadTriggers

  • Specify What to Load in Background = AutoLoadTarget

Value	Default	Description
AutoLoadTriggers	5 (OnLaunch and OnLogin)	This parameter will control the behavior when the FB2 will be streamed down by the client. (0) Never: No bits are set (value is 0), no auto loading will be performed, as there are no triggers set. (1) OnLaunch: Perform background loading when a user launches an application. (2) OnRefresh: Perform background loading anytime a publishing refresh process occurs. (4) OnLogin: Perform background loading for any application when a user logs in. Default: 0x5 (OnLaunch | OnLogin)
AutoLoadTarget	1 (Previously Used)	This parameter indicates what will be autoloaded when any given AutoLoadTriggers occurs. Bit mask values: (0) None: No autoloading, regardless of what triggers may be set. (1) PreviouslyUsed (default): If any AutoLoad trigger is enabled and loads only the packages where at least one app in the package has been previously used by a user (pre-cached). This targets 'important' apps, meaning apps that have been used before are likely to be more important to a user than apps that have never been launched. (2) All: If any AutoLoad trigger is enabled, all applications in the package (per package) or for all packages (set for the client) will be automatically loaded, regardless of whether they have ever been launched.

These settings can also be configured during the App-V client installation using the SFTMIME command:

• Using the MSI installation file:

  • For setting AutoLoadTriggers, we can use the AUTOLOADTRIGGERS=[0|1|2|4|5] parameter. The numbers used are the same as we reviewed previously.

  • For setting AutoLoadTarget, we can use the following parameters: AUTOLOADONLOGIN, AUTOLOADONLAUNCH, and AUTOLOADONREFRESH.

  Note

  Using the SFTMIME command will be reviewed in Chapter 4, Handling Scripting and App-V Command Lines.