Archive

Posts Tagged ‘streaming’

App-V 5: On the LocationProvider and the IgnoreLocationProvider Feature


In a previous blog entry, (http://blogs.technet.com/b/gladiatormsft/archive/2014/12/10/app-v-5-on-the-packagesourceroot.aspx) I discussed the PackageSourceRoot override and how it can be used to control source content locations for packages. There is another option for overriding source content locations for App-V packages: the LocationProvider registry value located in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreaming.

This registry value is not designed to be changed or adjusted manually. It is simply a configuration item that denotes the COM interface and its subsequent registration. When this value is empty, that means there is no LocationProvider interface registered. If one is registered {by GUID} than whatever its setting for the package source root per package takes precedent over the PackageSourceRoot registry setting or other per-package settings. This is how the Configuration Manager client hooks into the App-V client. It uses the COM provider called the VAppLaunchManager which essentially takes over package management with an event-driven methodology.

From the context of how is overrides the PackageSourceRoot, think of this as being a replacement for the manual registry setting of the OverrideURL setting done in previous versions of App-V and SCCM integration. If the application has not been streamed or fully loaded, the App-V Streaming Subsystem will reference this interface to retrieve the Override URL for the package (i.e. the SCCM Distribution Point) from which the package will stream from. This will happen under each time there is a:

  • First connection to a package.

  • Reconnection after a previous session was closed or a user has logged off.

  • Change in the network (move to new network, network interface reset, etc.)

The interface will be registered initially once the clients receives the first targeted advertisement of an App-V 5 virtual application from Configuration Manager. This is a much improved experience from the implementation of Configuration Manager 2007 and App-V 4.6 as existing packages will remain on the client

Now this brings up another likely question: Can you create exceptions to clients being controlled by the Configuration Manager client or some other ISV that might leverage the LocationProvider interface? Let’s say you have a subset of computers within a collection that you not only do not want receiving virtual advertisements from Configuration Manager, but you may also desire managing the applications by way of another mean altogether. In previous implementations of Configuration Manager and App-V integration, field resources came up with using custom policy exceptions (see Rob York’s old blog here: http://blogs.technet.com/b/virtualworld/archive/2010/07/07/using-sccm-local-policy-to-selectively-restrict-app-v-integration.aspx) and this worked.

So if you wanted to globally manage all of your resource physical machines, virtual machines, and devices through Configuration Manager (including the delivery of virtual applications) except for possibly a subset of machines in which you may want to manage the applications in a stand-alone fashion (i.e. RDS Servers, etc.) – how do you go about setting that exception in App-V 5? You could probably easily go about the same process – but what if you wanted to use Configuration Manager to publish the applications but still take advantage of the PackageSourceRoot? Why? Well, for reasons such as:

  • Having multiple App-V delivery systems but would like to reduce duplicity on content between content servers and distribution servers.

  • You want to manage affinity with content locations out-of-band from Configuration Manager

  • You want to provide streaming high availability with better failover than the distribution point failovers in Configuration Manager (which are not instantaneous as load-balanced shares.)  

You can have this by setting the value IgnoreLocationProvider to 0x1 (DWORD) in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreaming. This setting will force the client to ignore the path returned by the LocationProvider interface and instead use the Package Source Root. This was first introduced in App-V 5 SP2 but it was somewhat problematic. The feature works well now in Service Pack 3.

Advertisements

App-V 5: On the PackageSourceRoot

December 9, 2014 4 comments

One way App-V client administrators are able to centrally control and override content streaming locations has been through a client-based content-path override. In App-V 5, this is called the PackageSourceRoot configuration item. The PackageSourceRoot configuration item is used to override the Package URL of the individual package retrieved from the publishing server. Otherwise, the package will stream from the location specified in the publishing metadata received from the App-V Publishing server (which matches the URL specified when the package is imported and stored in the management database.)

Moving from Test Content Share to Production Content Shares

Often when administrators are staging content, they will place the content in temporary directories that are commonly labeled as test or UAT for “user acceptance testing.” This might not be the final path as the UAT path may be local and the production path may reside on a replicated DFS share. Rather than remove and reimport to correct the path, the PackageSourceRoot override resolves this issue.

Branch Office Scenarios

In environments where you have centralized publishing servers managing multiple branch office sites, you may not necessarily want the content streaming over slow WAN links and BranchCache may not give you enough first launch stream speed. You can leverage local file servers to stream content locally and use either installation switches, environment variables, or AD Site-based group policies to control the PackageSourceRoot location as opposed to specifying an environment variable.

Operations

The concept of the PackageSourceRoot is nothing new. It was originally introduced in App-V 4.5 as the ApplicationSourceRoot which allowed for the same flexibility. Like the ASR in 4.x, the protocol used for the PackageSourceRoot depends on the URL format used (\servershare vs. http://server/share.) Bear in mind the value is checked ONLY when a new streaming session needs to be created for a package – NOT before every single streaming operation or stream fault. This is the reason the effect is not instantaneously seen on existing packages that have already done streaming operations (including background streaming operations) since the last restart. Expect to wait a minimum of 30 minutes if packages already exists as this is the default timeout to close idle streaming sessions for a package. The PackageSourceRoot works with Shared Content Store configurations as well. It will be overridden if the Location Provider has been configured when using Configuration Manager scenarios.

If for some reason the PackageSourceRoot is incorrectly configured either manually or through policy, packages will NOT revert back to the package’s default URL from the Publishing Server metadata and will throw an error when trying to publish (0C-80070035) which translates to ERROR_BAD_NET_PATH due to the PackageSourceRoot location not being accessible.

There were some issues early on with App-V 5.0 where there were issues if the PackageSourceRoot was several levels deep or leveraged the same server under a different port for HTTP. Please make sure you are using the most updated build of App-V 5.

App-V 5: On Background Streaming

December 3, 2014 2 comments

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

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

 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)

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 (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 5: On App-V Nomenclature


As you may have figured out by now, App-V 5 has components that are referred to by multiple names depending on context. In some cases, App-V 5 basically takes the synonym concept to interesting levels. This can be misleading if misinterpreted. This can lead ISV’s and IT Pros down the wrong path with regards to troubleshooting, integrating with, or developing for – App-V. App-V 5 also brought us a whole bunch of new things that were really only new to the App-V product itself and not necessarily new to Windows as a whole. This is pretty clear once you are pointed back to the API reference. So to clear up potential confusion. I would like to take the time to point some of this information out. For those of you who are already App-V 5 experts, you may find this a little rudimentary and (dare I say it) boring – but we do have users who are new to App-V now following this blog on a regular basis. ?

A Virtual Process is also an Application

Whereas we had packages that contained applications in App-V 4.x and each application had its own set of configuration metadata, now we have metadata tied only to the package and the applications are launched by executables directly. Virtual applications are specifically pointed out and enabled within the package metadata. Applications are referred to as virtual processes when it comes to manipulation through PowerShell (i.e. the Start-AppVVirtualProcess cmdlet), but when turning on or off applications within Configuration Manager or the App-V Management Console, we are speaking still of Applications.

Targeting Reflects Publishing Method

User Targeting within a management system translates to the application being published to the user on the client machine. Machine Targeting within a management system, translates to the application being published to the machine globally.

A Connection Group is a Virtual Environment . . . and also a Package Group

A Connection Group is a set of XML metadata that defines a virtual environment. When a Connection Group is defined manually or through the App-V Publishing System, it is referred to as a Connection Group. When a Connection Group is created and deployed via Configuration Manager, it is referred to as a Virtual Environment. You may have already been made aware of that but also be aware that Connection Groups are also referred to as Package Groups in the context of the Client Catalog. Speaking of the Client Catalog . . .

A Manifest is Configuration but not Policy

The Manifest is the embedded configuration XML metadata that stored in the AppXManifest.XML within the APPV package. Dynamic Configuration is an external configuration policy that is tied to users and/or computers. Dynamic Configuration is also referred to as policy. The Catalog is not just the manifest but rather the Catalog is the combination of the two configurations for each packages and package groups.


 
Once an application has been published to the client, depending on the target, this is where you would view catalog configuration for troubleshooting purposes.

Integration Links are Actually Junctions

For both User and Global Publishing, the integration links for shortcuts are created to sync up with the most recent package version within the immutable package cache. This saves us from having to recreate these when a package version changes. These links contain junction points not symbolic links.  A symbolic link can be either a file or a directory. It looks to be the same as a Junction Point when viewed in Explorer, but it is spelled out as a Symbolic link to a file or a directory when viewed through the command prompt:


 
A symbolic link is defined here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365680(v=vs.85).aspx. A Junction Point is just that, a Junction point. Not a hard link. Junction Points are implemented through reparse points and are defined here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365006(v=vs.85).aspx

Can you create your own integration points? Yes, you can. You can use the http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx instead of mklink /d which would actually create a symbolic link.

A Shadow File is a Sparse File . . . and Friggin’ Awesome as Well.

Shadow files are what are created in the immutable package cache when a package is published. This is where a file is created that denotes the total size but does not consume disk space other than the allocation unit required to create the NTFS file record. Data will then populate these files upon streaming the application’s files to the disk. In the case of the Shared Content Store, these files will not get populated on disk (with some exceptions for portions of primary executables.) Shadow files are implemented using NTFS Sparse files defined here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365564(v=vs.85).aspx
Sparse files appear in Explorer with a “x” to denote it has not been completely populated with data. The difference between the appearance is outlined visually below:

When viewing sparse files in the command prompt, you will see that the sparse file size indicator has parenthesis, if there are no parentheses, they are fully cached files.

To Mount is to Stream

To load or basically pre-cache, or pre-stream, we use the “Mount-AppVClientPackage” cmdlet in PowerShell. So if you wanted to manually pre-cache all of the binaries of a virtual application, you would Mount the package. In previous versions of App-V, this would also be referred to as loading.

App-V 5: On Streaming

June 26, 2014 2 comments

Now that Hotfix 4 for App-V 5.0 SP2 has been out now for several weeks, many of you have likely already seen our Updated Guidance for Performance Recommendations now available on Technet (http://technet.microsoft.com/en-us/library/dn659478.aspx.) It almost goes without saying that the new stream-to-disk model of populating individual state-separated sparse files at the native NTFS level yielded an approach to streaming that came with some caveats and albeit, a few glitches, at first.

It was a big change and a lot of the move from an isolated virtual drive to a state separate immutable package cache directory meant that there would have to be some re-engineering and with that brought changes – including changes at the philosophical level.

The basic concepts remain the same. They are just implemented differently:

In addition, a switch to the use of standard protocols already deeply rooted into Windows occurred completing the change of the streaming landscape. Many customers have asked me to clarify some of the new performance recommendations and the rationale behind some of the choices.

SMB or HTTP?

Some concepts require us to rethink how we implement our packages. For example, intra-datacenter streaming, especially for Shared Content Store scenario will yield much better results with SMB or file-based streaming. HTTP, or web streaming, will be better suited for standard streaming especially to devices external to the data center. In the case of Internet-facing scenarios, especially where data would need to be encrypted, HTTPS would be the way to go.

Feature Block 1

When the package needs to stream content for a first launch, the StreamMap.xml file (which is already cached upon publishing) will be parsed.

Once all of the files listed in FB1 (the actual element is PrimaryFeatureBlock) are downloaded, the application can proceed to launch. Our updated guidance mentions the concept of automatic stream faulting upon first launch (which is what always happens in SCS) where if there is no FB1 (like in the example below) the file will be instantly pulled down to populate the sparse file and loaded into memory thus often resulting in a much quicker launch (especially in a scenario where HTTP streaming is being used.) This significant performance hit does not reveal its ugly head as drastic with SMB streaming as it is often going to be faster especially over higher speed LAN links.

  

Remember – this also not a simple file retrieval process. The files are inside a compressed package. So extraction also has to occur and that’s going to be somewhat less costly with SMB than with HTTP.

When the application launch succeeds, the PreviouslyUsed value in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreamingPackages<GUID><GUID> wil be marked to 1. This also means that if you are using the default configuration, the Autoload settings mean that a background load task will be queued to begin. This will not happen in SCS mode. No Autoload, No FB1.

 

Removing/Updating Package Content with Opened Packages

We use metadata to govern version and package lineage from a streaming perspective and as a result, many administrators are choosing to forgo the appending of package files to include a version stamp. That is certainly an option but overwriting content on package stores may yield problems. Usually it relates to packages being in use. There are several tools at the ready to verify on your content servers what files may still be open for streaming by clients. You can use the Handle.exe tool for Sysinternals http://technet.microsoft.com/en-us/sysinternals/bb896655 to view and close open packages although I would not advise closing packages, especially in Shared Content Store scenarios as that could create application crashes and lead to data loss.

Since Anonymous authentication is not supported and access is authenticated, you can use the handle command with the –u switch to get user information. You could also revert to the old fashioned NET FILE command if you are using SMB for streaming as well.

It will also reveal the user.

I’ve noticed, and you likely have as well that when working in stream-to-disk scenarios, the handles to the packages can remain open for quite a while – even after the file has been fully cached sometimes. That is actually by design. Each App-V Client will maintain a connection to the package file for each user on a per-package basis. Like the case with previous versions of App-V, this means that there will be a lot of sessions coming from RDS clients. BUT – unlike previous versions of App-V, we do NOT have to deal with limitations caused by ephemeral ports, individual connection on a per-application basis, constant re-authentication on each application launches. There will be one session per package/user combination for stream-to-disk scenarios. NOTE – In Shared Content Store mode you may see multiple sessions depending on stream faults.

With these improvements come some caveats. The client will keep an open handle to the file when using SMB streaming. This is because these sessions involve connect to compressed packages and that can be an expensive process if you need to consistently reconnect. As a result, the App-V Client will cache open sessions for up to 30 minutes past use. I my opinion, this is a small price to pay for the added benefits and scalability that come with the changes.