App-V 5: On Streaming

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.

 

App-V 5: On AddPackage and ConfigurePackage

The other day I was troubleshooting a package add issue where I was running into a brick wall that turned out to be an awfully simple solution. While troubleshooting this, it came to me that I have not really gone into much depth as to what happens during an AddPackage or a ConfigurePackage operation in App-V 5. I mention both because they both refer to the process of laying down the necessary assets that will be needed for publishing and streaming the application. Whether we are adding the package manually using PowerShell (Add-AppvClientPackage) deploying through Config Manager, or synchronizing with the App-V Publishing Server, the methodology is the same.

You’ll notice that all of the critical XML files extracted from the APPV file will be fully cached in the base package directory even in shared content store mode. You’ll also notice the registry hive will be downloaded as well. The base catalog assets will be laid down as well in the packages catalog root. Finally, all of the assets required for publishing (under FB0 Feature Block 0 – the publishing block – mostly icons) will be cached. This is why even if Shared Content Store mode, all of these small files are usually fully populated files and not just sparse files. All of this before the actual publishing events regardless of targeting. If all goes well, you will see a value of 1 under the PackageState registry value for each package under:

HKLMSoftwareMicrosoftAppVClientStreaming]Packages<GUID><GUID>

The values possible for PackageState are:

1 – Package has been staged/configured successfully.

2 – Package has been deleted.

3 – The package has been fully mounted (loaded) into the App-V cache.

0 or anything else (HRESULT) – means a problem has occurred.

If you are running in Shared Content Store mode, the only files that will be fully cached into the sparse files will be publishing assets and probably most of the initial executables for the applications. Prior to streaming, this will also be the case with the default stream-to-disk scenario. Once the package has been streamed down, the files will be fully populated. Note that EVEN in Shared Content Store mode, if you pre-cache the application using Mount-AppVClientPackage all of the files and assets will be fully streamed to the disk or cached for that particular package.

Package Rollback

If for some reason, the AddPackage/ConfigurePackage event fails, the AppV client will try to clean up everything be it a script failure (where rollback action is selected) or an issue with the package itself. The PackageState will be 2. If the package cannot be removed because files are in use (which could be the case when scripts are involved) the package will be marked for pending deletion. Look for 0x8007012F which means “Pending Delete.” When the client service is restarted, the client will re-attempt the deletion of packages that are in the deleted state. Once the removal is successful, the registry entries for the package will be gone.

App-V 5: Be Careful Toggling Shared Content Store Mode

One of my colleagues in support let me know of an important note for those upgrading to App-V 5.0 Service Pack 2 Hotfix 4. It appears that the value for Shared Content Store (registry value SharedContentStoreMode in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreaming or the same option using Set-AppvClientConfiguration) can be set back to 1 from 0 thus turning it off. If you have not yet upgraded to Hotfix 4 and are planning to, you will need to ensure that this value get reset after installing the hotfix prior to rebooting the App-V client post installation. If you are currently using Shared Content Store Mode, and this value gets set back to 0, some interesting things may happen. This will likely not be a factor if you are controlling the configuration of your App-V 5 client through Group Policy.

 

To tell if a value is controlled by policy, you can quickly run the Get-AppVClientConfiguration –Name SharedContentStoreMode to check the SetByGroupPolicy value.

New Launches Will Stream to Disk

This is the most obvious change and you will likely notice this by seeing the streaming progress indicator which was not used when running in Shared Content Store mode.

You may also find Packages Start Magically Populating in the App-V Cache

You will notice that the sparse files in the PackageInstallationRoot may start populating. This is because the Autoload setting which was ignored while running under Shared Content Store mode is now in effect. The Autoload value is in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreaming and has the following possible values:

• 0: Disabled

• 1: Previously Used Packages only (Default.)

• 2: All Packages

Since 1 is the default, and the packages were already previous launched, guess what? Yes, they will start background streaming which is why those sparse files are populating. All packages under HKLMSoftwareMicrosoftAppVClientStreamingpackages that have PreviouslyUsed set to 1 will background stream.

Setting it back to 0 Alone may not Fix Everything

Once a client is in Shared Content Store Mode, you can easily stream to disk overriding it on a per-package basis by pre-caching the application using the Mount-AppvClientPackage powershell cmdlet. In addition, when applications are launched and the PackageState value stored under HKLMSoftwareMicrosoftAppVClientStreamingPackages is set to 3, it will still launch from the cache. It will also likely continue streaming if the StreamedBytes value is populated.

The values under HKLMSoftwareMicrosoftAppVClientStreamingPackages are great for troubleshooting and debugging, but if you want to revert these packages back to proper functionality under Shared Content Store mode, I would advise you remove the packages and republish them (or resync with the publishing server after removing the packages depending on how you are delivering the applications.) Modifying these values directly can be dangerous and may yield undesirable results which would require you removing and republishing them anyway.

 

App-V 5: The Case of the Failed Connection Group Descriptor (or . . . Another Reason not to Use Notepad for XML File Creation)

Have you ever noticed that when you go to save a newly created file in Notepad, the default encoding is ANSI? And this matters to App-V how you ask?

Normally this may not matter to you but I should inform you that this actually is important – especially if you are a purist and insist on using Notepad to create XML files. In the case of App-V, you may be using it to create dynamic configuration files or Connection Group Descriptors to test Connection Groups in stand-alone mode.

Take the following Connection Group XML descriptor document:

<?xml version="1.0" encoding="Unicode" ?>

<appv:AppConnectionGroup

  xmlns="http://schemas.microsoft.com/appv/2010/virtualapplicationconnectiongroup&quot;

  xmlns:appv="http://schemas.microsoft.com/appv/2010/virtualapplicationconnectiongroup&quot;

  IgnorableNamespaces=""

  DisplayName="GAME_JAVA"

  AppConnectionGroupId="2a77f876-4ab2-4d1a-8b95-9af4f0c9a7da"

  VersionId="e479fd82-127c-411e-99b6-f116f17e195a"

  Priority="42">

  <appv:Packages>

<appv:Package DisplayName="JRE6U32" PackageId="58bade90-3338-4ef5-bdf7-c7bc87c3b177" VersionId="0ec92974-d30a-4dd9-b52c-77b0ea7e59ef"/>

<appv:Package DisplayName="FREECOL_VFS" PackageId="1f635638-3e0b-44da-98f4-48f12e823c65" VersionId="6fcb3000-d4b5-45e6-991f-f88c6668b9aa"/>

  </appv:Packages>

</appv:AppConnectionGroup>

 

Do you notice anything wrong with the above document? Me neither. However, if you were save the file in Notepad using the default ANSI encoding, you may run into problems when you try to add the Connection Group.

 

The error you will get is:

 “Data at the root level is invalid. Line 1, position 42.”

You’ll notice that in the event of this error, you will likely not see much of anything else in terms of logging. The root cause is exactly what the error states. It is invalid data – due to encoding.

You can also confirm this by attempting to view the XML document in Internet Explorer. If there is an encoding mismatch where the encoding is ANSI instead of unicode, IE will just simply show a blank page. Proper XML encoding will show up correctly formatted as shown below:

 

Applications such as XML Notepad and Notepad++ match up with the schema specification automatically – especially Notepad++ (which I actually use) when you specify the output as XML specifically.

Now some savvy users may want to know what would happen if they simply just changed the element of ENCODING to ANSI in the XML document. It will error out as well because ANSI encoding is not supported.

App-V 5: Creating and Testing Office 2013 Connection Groups in Stand-Alone Mode

App-V 5 has evolved significantly since its initial release in the fall of 2012. Many of these changes have had an effect on how the Office 2013 AppV Package interacts with the Explorer shell and, as a result, have created a challenge for those of us (like me) who like to first test Connection Groups which contain the Office 2013 AppV package.

I find testing Connection Groups first in standalone mode very valuable because I can confirm that the connection group works and get fine tune the application package order as needed when I am testing and debugging Connection Groups. I can then test the deployment though the App-V Publishing Server or through Configuration Manager once I have validated that the Connection Group works.

TO quickly review how to create a connection group in stand-alone mode, you must first publish the packages. In the case of Office, I will publish the Office package globally as well as the add-ins I am testing. After the packages have been published, I can then proceed to create the connection group.

You create the Connection Group using the Add-AppVClientConnectionGroup cmdlet and you enable it (matching target) using the Enable-AppVClientConnectionGroup cmdlet. The Add-AppVClientConnectionGroup requires the creation of an XML descriptor document which is documented here: http://technet.microsoft.com/en-us/library/jj713474.aspx

Since the user state and launch management will be changing, the packages must not be in use. The thing is, you will find in App-V 5.0 SP2 and later, that once you try to enable the Connection Group, it fails with the following error – even though you have not launched any Office application:

The operation was successful but at least one of the Virtual Processes in this Connection Group is currently in use. Please shutdown all Virtual Processes in the Connection Group in order to complete this operation.

Operation attempted: Enable Connection Group.

AppV Warning Code: 0200000510

Sure enough, when you run the Get-AppVClientPackage command, you will see that the Office 2013 Package is indeed already in use. How is that possible you ask? Because of Dynamic Virtualization and the fact that Explorer is processed using virtual components by default. This is to enable support for enhanced shell extensions as well as applications that hook into Explorer directly such as OneDrivePro.

If you try to run the Stop-AppvClientPackage command against the Office 2013 package, you will find that it kills Explorer, which in turn automatically restarts, thus re-triggering the package back in use. You will also notice that the Connection Group enablement task does not show up under pending tasks in the HKLMSoftwareMicrosoftAppVClientPendingTasks.

What you have to do is turn off Dynamic Virtualization and remove Explorer.exe temporarily from the ProcessesUsingVirtualComponents value in the registry: (HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientVirtualization)

I use these series of PowerShell commands:

First, I turn things off:

PS C:WINDOWSsystem32> Set-AppvClientConfiguration -ProcessesUsingVirtualComponents 0 -EnableDynamicVirtualization 0

I then reboot or restart the AppV Client service.

I then create and enable the Connection Group using the Add-AppVClientConnectionGroup and Enable-AppVClientConnectionGroup cmdlets:

Finally, I reset things back the way they were using the following PowerShell command:

PS C:WINDOWSsystem32> Set-AppvClientConfiguration -EnableDynamicVirtualization 1 -ProcessesUsingVirtualComponents %SystemRoot%Explorer.exe,"%ProgramFiles%Internet Exploreriexplore.exe","%ProgramFiles(x86)%Internet Exploreriexplore.exe"

I then reboot or restart the AppV Client service and test the Connection Group functionality.