Microsoft's Application Virtualization technology is emerging as one of the main platforms in application virtualization. This is mainly because more and more organizations are thinking about application virtualization as a valid implementation and also because App-V represents probably the most attractive solution.
With App-V 4.6 Service Pack 1 came an important variety of improvements, and most of them focused on the experience of sequencing. This made it possible for sequencer engineers and practitioners to quickly improve their techniques and share most of them with the community.
But, as you already know, App-V does not depend only on the sequencing process to work properly. There are several components in the App-V servers and App-V clients that are interacting. There are also several models available to implement and complement application virtualization in our company. Prior to starting implementation, we should be aware of and understand these components and possibilities in order to take full advantage of the complete platform.
The App-V server components and sequenced application files represent, probably, the pieces you already know about. The App-V client components are way larger than most App-V admins think they are, and if they know about their existence, they have probably not been fully used to optimize the platform.
A good example is using the App-V Client Management Console properties, from where we can configure the basic operations in the client and also several other important tasks, for example, configure the App-V client cache, add the SFT directories for cached content, configure permissions in the App-V Client Management Console for non-administrators, and so on.
Also, as an important section of this chapter, we will go through the detailed steps involved in the main processes in App-V, that is, publishing refresh and launch/load.
As a quick review, in this chapter, we are going to take a deep dive into the following topics:
Latest improvements in App-V 4.6 SP1
Server components in App-V and the files present in sequenced applications
Take a detailed tour of the App-V client components:
App-V Client Management Console
Global Data and User Data directories
App-V client cache
App-V client registry options
Deployment methods available in App-V
Understand the App-V client and publishing interaction: Publishing refresh and launch/load processes
The Microsoft Application Virtualization 4.6 build appeared a while back, introducing several enhancements with new features and possibilities to use virtual applications more efficiently. Some of the new features included were supporting 64-bit environments, including the "shared cache" feature for VDI environments, tight integration with Microsoft Office 2010, and so on.
This time, with the Service Pack 1 release, the improvements focused on the sequencer side, providing several new possibilities for the sequencer engineers to make their job easier and with several embedded best practices. Let's take a look at these improvements:
A package accelerator, created by a sequencer engineer, contains all necessary files and customizations in a virtualized application. It makes it possible not only to share with the community, but also for a sequencer trainee to capture a complex application just by using this accelerator.
Best practices applied by default: There are several common best practices that all of the experienced sequencer engineers know about. But, this time, the App-V Sequencer applies some of them by default, making it a lot easier to set our environment efficiently.
Using the Q drive: When we launch the App-V Sequencer installation, we have the option embedded into the wizard to select the Q drive as a default for the virtual drive. And, if we don't have any Q drive available, the installer creates this virtual drive automatically.
It is recommended to use 4.6 SP1 Hotfix 4. More information is available at the following Microsoft KB: http://support.microsoft.com/kb/2586968.
Installing a dummy ODBC (Open Database Connectivity): This is one of the common best practices we mostly didn't have deployed in several environments. The App-V Sequencer creates one as soon as the installation completes.
Remember that having an ODBC prior to sequencing an application can avoid creating several registry settings that would be captured by the sequencer in the current package (if this application tries to create an ODBC entry).
Also, if the default ODBC entries are not present, then the virtual application will only see the Data Source Names (DSNs) installed by the application; none of the local DSNs, due to registry overrides by the App-V client, can be seen.
Verifications prior to sequencing an application: Just before the App-V Sequencer wizard starts capturing a new application, it verifies that the OS image is clean and has no other capture launched before, no disruptive services are running in the background, or no other application is running.
By double-clicking on each observation, we will also receive the recommendation to solve the warning.
When we are capturing an application, we will also receive several guides during the stage to maintain common best practices, for example, the App-V Sequencer, by default, selects the installation path in the Q drive.
Several improvements in the App-V Sequencer GUI to improve sequencing workflow: If you are just starting with App-V and trying to capture an application for the first time, the options available in this new App-V Sequencer will make the process much easier.
As soon as we start the Sequencer wizard, we'll be given the option to choose the type of application we would like to sequence: Standard, Add-on or plugin, or Middleware. Depending on what we select, the capturing workflow will be modified.
If we try to update/modify an existing captured application, then we will receive the options Apply an update, edit a package, or add a new application.
Quickly review important information regarding the sequencing process: Starting with SP1, the Sequencer includes several important notifications when we are in the capturing process. For example, a driver that was not captured, or shell extensions not supported, and of course, the files excluded from the package.
In this example, we receive the notification as soon as we complete the installation of the application, and we will receive a summary of all the notifications in the Completion section.
In this section, by double-clicking the information, we will get a detailed look for each message. With the Unsupported driver detected message, the App-V Sequencer will show us the driver and files detected that will not be included in the package.
For more information on sequencing an application with drivers, review Chapter 2, Sequencing in Complex Environments.
Include "Templates" in the Sequencing process: When we have some customized options that are commonly used for capturing applications (such as the server name in charge of deployment and the port used), we can apply them in a template and use it in all of our sequencing processes.
The options we can use in templates to customize and maintain in our environment are:
Package Deployment Settings
Advanced Monitoring Options
Relax application isolation when we are virtualizing it: This option appeared in earlier versions of App-V (by using the
LOCAL_INTERACTION_ALLOWEDtag in the OSD files) but was required to be applied manually in all OSD files that we would want to use. Now, we can enable and disable it by using the App-V Sequencer options, which will apply to all packages. The default option is disabled, of course.
The option is called Allow all named objects and COM objects to interact with the local system and should only be applied when necessary, as the application will no longer work completely inside its "bubble" and will receive interaction from the OS components.
In this section, we are going to take a good look at the App-V components and architecture in order to understand how we can achieve a proper design, implementation, and maintenance of the infrastructure.
We are going to divide these concepts and components into those belonging to the server and those for the client machines. We will also review the sequenced application components, including all the files used in a virtual application.
We are going to summarize all the server components including App-V, as well as some of the options available in the App-V Management Console that should be analyzed in order to get a correct implementation.
The management server represents the service from which the App-V Full Infrastructure model controls application permissions, licenses, and policies as well as the statistics data.
The management server needs an SQL data store (multiple management servers can access the same data store), where it retrieves information such as application assignments and licenses, records, and permissions within the App-V management environment. The authorization phase, which we administer from the App-V management server, is integrated with Active Directory groups.
If we are including the streaming process with the App-V management server, the default ports used by this server are RTSP 554 and RTSPS 322. The
content folder is the location where this server requests for the packages, but it does not necessarily have to be located in the management server.
Also, the management server gathers all the performance and metering information within the environment. This information is stored in the SQL data store, although it can be stored on a separate server.
The App-V management system is composed of the App-V Management Console and the App-V management service. This web service represents the communication channel between the MMC and the SQL data store, controlling any read/write requests to the database. It can be installed together with the management server or on a separate computer with IIS.
The MMC console can also be installed on a separate computer; the software requirements are MMC 3.0 with the .Net Framework 2.0 installed. Additionally, we need to configure a few settings in Active Directory. Take a look at the article Running the App-V Management Console from a remote Computer at http://blog.appvtraining.com/Blog/tabid/87/EntryId/2/Running-the-App-V-Management-Console-from-a-remote-Computer.aspx.
We will also review the steps of "Trusted Delegation" in Active Directory and Service Principal Names (SPN) in Chapter 6, Scaling Up App-V Implementations.
Here's a quick overview of the interaction of the App-V management server components:
This server will serve the role of streaming applications to the clients who do not have an acceptable connection to the management server, such as a branch office. Streaming applications is the only functionality enabled for this server, and it is represented, in most cases, as an optional role to be installed.
In this section, we are going to understand some options that could be useful when we are working with the App-V Management Server Console.
We will not cover the App-V management server operations and features, such as managing providers' policies, in this section. Those processes will be covered in other chapters of this book.
The App-V Management Console includes an option embedded to reset administrators for the App-V database. This option "in theory" would bring the administration back in control of the platform and change the location of the database, if required.
But "in theory" is the right term used, because, in the actual process, the UI does not work. This is a known error in the App-V Management Console. Microsoft states that this error will be fixed in a later release of the App-V management server.
For more information on how to solve this situation, check Chapter 5, Troubleshooting App-V.
Microsoft includes a process we can use to move the SQL database to another SQL server. Check the article How to Migrate the App-V SQL Database to a Different SQL Server at the following link: http://technet.microsoft.com/en-us/library/gg252515.aspx.
There are some situations where we might experience performance issues in the App-V management server when we have a lot of clients connecting to this server to retrieve applications; one of the possible reasons could be related to the memory and core processes resources allocated in the Management Console.
In the App-V Management Console, when we access the Server Groups | Properties of the selected server, then in the Advanced pane, we can check some of the resource options available.
The Max Memory Allocation (MB)
(defaults to 512) represents the memory used by the App-V management server dispatcher core processes (shown as
sghwsvr.exe in Task Manager). When we have several clients connected to the server and requesting applications constantly, we will see these processes repeated and consuming a lot of memory.
It is highly recommended to increase the Max Memory Allocation (MB) value when we have an App-V management server experiencing slow performance. For example, if we have an App-V management server with 8 GB of RAM, we should be considering using values such as 4096 to optimize the resources in the server.
Also, as a symptom, which could be related to the memory utilization, the App-V clients will show timeouts when they are trying to stream an application.
The Number of Core Processes
represents the quantity of dispatchers (
sghwsvr.exe processes) that will be used by the App-V management server to handle the clients' requests. 5 is the default value used.
If we have "crash dumps" (or also known as BSOD, blue screen of death ), then it is recommended that we use it to reduce the value in Number of Core Processes to 1. This will let us analyze only one core process in order to find the problem.
If we have a large App-V environment with several App-V management servers, we must configure these values, Max Memory Allocation and Number of Core Processes, consistently across all servers.
If we don't follow this consistency, some of the issues that might appear are periodic/intermittent loss of database connectivity, services failing to start, general performance issues, and so on. For more information, have a look at the article Pre-creation of Server objects may yield certain sub-optimal values in the App-V SQL Database at the Microsoft TechNet Blog: http://blogs.technet.com/b/appv/archive/2010/05/10/pre-creation-of-server-objects-may-yield-certain-sub-optimal-values-in-the-app-v-sql-database.aspx.
App-V applications do not act as normal applications and, of course, do not contain the normal files we can find in any given application. Once the App-V Sequencer captures the application, the following files are created:
SFT: The SFT file is the container for the original files used by the application. In the capturing process, the App-V Sequencer packs these files in a form that can be streamed by the App-V server, without altering any configuration or source code. The SFT file is composed of two sections: the feature block 1 (FB1), which represents the applications most used features (or in this case, most used files), and the feature block 2 (FB2), which represents the rest of the application.
The behavior on the clients of these two blocks is as follows: the FB1 is streamed the first time the App-V client launches the application, and the FB2 is streamed by the client only on demand.
DSFT: Also, there is a differential version for the SFT called the DSFT file. This file is the one that we create when we need an active upgrade of the published application. The DSFT contains the delta files between the original SFT. Using DSFT, we can reduce the bandwidth impact when we perform a significant change in an already-delivered application; the App-V server only streams the file that the client does not already have.
The DSFT feature appeared in App-V during the Release Candidate version of 4.5, which included an option in the UI of the App-V Sequencer to generate this type of file (Generate Difference File). Later, in the RTM version, this option in the UI was removed, but the option is still present, as seen when using an executable file included in the
Program Filesfolder of the App-V Sequencer.
We can find the executable to generate DSFT at the following path:
%PROGRAMFILES%\ Microsoft Application Virtualization Sequencer\mkdiffpkg.exe. For more information about using DSFT files, visit the article How to Use the Differential SFT File at Microsoft TechNet: http://technet.microsoft.com/en-us/library/dd351395.aspx.
The OSD file translates to the App-V client the location of the SFT file for the application, the name and place of the executable file in the virtual environment, supported operating systems, and so on.
SPRJ: The SPRJ is the XML-based project file. Once the application is sequenced, we can save the project for a future change in the application. It contains the list of files, registry keys, and directories that are being excluded by the sequencer, as well as the parse items.
The manifest file is always saved in the sequencing process and uses the same name as the SFT and the SPRJ file, adding the
_manifest.xmlat the end of the filename.
The use of this manifest file occurs on important phases in the App-V delivery deployment:
Loading and running a virtualized application using a script or command line with the
The MSI, which you can create to deploy applications to offline users, contains the manifest file.
The XML manifest is needed when you import App-V applications to System Center Configuration Manager 2007 R2.
ICO: The icon file is created on the sequencing process and represents the file that App-V is using to deliver clients the proper shortcut for the App-V package as well as the file type associations. The ICO file always uses the same file from the original application.
MSI: The MSI file is optional in most cases. The main role of this file is for offline users, in those scenarios where we need them to provide a file from which we deliver the application without the intervention of a streaming server.
MSI files contain a copy of the manifest, OSD, and ICO file.
Now that we've arrived at the App-V client, in this section, we will understand which of the components are interacting on the client side.
The App-V client is actually a simple component in the platform, basically working as a filter driver, redirecting and comprehending requests from the virtual environment to the operating system. The App-V client contains several options and components interacting to execute the processes efficiently:
An important remark regarding virtualized application architecture is that it provides App-V clients with several virtual environments, which isolates the applications and generates all the necessary virtual components for a proper functionality. As we've seen earlier, this is the main difference between normal applications and virtualized applications.
Virtual drive or virtual filesystem: It is where the applications are stored, namely, the Q drive. The virtual filesystem redirects the filesystem requests from the application, for example, where the application would normally be installed to the C drive.
The App-V Client Management Console is rarely used by a normal user, but it could be quite helpful if we want to locally manage some of the options regarding the App-V client.
Load/unload: This option loads/unloads the application into the client's cache.
Locked/unlocked: This locks/unlocks the selected application in the client's cache. Once it's locked, we cannot remove the application.
Clear: This option clears (not deletes) the current user's settings and publishing configurations for an application. None of the PKG files are deleted.
Repair: This option removes the user's settings applied to that application. Getting more specific, repairing an application deletes the
usrvol_sftfs_v1.pkgfrom the user profile.
The App-V Client Management Console can be accessed in the following
Program Files path (64-bit environment):
C:\Program Files (x86)\Microsoft Application Virtualization Client\SftCMC.msc.
So far, so good; handling these options did not present us with any advanced task in the client machines. But, the Management Console includes, in the Properties section, some important parameters we should consider. This is discussed in the next section.
The App-V Client Management Console does not support remote management; we can access only the local computer when we are using it.
This supportability changed in App-V 4.5 due to several security issues in this option.
As we have reviewed the App-V management server components, now let's take a look at the App-V client components' interaction. Within these components, we can find several services working together to make the virtual environment functional:
When we select Application Virtualization (Local) | Properties, we receive several new options available for the App-V client.
Let's take a look at some of the most important ones:
Configure the Logging level in the App-V client, for both type of logs the
sftlogand the System Log in the Event Viewer. More information about logging and errors are seen in Chapter 5, Troubleshooting App-V.
Select the path for the Global Data Directory, which is the directory where common data for the computer will be kept. We are going to analyze this directory a little bit further in this chapter.
Select the path for the User Data Directory, the location to keep the user-specific data for the virtual applications. We are going to analyze this directory a little bit further later in this chapter.
File System tab:
In this tab, we can configure the Client Cache, using the same options we used when we installed the App-V client (and also when we added the current reserved cache size to avoid any misconfiguration).
Also, we can switch the drive letter assigned to the virtual drive. This option must not be changed if we already have our applications sequenced in the Q drive.
This is an interesting set of options we can use for our power users in the organization. We can define the tasks that can be performed in the App-V Management Console to normal users such as Add applications or Publish shortcuts.
The complete set of these options is available to administrators, no matter the tasks we configure here.
In this tab, we can configure whether we want users to be able to execute applications when they can't establish the connection to the App-V Management or Streaming Server and just run it in the cache.
We can also configure the time from which we will let the clients be able to use the "disconnected" option.
Import Search Path tab:
This tab represents a great alternative in App-V scalability; we can add directories that will let the App-V client scan for applications' SFT files that can be cached. The paths included here will be added into the cache beside the files the client receives from the App-V management server or the Application Source Root configuration.
When we are using the Full Infrastructure model, it is not enough to make an application available in the client, as the authorization phase still occurs.
When we are using the standalone model, caching SFT files in any directory added here won't require authorization.
As we've reviewed earlier, the App-V client components are not only represented by the applications it receives from the server, this component includes several other elements used to handle App-V operations efficiently. With this are included the Global Data directory and User Data directory.
The Global Data directory is the container where the common computer data is stored and is available for all users in this operating system. The default location is
C:\ProgramData\Microsoft\Application Virtualization Client\.
shortcut_ex.dat: This file is present in both directories, that is, the Global Data and User Data directories. It contains the list of application shortcuts present. This list is updated for every publishing refresh.
The file in the Global Data directory is updated when adding a package using
SFTMIME ADD PACKAGEwith the
/Globalswitch or adding an MSI-based package.
AppFS Storagefolder: Within this folder is kept information and personalization made in applications which are not user specific. Not all applications require storing particular computer information.
The application-specific data in PKG files will be analyzed later in this chapter.
There is also an
Icon Cachefolder created in the User Data directory for the same purpose.
The User Data directory is the place where the applications store the user profiles associated with each application. Any particular configuration made by a user in an application is kept here.
The default location of the User Data directory is using the system variable
%APPDATA%\SoftGrid Client, translated to
The folder also includes, as mentioned before, the Icon Cache folder for storing particular user published icons and the shortcut_ex.dat with the list of these icons.
We've discussed, in the last two sections, the common data appearing in virtual applications and stored in PKG files. App-V separates these files into two separate directories, Global Data and User Data, representing each change made in the operating system and in the user profile environment of the application.
How does App-V know where to store these changes? In the sequencing phase, each file captured includes a parameter regarding whether it is User Data or Application Data. So any change made to any of these files is stored as PKG in Global Data or User Data directories.
We can review this parameter in the App-V Sequencer using the Files tab:
App-V already has an algorithm to decide whether the file belongs to Application Data or User Data and rarely will we need to change this value while editing a virtual application.
The PKG files created by each application are unique and can be differentiated in these directories, as it is using the package name plus the GUID associated with that package. Using a previous example, the Firefox directory is named FIREFOX6-C06AF524-837-44AC.
Within each package directory, we will also find several files, including two separate PKG files associated with User Data and Global Data. These files are present in the User Data and Global Data directories, respectively.
Here's an example of the Global Data directory of the Mozilla Firefox 6 package:
GlblVol_sftfs_v1_<SID>.pkgcontains application-specific files that are modified by any user process in the virtual environment. The SID of the user is appended to the volume name to uniquely identify it.
GlblVol_sftfs_v1_S-1-5-20.pkgcontains any application-specific data that is modified by a system process. The well-known SID for a system is appended to the volume. User modifications go instead to the application data isolation volume. The global package volume also contains the virtual environment configuration for system processes.
Regarding the User Data directory, we can find only one file:
These files interact in several different ways during the normal processes of virtual applications such as the initial launch, shutdown, upgrade, and so on.
Microsoft developed a complete document where we can evaluate this behavior closely and understand how these files are used during each task.
The following is an example, taken from Microsoft documentation, of processes such as initial launch, shutdown, and subsequent launch:
The process runs as follows:
When a user launches the virtual application, the TMP files are created in the Global Data directory to store any changes that occur while the application is launched, like we saw in the Firefox 6 package container.
When initiating a shutdown, the TMP files are merged with their respective locations, global and/or user, as PKG files. These files are stored for subsequent launches to preserve any changes that were made when the application was launched.
On subsequent launches, the PKG files are copied to TMP files for changes that are made while the application is launched.
We can find more information in the Microsoft document, App-V Application Publishing and Client Interaction, at: http://download.microsoft.com/download/f/7/8/f784a197-73be-48ff-83da-4102c05a6d44/APP-V/AppPubandClientInteraction.docx.
As we've already seen, the App-V client cache performs a critical role in all App-V implementations. One of the main reasons is that most of the virtual application's usage occurs using the App-V client cache.
The client cache file, named as
sftfs.fsd, contains the SFT files included in all the packages used by the App-V client.
By default the App-V client cache is stored at
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client.
1 TB is the maximum size permitted (it is 6 GB configured by default when we install the App-V client).
Fixed size and minimum free disk space are the two limitations we can use in the App-V client cache.
In the App-V client cache, the following components are included: all the files and folders information, Feature Block 1 (FB1) of applications launched (complete packages are also stored when we configure auto load triggers), and virtual registry of the applications.
When the App-V client cache is full and new applications need to be added, the oldest and unused files are removed from the cache in order to maintain the latest applications.
Applications "locked" into the cache are not considered for deletion.
When an application deleted from the App-V client cache is launched, the streaming process starts again.
Sharing the App-V client cache among several clients is possible. It is only supported in VDI scenarios plus Full Infrastructure and RDS hosts. This "shared cache" feature is used as a read-only file.
For more information about this, take a look at Chapter 7, Integrating App-V with Virtual Desktop Infrastructure (VDI).
Modifying the size of the cache is possible using the App-V Client Management Consoles Properties | File System tab.
If we want to reduce the size of the client cache using the App-V Client Management Console and the current size exceeds our new value, then this will not reduce the size of the file. To do so, we must edit a registry.
As we discussed in the App-V Client Management Console, we can modify the size of the client cache, but the limitation is presented when we want to reduce the size of the cache and the current size of the file surpasses the value.
To accomplish this, the following procedure can be executed:
In the App-V client, access
HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432\]Microsoft\SoftGrid\4.5\Client\AppFS, modify the "State" registry key to 0.
Reboot the operating system.
When the machine is rebooted, the FSD file is deleted and a new one is created. There's no need to change the registry value, as this is reconfigured by the App-V client.
The App-V client cache includes a complete set of registry settings we can modify manually, and several of them using Group Policy with the App-V ADM template. The registries can be found at the following path:
Microsoft already provides a complete review of each of the registry keys available; we can find App-V Client Registry Values at the link http://technet.microsoft.com/en-us/library/dd464849.aspx.
We are going to take a quick look at each of the sections included in the App-V client cache registries to understand the options available to configure:
Configuration registry: This section is probably the most used, manually or using Group Policy, as it represents the behavior of the App-V client regarding the virtual environment parameters. Some of the important options we can find here are:
The normal use of this value appears in, for example, branch offices. The clients here receive the application information from a management server in HQ, but by using registry or Group Policy, the location of the SFT file is overridden to use a local Streaming Server instead of accessing HQ resources.
AllowIndependentFileStreaming and RequireAuthorizationIfCached: These options are used when we need to configure the standalone model manually. For more information about the standalone model, review Chapter 3, Deploying Applications in Complex Environments.
This is an example of the Configuration setting with some default values:
There are also other sets of registry settings available when some of the non-default configurations are present in the App-V client such as CustomSettings or Reporting. For more information on them, please visit the link http://technet.microsoft.com/en-us/library/dd464849.aspx.
Microsoft Application Virtualization offers administrators and decision makers tons of possibilities to implement it when we have already decided that virtualizing applications is our approach.
App-V implementation models consider pretty much all the scenarios in small, mid, and large-size organizations, making it possible to offer all users App-V applications. Scenarios such as branch offices with slow bandwidth, offline and/or roaming users, or when we already have other platforms to provide applications (such as SCCM, Citrix XenApp, or Remote Desktop Services) are also included as valid deployment models.
The deployment model used basically depends on the current infrastructure in place, understanding the requirement, and of course analyzing the cost-benefit equation. The deployment possibilities in App-V are as follows:
Full Infrastructure model
Electronic software distribution (ESD) model
We are going to take a quick look at each deployment method available, but we are assuming that the basic concepts about App-V implementation are clear for the reader.
More information can be found in Microsoft's document App-V 4.6 Infrastructure Planning and Design Guide at http://go.microsoft.com/fwlink/?LinkId=160978.
In my previous book, Getting Started with Microsoft Application Virtualization 4.6, we've also covered App-V deployment models, replacing the Electronic Software Distribution to be reviewed in this book by the "Streaming Model".
There are several names that App-V experts use to list the deployment models, and practically these different approaches are the same, except that some of the information is reorganized.
For example, there are some articles, including Microsoft's, that include SCCM as a standalone deployment model. Others articles refers, that SCCM represents by itself a different deployment method; or even there are some approaches that refer to the ESD model as every implementation model which do not include an App-V management server.
In this book, we will consider the standalone model as the deployment model where the only requirement is the App-V client and the virtual application MSI, and the ESD as the deployment model using Streaming Servers (such as HTTP/S, File Server, SCCM, and any other third-party platform).
The full model contains the full set of components in App-V: management server (App-V SQL database included), Sequencer, Streaming Server, and App-V client.
In Full Infrastructure, clients interact with the App-V infrastructure by using the "publishing refresh" process, which is highly integrated with Active Directory. Here, users have access to their applications on logging in.
Central management for file type associations and shortcuts: Using the App-V Management Console, we can control the behavior of these components in clients, which is crucial for the applications, deployment and maintenance. Other deployment methods require modifying OSD files or even the whole sequencing process in order to manage FTAs and shortcuts.
Central licenses management: By using named licenses for each App-V package, you can guarantee that only users who have the appropriate license can run the application. And, if we are using concurrent licenses for the same application, the App-V licenses management will only let the application run the number of times permitted.
The App-V Full Infrastructure model is the most suitable when we are looking for a large, scalable, and dynamic platform in virtual applications within our organization.
The Electronic Software Distribution deployment model is focused on platforms that do not want/require management servers. The components present here are the Streaming Server, the sequencer to package applications, and the App-V client.
SCCM is the platform commonly used with ESD deployment methods. System Center Configuration Manager is highly integrated with App-V, providing a simple way to re-use an existing platform to deploy our virtual applications, optimizing our costs.
SCCM architecture is designed for large and scalable environments since it is not only in charge of deploying applications. Configuration Manager possibilities refer to all the life cycle in desktops, starting in the operating system deployment (OSD feature in SCCM), patch and application management, as well as hardware and software inventory, and so on.
App-V Streaming Server: Using the RTSP/S native protocol to distribute applications
HTTP/S Streaming Server: Configuring a web server such as IIS
Third-party tools support publishing App-V applications such as XenApp. This Citrix platform publishes virtualized applications created by their own technology as well as Microsoft's App-V.
The key concept here is "publishing". This is not the same as deploying or streaming. Publishing represents the process of notifying clients about resources available (in this case, applications), but the delivery, deployment, or streaming process is still performed by this third-party tool or any other method supported by the vendor.
For more information about this interaction, take a look at the following links:
How to publish an App-V-enabled application in Citrix XenApp: http://support.microsoft.com/kb/931576
Publishing App-V Sequences in XenApp: http://support.citrix.com/proddocs/topic/xenapp6-w2k8-admin/ps-pub-app-v.html
Streaming is the process of the App-V client obtaining the sequenced application package, starting with FB1 (feature block 1) and the rest; FB2 (feature block 2) is acquired on demand.
In the streaming possibilities, we already know about App-V. Here's a little summary on each of them that includes the pros and cons:
Simple, low-cost solution to configure an existing file server with the
No active upgrade
Supports enhanced security using IPSec
Supports enhanced security using HTTPS protocol
No active upgrade
Only using one port in the firewall
Active upgrade supported
Server administration requirement. Can handle fewer simultaneous cached launches than file or IIS servers
Supports enhanced security using RTSPS protocol
If we are using RTSPS, only one port in the firewall is used
This is the minimalist mode of App-V with no infrastructure required, but App-V Sequencer, to generate the applications the first time and the App-V Desktop Client.
Sequencing the application adds all the necessary files into one package and generates an MSI file that you can use to deploy manually (distributing with a CD/DVD or USB drive), scripting and Group Policy (having GPO involved to distribute it will require, of course, Active Directory), or using the System Center Configuration Manager (SCCM).
This model is in use when you have several offline users. It also has several uses when the cost of distributing to branch offices with a small bandwidth is too high.
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.
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
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:
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.
Next, the client will send a request for publishing information to the Management Server over RTSP or RTSPS, depending on the client configuration.
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.
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.
The client computer creates the appropriate shortcuts and registers file type associations based on the publishing information from the server.
Finally, any offline reporting information will be sent to the management server to be placed in the data store for reporting.
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:
A user first double-clicks the application icon, or tries to open a file with an FTA associated to a virtual application.
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.
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.
After ensuring that disk space is available, the client will stream the primary feature block of the package (
SFTfile) from a server with the appropriate package. App-V supports streaming package files from the following locations:
CONFIGURE PACKAGEwith the
/OVERRIDEURLswitch allows an administrator to change the Streaming Server on an individual package.
OVERRIDEURLis 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.
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.
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 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
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
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)
1 (Previously Used)
This parameter indicates what will be autoloaded when any given
(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.
AutoLoadTriggers, we can use the
AUTOLOADTRIGGERS=[0|1|2|4|5]parameter. The numbers used are the same as we reviewed previously.
AutoLoadTarget, we can use the following parameters:
SFTMIMEcommand will be reviewed in Chapter 4, Handling Scripting and App-V Command Lines.
In this chapter, we had the chance to take a complete tour of the App-V components and architecture. Learning about these concepts can introduce us to an optimized new implementation and healthy operations in App-V.
We've reviewed the App-V server components and the sequenced files present in each virtual package, and we also had a good look at the App-V client modules. This last topic is not usually used by most admins, ignoring the fact that some of the most important optimization parameters are included in the client.
We understood the Global and User Data directories present on each App-V client, and how the particular application's modifications are stored within these directories, including one of the key components in the App-V client cache.
We also took a quick tour of the deployment possibilities and differentiating them to understand which possibility (or possibilities) is best suited for our organization. In order to understand most of that, it is also important to understand the App-V client and publishing interaction processes.
We had a good glimpse at the App-V platform, and reviewed some key concepts that will probably clarify a lot of topics and highlight necessary information for a healthy App-V implementation and maintenance.
In the next chapter, we are going to keep up with some advanced topics; this time by using advanced sequencing techniques in App-V.