App-V 5: On Background Streaming

Several years ago, I wrote an article for the App-V team blog on the Autoload feature that was first introduced in App-V 4.5: http://blogs.technet.com/b/appv/archive/2009/07/28/understanding-the-autoload-feature-of-microsoft-app-v-4-5.aspx. The combinations and scenarios (not to mention, the potential network storms that could occur from post-upgrade default settings) yielded a necessary detailed explanation.

The Autoload feature continues in App-V 5 in a slightly simplified implementation through the use of low priority background tasks. These occur only in stream-to-disk scenarios and the values are totally ignored for Shared Content Store mode (unless it is toggled off.) You will recall from a previous blog (http://blogs.technet.com/b/gladiatormsft/archive/2014/10/31/on-troubleshooting-http-streaming.aspx) that these run always at low priority, have a 7 day timeout, and will try forever with a 15 minute interval between retries.

What was simplified was the autoload trigger settings in the registry. There is a single configuration value called Autoload located in:

HKLMSOFTWAREMicrosoftAppVClientStreaming

The potential values are:

• 0: Autoload is disabled.

• 1: A background task to stream will be generated after an application has been initially launched. This is the default value. These tasks will also kick in upon login if the application has been launched before. The PreviouslyUsed value for the package (located in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreamingPackages<GUID>) is how this is tracked. This will also occur if the package is updated to a new version as the PreviouslyUsed value will remain at 1.

• 2: This value means all packages will be background streamed regardless of whether or not they have been previously launched. This value can sometimes leverage unpredictable results as background streaming can begin as soon as packages are published.

Exceptions

There are some exceptions to the above configuration items:

User Logoff: Auto-loading occurs in the background under the context of the currently logged on user matched with the publishing target. This means that once a user has logged on, in order for an autoload task to initiate, the user must be assigned that package either implicitly (package globally published) or explicitly (user targeting.) When the user logs out, any autoloads running are stopped. They may resume upon another user logon on the same computer should entitlements match, otherwise, it will resume upon the user’s next logon.

Metered Connections: If you are running Windows 8 or later and the device has just moved from a normal corporate network or high-speed Wi-fi to a high cost network, the App-V client will suspend background loading tasks. This exception only occurs when streaming from a UNC path or an HTTP path. If the package is mounting from a local path, it will continue to background stream.

Connected Standby Mode: Connected Standby Mode is a new low-power state that features extremely low power consumption while maintaining Internet connectivity. Starting with Windows 8 and Windows 8.1, Devices that implement the connected standby power model run at very low power levels, but stay connected and up-to-date, even when they appear to the user to be turned off. Autoloads/Background tasks will be suspended by the App-V client when the device is in connected standby mode.

Caveats

I worked a few cases in support where the configured Autoload settings for newly provisioned (or upgraded) App-V clients created network traffic storms – especially in shift-oriented environments where everyone tends to log on at the same time. Most of this was due to the dual settings of 4.x where the trigger would occur upon logon and background stream previously used applications. However, setting this value to 2 in App-V 5 could yield similar results.

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:

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_MACHINESOFTWAREMicrosoftAppVClientStreaming

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 (http://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:

http://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:

http://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 (http://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)

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

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 (http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-11#section-5.4)  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: http://technet.microsoft.com/en-us/library/dd637832(v=WS.10).aspx and here: http://technet.microsoft.com/en-us/library/hh831696.aspx. 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 4.6: Configuration when Using Proxy Servers with HTTP Streaming

How App-V uses proxy settings will vary depending on configuration values. The values related to proxy configuration can be found under the HTTP subkey of the App-V networking configuration in the registry here:

• HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5 ClientNetworkHttp or
  HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftSoftGrid4.5 ClientNetworkHttp

Simply put, you can sum up the options into this simple table below:

Value	ForceProxyAutoDetect	SkipProxyDetection
Use IE Proxy Settings	0	0
Auto-Detect Proxy Settings	1	0
Use No Proxy	Does not matter	1

Specific registry entries related to HTTP proxy configuration and their descriptions are below:

ForceProxyAutoDetect

Data Type: REG_DWORD
Default Value: 0
Possible Values: 0-1

When this value is set to 1, it forces auto proxy detection instead of using IE proxy settings. Requires a restart of the App-V client service.         

ConcurrentRequests

Data Type:  REG_DWORD
Default Value:  4
Possible Values:   1 – infinite

If the value is greater than 1, divides the Http streaming request into concurrent sub-requests for parallel streaming. Value must be greater than zero. Recommended setting is 4 (default).  Requires a restart of the App-V client service. 

SkipProxyDetection

Data Type:  REG_DWORD
Default Value:  0
Possible Values:   0 or 1

If the value is set to 1, App-V will not use IE proxy configuration. If 1, it overrides ForceProxyAutoDetect flag. Requires a restart of the App-V client service.   

FailedProxyAutoDetectRetryTimeout

Data Type:  REG_DWORD
Default Value:  60
Possible Values:   varies

Don’t try auto-proxy-detection if it failed in last ‘x’ seconds for the current user. Where ‘x’ is the value of this flag. Requires a restart of the App-V client service.      

ProxyCacheLife

Data Type:  REG_DWORD
Default Value:  60
Possible Values:  varies

The number of seconds the http proxy info is cached by App-V in memory for a user       Requires a restart of the App-V client service.       

 

You can get more specific information by enabling the SFTLIST.log file which helps with File/HTTP Streaming troubleshooting
 
Path : HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5ClientConfiguration
 
(KEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftSoftGrid4.5ClientConfiguration if x64)
 
Value Name: TRAN  DWORD
 
Value data: 0 to 6
 
0 : NEVER (Does not open/create log file)
1: ALWAYS,  (Info that should always be emitted)
2: FATAL, (Serious system-wide errors )
3: ERROR,  (Serious errors related to one user or app)
4: WARN,   ( Print a Warning & keep on going)
5: INFO,   (Informational stuff)
6: VERBOSE,  ( Heavy-duty output for users)
7: DEBUG   ( Even more output )
 
 Logging for individual sub-modules can be handled by creating a dword value instead for each of the following Sub-Modules:
 
TRAN_HTTP – HTTP streaming traffic
TRAN_FILE – File streaming
TRAN_ASYN – requesting asynchronoze pacakge info such as FB2
TRAN_OOSR – Data header information
TRAN_CONF – configuration information
TRAN_PLCY – Policy information
TRAN_PACK – Package information
TRAN_MAIN – Main transport stream
 
 
The name of the log is SFTlist.log and its located under the install path of APPV (Ex: c:Program FilesMicrosoft Application Virtualization Clientsftlist.log)
 
This might help shed light on what specifically in the HTTP proxy communication is failing.

App-V: App-V Client Issues Streaming from App-V/IIS Server using XP with IPV6

The App-V Client (running under Windows XP) may fail to stream from App-V Server (or IIS Server) when running IPV6. You may get an error similar to the following:

[08/18/2011 10:23:32:058 JGSW ERR] {tid=10CC:usr=steveth}
The Application Virtualization Client could not connect to stream URL ‘http://server/content/application/package.sft&#8217; (rc 16D1100A-0000E005, original rc 16D1100A-0000E005).

[08/18/2011 10:23:32:058 PMGR ERR] {tid=10CC}
Failed to background load package {package} (rc 16D1100A-0000E005).

[08/18/2011 10:23:32:059 AMGR WRN] {tid=10CC}
Attempting Transport Connection
URL: http://server/content/application/package.sft
Error: 24604F0A-40002EE2

Windows XP supports DNS queries only over the IPv4 protocol, but will support IPv6 queries (such as PTR and AAAA) which is why name resolution will fail.  Unless the the WinXP client is dual-stacked with both IPv4 and IPV6, you may have issues with the App-V client and IPv6.

It is important to note that this problem is only found on clients running exclusively IPv6 on Windows XP clients only.

 

SCVMM: Service Principal Names (SPNs) Required for Proper SCVMM 2008 Functionality

SCVMM 2008, 2008 R2, as well as future versions of SCVMM rely on kerberos and kerberos delegation functionality for its security and authentication model. You may encounter various problems with SCVMM related to authentication and authorization if the underlying platform service principal names (SPNs) are not properly set.

There are all sorts of problems ranging from console authentication, to SQL access, or even host access for the purposes of accessing virtual machines managed by SCVMM. All of these problems cann be caused when delegation is failing possibly due to incorrect or missing SPNs (Service Principal Names.)

 

The resolution is to verify and correct any configuration issues with kerberos delegation, often correcting problems related to SPNs not being registered – or even duplicate SPNs.

 

You can use the SETSPN command to check for duplicate SPNs and to create missing ones if needed. Please note not all SPNs may be required as that will vary based on what server roles are installed. SETSPN is a default external command in both Windows Server 2008 and 2008 R2. For Windows Server 2003, I would recommend downloading the SETSPN update for Windows Server 2003. More information and download links are found here:

 

http://support.microsoft.com/kb/970536

 

The following list below lists all of the SPNs that may be required relating to their corresponding components. Since SCVMM is a management interface that sits on top of so many different platform components, incomplete or improper delegation at these component layers will cause problems in SCVMM functionality.

 

Hyper-V Virtual Consoles:

For Virtual Console Support for Hyper-V Hosts (VMCONNECT.EXE) – This will be required on Hyper-V Hosts. Use the following command to set and verify SPNs.

setspn -s "Microsoft Virtual Console Service/HOSTNAME" computername 
setspn -s "Microsoft Virtual Console Service/hostname.fqdn.etc" computername 

For P2V Support.

Use the following command to set and verify SPNs.

setspn -s "Microsoft Virtual System Migration Service/hostname.fqdn.etc" computername 
setspn -s "Microsoft Virtual System Migration Service/hostname" computername 

 For VS2005 Hosts and the VMRC utility

– This will be required on Virtual Server 2005 Hosts. Use the following command to set and verify SPNs.

setspn -s vmrc/hostname.fqdn.etc:5900 computername 
setspn -s vmrc/hostname:5900 computername 
setspn -s vssrvc/hostname.fqdn.etc computername 
setspn -s vssrvc/hostname computername 

For RDP Support.

Use the following command to set and verify SPNs.

setspn -s TERMSRV/hostname.fqdn.etc computername 
setspn -s TERMSRV/hostname computername 

 For all Hosts.

Use the following command to set and verify SPNs.

 setspn -s HOST/hostname computername 
setspn -s HOST/hostname.fqdn.etc computername 

 HTTP (may needed for authentication on SSP if VMM server is using Remote SQL.)

Use the following command to set and verify SPNs.

setspn -s HTTP/hostname.fqdn.etc computername 
setspn -s HTTP/hostname computername 

 SQL VMM Database

Depends on port and instance type: 

Named Instance.

Use the following command to set and verify SPNs.

 setspn -s MSSQLSvc/hostname.fqdn.etc:Port computername

setspn -s MSSQLSvc/hostname.fqdn.etc:InstanceName computername 

 Default Instance.

Use the following command to set and verify SPNs.

setspn -s MSSQLSvc/hostname:1433 computername 
setspn -s MSSQLSvc/hostname.fqdn.etc:1433 computername 
 

Here are some links to some excellent articles:

http://msdn.microsoft.com/en-us/library/ee191523.aspx

http://support.microsoft.com/kb/929650