Archive for October, 2014

On Troubleshooting HTTP Streaming

October 30, 2014 2 comments

In App-V stream-to-disk scenarios where HTTP will be used as the streaming protocol, having some architectural knowledge under your belt will help you in troubleshooting adjustments or failures when attempting to stream or launch applications.

Performance and Priority

There are three types of requests. Each stream will be assigned a priority based upon the type of stream we are dealing with. If a higher priority request is running on the same connection, it will take precedence over other requests. The following table lists the priority levels, time out, retry, and wait values:

 Type of Request




 Wait Between Retries

 Stream Faults


 30 seconds


 5 Seconds

  (Normal Stream)




 5 Seconds

 Background Streams


 7 Days


 15 minutes

One of the reasons why we recommend to not use Feature Block 1 and to take advantage of Stream Faults is the fact that it runs at a much higher priority than the standard stream. This was especially crucial for Shared Content Store. For normal stream operations, you can adjust the number of retries and the retry interval by making adjustments to the ReestablishmentRetries and ReestablishmentInterval values in:


Basic Testing

Assuming the server hosting the content is set up properly (i.e. APPV MIME type set up properly as Plain/Text, etc.) the quickest way to isolate issues with the client versus the network or server is to test accessing the data in Internet Explorer. Remember that Internet Explorer must be running in the matching user context.

HTTP-related Error Messages

In an earlier blog post I wrote on the App-V 5 error code format ( where I discuss the last 8 digits being used often to pass through a Windows HRESULT. This will be very crucial when understanding HTTP-related error messages and return codes. The HRESULT received from the App-V client will align with error messages returning from WinHTTP and the WinHttpReceiveResponse function:

The Error Codes will be the HEX variants of the status codes outlined here for WinHTTP:

In the case of the following errors, the App-V client will retry for a certain number of times depending on the request priority and how it is configured.

 Error String


 WinHTTP Response
















HTTP Streaming and Proxies

The App-V Client will share the same proxy list with the Internet Settings configuration (What WinHTTP and Internet Explorer use.) In the case of multiple proxy servers, App-V will first start trying to connect through the first proxy. If that connection is unsuccessful with a non-final error, it will continue through the list. Once a successful proxy is located, all future connections during the session will be through that specific proxy. If there is a failure through all servers in the proxy list, there will be a final request through a direct connection.

What do you Mean by “Non-final Error?”

Non-final errors are errors that will be retried rather than terminate an attempt. The above table of errors represent these non-final errors. The below table represents errors where there will not be retries:

 Error String


 WinHTTP Response










In addition to the above WinHTTP errors, there will not be retries if the following HTTP status codes ( are returned from the server.




Categories: Uncategorized Tags: , , ,

App-V 5: On Using BranchCache vs. Multi-Range with HTTP Streaming

October 28, 2014 Leave a comment

Like with 4.6, App-V 5 uses HTTP Streaming – however – the functionality varies depending on client configuration. Two important items to be made aware of:

  1. App-V hooks into WinHTTP and shares the Internet Settings (i.e. what Internet Explorer uses.) This makes the App-V client adhere to the underlying settings with some minor exceptions.

  2. App-V defaults to using multi-range requests instead of single range.

Why Multi-Range?

Multi-range HTTP was defined in the HTTP 1.1 specification (  in order to optimize performance and to reduce delays on downloading large amounts of data. Otherwise, the normal operation of single-range HTTP is used. In the case of the App-V client using multi-range, the expectations are for ranges to come back in the same order they were requested in but if an out-of-order range does not come back in the proper order, the App-V Client will revert back to single range. This will most likely happen in Internet-facing scenarios or situations involving streaming from the Cloud (i.e. Azure.) This will also happen if a multi-range streaming request fails with an “invalid response range” return.

Why Single Range? Well BranchCache of Course!

If BranchCache is configured in your network, the App-V client can take advantage of BranchCache be it Distributed Cache Mode (distributed amongst the various client computers running Windows 7 or later) or in Hosted Cache Mode (where the content is hosted on a server running Windows Server 2008 R2 or later.) If you are not familiar with BranchCache, you can read up more on it here: and here: Remember that in order for BranchCache to work, the server hosting the content must be running IIS and have the BranchCache feature installed.

But . . . BranchCache does NOT support multi-range. Because of this fact, when App-V 5 was released initially, the client defaults to single-range if the client machine was set up for BranchCache. There was a configuration item exposed to override this by setting the value “MultirangeEvenIfBranchCacheEnabled” to 1 either through modifying the registry, PowerShell, group policy, or as an installation flag. Remember that turning this on will not allow the App-V client to take advantage of BranchCache.

Enter App-V 5 Service Pack 2

Amongst the many feedback items that were addressed in Service Pack 2 was some of the confusion amongst the configuration of the App-V client with BranchCache. The concern was brought forth that the default to single-range HTTP when BranchCache was detected was too final and led to some confusion revolving performance. Most customers were not leveraging BranchCache for the App-V content in internal networks or using Internet-facing scenarios to stream virtual applications.

So with App-V 5 SP2, the value was changed to SupportBranchCache and it is turned off by default. This means only those customers who wanted to explicitly stream content using BranchCache for HTTP can turn it on, but otherwise, standard installations of the App-V client will take advantage of multi-range for improved performance. This should improve performance for customers who do not use BranchCache. Performance for customers who do use BranchCache will remain the same as long as SupportBranchCache is set to 1.

App-V: How the Sequencer Detects an Existing Package was Created

October 26, 2014 Leave a comment

One of the most consistent recommended practices throughout the history of App-V sequencing is to always sequence on a clean sequencer. Starting with App-V 4.6 SP1, a detector was put in to warn users if they were about to sequence on a machine where a previous package was sequenced.


When the App-V sequencer is installed, it will create a registry key called ReadyBit located beneath HKLMSoftwareMicrosoftAppVSequencer and set this value to 1. As soon as a sequence begins to go forward (creating a PVAD, Package Name, etc.) this bit will be set to 0 to inform the sequencer that we are no longer working with a clean sequencer.

So, the obvious next question would be, should we be manually resetting this bit. Only in certain circumstances. Let’s say you gave an incorrect package name or specified the wrong PVAD and went forward with the wizard and accidentally began monitoring. You had yet to install any binaries but you realized you made a mistake. Is there another option other than reverting to a previous snapshot of the virtual machine? What if you were doing this on a physical workstation? Yes, you can exit out of the sequencer, set that registry setting manually, and restart the sequencer and not have to worry about having that warning pop up during the computer preparation stage.

Please note that this is the ONLY time I would recommend doing this.

App-V 5: On Environment Variables

October 26, 2014 8 comments

Environment variables are managed on a per-package basis in App-V 5 just as they have with previous versions. During sequencing, the Environment Variable Virtualization Subsystem (say that 10 ten times fast) will capture snapshots of the user and system variable list before and after the monitoring process. Then lists are compared and any differences are added to the package manifest. This means the package will default to the variable data entered in during sequencing. The variables are then stored in the package manifest using the following format:


<appv:Variable Name="TMP" Value="[{LocalAppData}]Temp" />


Where the “Name” is the variable and “Value” is the new, tokenized (if necessary) value of the environment variable.  On the client, the named variable will be set to the new value within the virtual environment and properly translated.

The one time there is an exception to this process is when the PATH value is being handled. Applications never “set” the PATH variable – they only append, or add to it therefore if changes to the PATH value are detected during sequencing, the changes will be captured and will appear slightly different in the manifest, with a self-referential value. The PATH variable that is captured in manifest will look similar to:

<appv:Variable Name="PATH" Value="<dirpath1;%PATH%;dirpath2" />

Where dirpath1 would be a prefixed Path segment to the current PATH and dirpath2 is a suffixed path segment to the current PATH.

The sequencer can also detect the deletion of existing variables and will apply those in the manifest using the following format:


<appv:Variable Name="TEMP" />


In this case, the Environment Variable TEMP will be deleted within the virtual environment of the application.

These captured values can be modified and overridden using dynamic configuration. An administrator can modify DeploymentConfig and/or UserConfig to edit Environment Variables. The <Include> element beneath the <EnvironmentVariables> section is where new or modified variables should be placed. The <Delete> element is where values need to be removed. In the example below, the PATH variable is modified, two additional variables are added and one will be deleted (if exists.)


The Virtual Environment Variable Subsystem reads the package manifest and the option deployment and user dynamic configuration files, and produces two lists – variables to add and variables to remove.  This is all done when the application launches. As the catalog documents are processed, newly processed values overwrite previously processed values, so last writer wins. It is important to make sure all needed variables from the manifest are transferred over to the dynamic configuration files when leveraging them to change variables post-sequencing.

As with sequencing, there is an exception and it again involves the PATH variable. The PATH variable is injected after a process has completely loaded. This is why it is not a good idea to try to use the PATH value to help a virtual application to find a static binary dependency (even inside the immutable package cache.)

Caveat with Connection Groups

An area that confuses sequencers is how environment variables are handled with Connection Groups. Environment variable lists overwrite each when combining packages into Connection Groups. Like with registry convergence, variable convergence is a last writer win scenario in the case of overlapping variable names. The package with the highest order within the connection group descriptor document wins variable name conflicts.

Exception with Multi-String Values

Be advised though that some variables are treated specially, as they have been identified as having multi-string values.  If a multi-string variable is present in multiple packages, the resulting value is the combination of values from all packages, instead of the last writer winning. The list of variable names which are treated as multi-strings is stored in the registry at HKLMSOFTWAREMicrosoftAppVSubsystemEnvVarMultiStrings

Exception with Cross-Bitness

App-V deploys special additional tokens used to denote information that has to be adjusted depending on the bitness of the sequencing machine and the correlation of the client machine. These tokens apply to environment variables impacted by Wow64 redirection. They enable the proper translation when an application that was sequenced on a 32-bit machine gets deployed on a 64-bit client machine.

The two are:

  • AppVEnvironmentVariableCommonProgramFiles: Can be %commonprogramfiles% or %CommonProgramFiles(x86)%

  • AppVEnvironmentVariableProgramFiles: Can be %ProgramFiles% or %ProgramFiles(x86)%

The rules for this are as follows:

  • If the application is a 32-bit application, sequenced on a 32-bit operating system, deployed on a 32-bit operating system, then these tokens are expanded back to the original values.

  • If the application is a 32-bit application, sequenced on 32-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to X86 versions of the values.

  • If the application is a 64-bit application, sequenced on 64-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to the original values.

Verification of Virtual Environment Variables

When testing environment variables within a virtual application package, the environment variables will not be visible outside of the virtual environment. That is why you will see no changes when you list the variables using the internal “set” command:


However, when you open the command prompt inside of the virtual environment, you will see the variables from above:





App-V 5: On the Catalog and Catalog Caching

October 4, 2014 2 comments

The App-V 5 catalog is the client collection of package information and package group (Connection Groups) information organized by GUID containing downloaded package manifests and dynamic configuration. The metadata stored in the catalog governs the overall behavior of the application with regards to virtual operations and operating system integration. The catalogs are divided up by the global machine catalog (packages deployed machine-wide – globally published) and the user catalog (targeted to the user.)

Catalog Locations

The catalog locations are as follows:

Machine Catalog:

  • Packages: %ProgramData%MicrosoftAppVClientCatalogPackages
  • Connection Groups: %ProgramData%MicrosoftAppVClientCatalogPackageGroups

User Catalog:

  • Packages: %AppData%MicrosoftAppVClientCatalogPackages
  • Connection Groups: %AppData%MicrosoftAppVClientCatalogPackageGroups

Unlike options with integration and VFS folders which has both local romaing AppData settings, the Catalog is always set to roam with AppData for user-published packages.

Catalog Components

XML components vary between user and machine catalogs.

Machine Catalog

The default location of the machine catalog is in %ProgramData%MicrosoftAppVClientCatalog. For each package there is a:

  • Manifest.xml – This will be here regardless of publishing target.
  • DeploymentConfiguration.xml – This will also be here regardless of publishing target.
  • UserManifest.xml – This will be present if the package is globally published.
  • UserDeploymentConfiguration.xml – This will also be present if the package is globally published.

For each connection group, there is a:

  • PackageGroupDescriptor.xml – This will be here regardless of connection group target. It is created upon Add/Configure operation. This is a copy of the Connection Group descriptor document. It come either manually or delivered via the management system (App-V publishing server or Configuration Manager.)
  • UserPackageGroupDescriptor.xml – This will be present if the connection group is globally published.

User Catalog

The default location of the user catalog is in %AppData%MicrosoftAppVClientCatalog. For each package, in the user catalog, there is a:

  • UserManifest.xml – Always present and generated from the base manifest within the machine catalog but not identical.
  • DynamicConfiguration.xml – If additional dynamic user configuration has been supplied. If not then there will be a default UserDeploymentConfiguration.xml

For each connection group, there is a:

  • UserPackageGroupDescriptor.xml – A copy of the connection group descriptor document.

One way to tell if the packages and or connection groups have been properly published, will be the presence of the Dynamic Configuration or descriptor documents.

Catalog Operations on Package Add/Configure

When a package is added or Configured, a deployment configuration file and a package manifest are created for each package and package version regardless of how the package will be published. The manifest in the machine catalog is copied out of the immutable package cache location. There will always be a Dynamic Configuration document in the Catalog, even if one is not specified manually (through PowerShell Add-AppVClientPackage) or through the delivery system.

Catalog Operations on Package Publish

The UserManifest.xml, UserDeploymentConfiguration.xml, and UserPackageGroupDescriptor.xml documents are created in the catalog during the publishing operations for packages and connection groups. For all of the documents that are generated by the App-V publishing server, these will have time stamps that correlate to the time stamps on the publishing metadata contained on the server.

Registry Storage

Catalog registrations are stored as follows:

  • Global Packages: HKLMSOFTWAREMicrosoftAppVClientPackage<GUID><GUID>Catalog
  • Global Connection Groups: HKLMSOFTWAREMicrosoftAppVClientPackageGroups<GUID><GUID>Catalog
  • User Packages: HKCUSOFTWAREMicrosoftAppVClientPackageGroups<GUID><GUID>Catalog
  • User Connection Groups: HKCUSOFTWAREMicrosoftAppVClientPackageGroups<GUID><GUID>Catalog

The machine catalog registrations contain the local package store folder and the publishing source. The user catalog only contains the publishing source. All registrations contain policy file timestamp.

Catalog Caching

There are two registry values that govern the behavior of client catalog caching found in HKLMSOFTWAREMicrosoftAppVClientCatalog

  • CacheMachineData: DWORD value defaults to 1 – enabled.
  • CacheUserData: DWORD value defaults to 0 – disabled.

When a value is enabled, the catalog is cached and remains even after the package is unpublished. In the case of machine catalog information, this is the behavior on default. In the case of user catalog data, it is removed when a user-targeted package is unpublished or a user-targeted connection group is disabled. When a package is removed, the machine catalog information is also removed regardless of these settings.

Lingering Catalogs

Lingering Catalogs can prove problematic if they persist past a system reset in those non-persistent environments where the App-V catalog may reside on a persistent disk. You may find errors in the App-V Client service failing to start. The quick solution to this is to either ensure that the catalog root is located on a non-persistent disk, or simply remove the dead catalog upon system reset.