Book Image

Microsoft Application Virtualization Advanced Guide

By : Augusto Alvarez
Book Image

Microsoft Application Virtualization Advanced Guide

By: Augusto Alvarez

Overview of 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.
Table of Contents (17 chapters)
Microsoft Application Virtualization Advanced Guide
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

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.