Udostępnij za pośrednictwem

On Troubleshooting HTTP Streaming

  • Artykuł

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

 Priority

 Timeout

 Retries

 Wait Between Retries

 Stream Faults

 Real-time

 30 seconds

 3

 5 Seconds

 Loads/Mounts (Normal Stream)

 Medium

 Unlimited

 3

 5 Seconds

 Background Streams

 Low

 7 Days

 Infinite

 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:

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.

 Error String

 HRESULT

 WinHTTP Response

 ERROR_WINHTTP_NAME_NOT_RESOLVED

 0x80072EE7

 12007

 ERROR_WINHTTP_CANNOT_CONNECT

 0x80072EFD

 12029

 ERROR_WINHTTP_CONNECTION_ERROR

 0x80072EFE

 12030

 ERROR_WINHTTP_OPERATION_CANCELLED

 0x80072EF1

 12017

 ERROR_WINHTTP_TIMEOUT

 0x80072EE2

 12002

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

 HRESULT

 WinHTTP Response

 ERROR_WINHTTP_SECURE_FAILURE

 0x80072F8F

 12175

 ERROR_WINHTTP_INVALID_URL

 0x80072EE5

 12005

 ERROR_WINHTTP_UNRECOGNIZED_SCHEME

 0x80072EE6

 12006

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