Microsoft Application Virtualization Advanced Guide

By Augusto Alvarez
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Taking a Deep Dive into App-V

About this book

Microsoft’s Application Virtualization technology has been 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; also because App-V represents probably the most attractive solution. App-V introduces a new and efficient way to improve operating systems and application life cycles in organizations. However, if we want to maximize our investment we must learn that every scenario and application differs from another, as does complexity.

With Microsoft Application Virtualization Advanced Guide administrators will find detailed topics for understanding App-V components, architecture and implementation models; as well as step-by-step guidance to master App-V processes. There is also guidance on integrating App-V with other robust platforms like VDI, SCCM 2012 and even virtualizing server applications.

Microsoft Application Virtualization Advanced Guide will start by giving readers the means to discover unfamiliar topics in App-V, as well as understanding App-V's architecture. By doing so, it will provide the baseline needed before shifting to advanced topics in App-V, like complex scenarios for sequencing and deploying applications.

The book details scripting within App-V, as well as handling the platform using the command line; there is a complete review of troubleshooting installations, sequencing and deploying applications.

Integration is another key component we will cover by introducing App-V in VDI and SCCM 2012. Server applications are not forgotten with Server App-V, using this book the reader will have a detailed understanding, with how-to steps to virtualize server applications.

Publication date:
March 2012
Publisher
Packt
Pages
474
ISBN
9781849684484

 

Chapter 1. Taking a Deep Dive into App-V

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.

The App-V deployment possibilities are also something you should already know about. But, there are some misleading concepts that we will review in this chapter about the use of each of these models.

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:

    • Virtual environment

    • 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

 

What's new in App-V 4.6 SP1?


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:

  • Package accelerators: This major improvement simplifies the distribution of best practices and customizations used among applications in the sequencing process.

    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.

      Note

      There is a known issue in App-V Client 4.6 SP1 RTM that causes the "symbolic link" Q drive to register DLLs improperly. This behavior can appear inconsistently in App-V clients.

      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.

      Note

      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.

      Note

      The App-V Sequencer does not create a dummy printer. This activity remains as a best practice to apply in your environment.

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

    Note

    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:

    • Parse Items

    • Exclusion Items

    • Package Deployment Settings

    • Advanced Monitoring Options

    • General Options

  • Relax application isolation when we are virtualizing it: This option appeared in earlier versions of App-V (by using the LOCAL_INTERACTION_ALLOWED tag 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.

 

App-V components and architecture


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.

Understanding App-V server components

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.

App-V management server

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.

Tip

It is highly recommended that both of these servers, management and SQL, interact on the same network segment, because of the high amount of data that is transferred.

App-V management system

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.

Note

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:

App-V Streaming Server

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.

Note

It is important to note that only using the RTSP/RTSPS protocols in the Streaming Server requires an App-V installation. Using HTTP or SMB streaming does not need any App-V role installation.

App-V Management Server Console options

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 Reset Administrators option

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.

Note

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.

Understanding memory and core processes utilization

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.

Note

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.

Tip

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.

Understanding sequenced application components

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.

    Note

    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 Files folder 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.

  • OSD: The OSD file (Open Software Description) represents the link for the SFT file, providing all the necessary information to the client for locating and launching the application.

    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.

  • Manifest file: This XML file stores information for the sequenced application regarding the application shortcuts (Desktop, Start Menu, and Quick Launch) and the application file type associations.

    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.xml at 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 SFTMIME command.

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

    Note

    It is important to note that the SFT file is not included in the MSI (due to restrictions in the MSI file format), and we are no longer able to quickly edit the OSD file to make a change in the virtual application. Therefore, we will need to re-sequence it.

Understanding App-V client components

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:

  • Virtual environment: Called "SystemGuard" in App-V, this environment summarizes all the components virtualized that are redirected by the App-V client.

  • App-V Management Console: Within this console, we can configure several options and behaviors in the App-V client.

  • Global Date and User Data directory: These two directories are vital in App-V; common and user-specific data is kept in these locations.

  • App-V registry keys: The client machine operates with several parameters that can be easily modified in the registry. Some of these parameters can be modified using Group.

  • App-V client cache: Client cache is another key component in App-V; applications, icons, and OSD files will be stored here for re-utilization.

Understanding the virtual environment

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.

These virtual settings created are packaged in one environment called SystemGuard, where we can find:

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

  • Virtual registry: It is used for handling registry keys and requests for the application.

  • Virtual COM: It is used for managing and redirecting COM objects to avoid conflicts with the already-existing operating system components.

  • Virtual services: Embedded services in the application are captured in the sequencing process and maintained in the SystemGuard environment.

  • Virtual process environment: It is where the path environment values are located.

  • Virtual fonts: Each font created/added in the sequencing process exists only in this environment where the application can use it.

  • Virtual INI: Here, each application has private settings within virtual copies of standard Windows .INI files.

App-V Client Management Console

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.

Following are the normal user tasks that can be executed in the App-V Management Console:

  • Handling applications associated with the user: The applications listed here are those available for the user from which we can:

    • Add/remove.

    • 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.pkg from the user profile.

      Note

      A detailed explanation of the PKG files is included in the following sections of this chapter.

  • File type associations: We can also modify the file type associations generated by the applications loaded.

  • Publishing servers: Here, we have the chance to modify properties for the existing publishing servers available, as well as adding new ones.

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.

Note

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:

Here are the services and components included:

  • Sftlist.exe: Represents the App-V client service

  • Sftdcc.exe: In charge of publication refreshes

  • Sfttray.exe: Handles the notification pop-ups placed in the system tray

  • Sftvsa.exe: In charge of handling the virtual services included by the virtual applications

  • System-Guard: The isolated environment for the virtual application

  • Transport: Communicating channel to stream down the application into the client

Reviewing Management Console properties

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:

  • General tab:

    • Configure the Logging level in the App-V client, for both type of logs the sftlog and 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.

  • Interface tab:

    • Configure the visibility that the user will have when the App-V applications are running.

    • Configure the time that the common App-V client pop-up messages appear.

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

      Note

      If we change the value of the maximum cache size to a lower one than the client already has, this will not change the actual size of the cache.

      We will review the procedure necessary for resetting the App-V client cache size in the following sections of this chapter.

  • Permissions tab:

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

  • Connectivity tab:

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

Understanding Global Data and User Data directory

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.

Global 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\.

The default folders available in this directory are the SoftGrid Client and Temp folders, along with the sftlog.txt log file.

The SoftGrid Client folder is where all the necessary files are stored; here's a quick look at them:

  • Sftfs.eld and Sftfs.eld.old: This is a log file used internally in the App-V cache; it is usually used by Microsoft Technical Support to detect possible errors.

  • Sftfs.fsd: This is the App-V client SFT cache. It is a single file used by the App-V client to store all applications used in the computer.

  • Sftfs.fsG: It is also a file related to the App-V client cache, but its use is undocumented at the moment.

  • 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 PACKAGE with the /Global switch or adding an MSI-based package.

  • AppFS Storage folder: 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.

  • Icon Cache folder: Stores the icons used in the machine when a package/application is added. This directory is populated in the publishing refresh workflow.

    There is also an Icon Cache folder created in the User Data directory for the same purpose.

  • OSD Cache folder: As for the Icon Cache, this is the place where the OSD files of the applications involved and received from a server are stored.

    Note

    If the computer had an earlier version of App-V, we could also see a Resource Cache folder, which is not necessary in this App-V client version.

User Data directory

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 C:\Users\username\AppData\Roaming\SoftGrid Client.

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.

The userinfo.dat file is used for storing each user identity.

Using PKG files

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:

To understand a little bit more about these GlbVol and UsrVol files, here's an explanation:

  • UsrVol_sftfs_v1.pkg contains new or modified user-specific data from a system process that is not associated with a specific user context but is associated with a specific package.

  • GlblVol_sftfs_v1_<SID>.pkg contains 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.pkg contains 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.

  • GlblVol_sftfs_v1_S-1-5-18.pkg is only created when the package includes processes running in a different context besides the virtual, for example, a Windows service.

Regarding the User Data directory, we can find only one file:

  • Usrvol_sftfs_v1.pkg contains user-specific files that are modified or new files that are created by any user process in the virtual environment. This volume also contains the virtual environment configuration, as modified by the user.

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:

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

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

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

Understanding the App-V client cache

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.

To summarize some of the characteristics regarding the App-V client cache:

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

    Note

    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.

Reducing the size of the App-V client cache

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:

  1. In the App-V client, access regedit.

  2. In HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432\]Microsoft\SoftGrid\4.5\Client\AppFS, modify the "State" registry key to 0.

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

Registry keys available in 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: HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\SoftGrid\4.5\Client.

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:

    • ApplicationSourceRoot: This is the option that overrides the location of the SFT files received by the applications in the OSD files.

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

    • OSDSourceRoot and IconSourceRoot: Also, we can change the default location from where these OSD files are retrieved.

    • 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:

  • Network registry: Used to configure some of the network parameters in the App-V client.

    • AllowDisconnectedOperation : Also another option used for the standalone mode

    • Several network timeout values to configure

  • AppFS registry: Controls the use of the drive, filesystem directories, and files used by the App-V client.

    • State: Changing it to 0 resets the App-V client cache when rebooted

    • FileSize: Maximum value for the App-V client cache

    • FileName: Filename used for the App-V client cache

  • Permissions registry : The values here are the same ones used in the App-V Client Management Console available in Properties | Permissions (reviewed earlier in this chapter).

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.

 

App-V deployment possibilities


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

  • Standalone 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.

Note

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

Understanding the Full Infrastructure model

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.

Other important features that you can benefit from by using this model are:

  • Reporting: Detailed periodic reporting of the App-V package usage will provide us with significant information on improving our virtualized applications platform.

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

    Note

    There are some known issues regarding the enforcement of licenses in App-V. Several customers complained that the behavior is not consistent.

    The problem usually appears in scenarios where we have disconnected users, from which the system cannot verify whether the applications are running.

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.

In the following figure, we can see all of the App-V components interacting in the Full Infrastructure model:

Understanding the ESD model

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.

This streaming process is not attached to SCCM. Other similar possibilities are also available:

  • App-V Streaming Server: Using the RTSP/S native protocol to distribute applications

  • HTTP/S Streaming Server: Configuring a web server such as IIS

  • File Server

    Note

    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

Comparing streaming methods

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:

Server

Protocol

Advantages

Disadvantages

File server

SMB

Simple, low-cost solution to configure an existing file server with the \CONTENT share

No active upgrade

Supports enhanced security using IPSec

Familiar protocol

IIS server

HTTP/HTTPS

Supports enhanced security using HTTPS protocol

No active upgrade

Only using one port in the firewall

Familiar protocol

App-V Streaming Server or management Server

RTSP/RTSPS

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

Understanding the Standalone model

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.

 

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.

 

Summary


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.

About the Author

  • Augusto Alvarez

    A full time computer geek. Working as an IT Manager, coordinating and managing IT areas; envisioning, designing and implementing client-driven solutions. Also working with Microsoft Academics and Technet, collaborating on different technological events.

    Browse publications by this author
Book Title
Unlock this book and the full library for FREE
Start free trial