On Troubleshooting HTTP Streaming

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:

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:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming\

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 (https://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspx) 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:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa384105%28v=vs.85%29.aspx

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

https://msdn.microsoft.com/en-us/library/windows/desktop/aa383770%28v=vs.85%29.aspx

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.

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:

In addition to the above WinHTTP errors, there will not be retries if the following HTTP status codes (https://msdn.microsoft.com/en-us/library/windows/desktop/aa383887%28v=vs.85%29.aspx) are returned from the server.

• HTTP_STATUS_DENIED (401)

• HTTP_STATUS_FORBIDDEN (403)

• HTTP_STATUS_NOT_FOUND (404)

Comments

• Anonymous
  December 03, 2014
  Several years ago, I wrote an article for the App-V team blog on the Autoload feature that was first
• Anonymous
  December 03, 2014
  Several years ago, I wrote an article for the App-V team blog on the Autoload feature that was first
• Anonymous
  January 07, 2019
  The comment has been removed