Much of the changes in App-V 5 revolved around moving to more integrated components (NTFS, a “real” registry, native API’s on the client, representational state transfer on the server side, etc.) – but one of the most major key developments was the modernization of the AppV Package format. The reason behind this was simple. Using this new standard based upon an open standard allows for the modernization of your legacy applications with regards to package format. This provides synergy going forward by synchronizing the packaging of legacy application with the native packaging format of your modern applications existing (or to come.)
This drastic change makes a huge difference. The package is open and human readable. No more closed, custom package format full of mystery. Pre-requisites, installation process, experience opt-in settings, configurations, and site-specific deployments can be simplified into a single-command deployment. In addition, the package format exists in an installed state that follows the principles of the open package specification outlined in the ISO standards for the Open Package Specification (OPC) - http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51459

This is also clarified in the following magazine article from MSDN: http://msdn.microsoft.com/en-us/magazine/cc163372.aspx

 
The OPC Standard

The Open Package Conventions, or as it also referred to as Open Packaging Container, are a set of standards spearheaded by Microsoft to store binary data and XML metadata in a single entity leveraging Open XML and ZIP formats. OPC-based file formats combine the advantages of leaving the independent file entities embedded in the document intact and resulting in much smaller files compared to normal use of XML. With OPC, you have a package in ZIP format that can contain mandated descriptor files, content definitions by MIME type, followed by application-specific metadata and resources files. With the embedded MIME definitions it also removes many issues associated with simple document file type extensions.

 
The container could be treated as a package or a document - as in the case with Office documents. Regardless, each is technically a ZIP archive containing resources identified as parts and each part has a unique path identifier by URI and by a specified content type expressed as a MIME type to describe the actual data stored in that part. You can see this when you browse an APPV, APPX, or even a .DOCX file using a ZIP utility.

 
In addition to a hierarchy of directories and parts, OPC packages representing document types commonly use relationships to access content through associations. These Relationships are composed of four elements:

• The identifier (ID)
• The optional source (the package or a part within the package)
• The relationship type (a URI-style expression that defines the type of the relationship)
• A target (a URI to another part within the package or to an external resource)

The extension ".rels" is reserved for storing relationships metadata within "/_rels" subfolders. The subfolder name "_rels", the file extension ".rels" within such directory, and the filename "[Content_Types].xml" in any folder are the only three reserved names for files stored in an OPC package. Otherwise, it is extensible to associate additional resource type with their specific package and application standards (for example -  those resources tied to App-V i.e. StreamMap.xml, PackageHistory.xml, etc.)

Notice in an APPV package while the [Content_Types].xml is present, the .rels components are not.  AppX and AppV handles these relationships differently using its own AppXBlockMap.xml and AppXManifest.XML files. More information can be found in that excellent MSDN article I referenced earlier: http://msdn.microsoft.com/en-us/magazine/cc163372.aspx 

AppX (Modern Applications)

AppX is the OPC-compliant package format for both Modern applications and Windows RT packages (what we commonly refer to as store applications) as referenced in: http://msdn.microsoft.com/en-us/library/windows/apps/hh464929(v=VS.85).aspx 
The AppX package can be viewed with a ZIP extraction utility just like the AppV package. Like the APPV file format, the APPX package uses declarative XML to define requirements, dependencies, and relationships defined in “AppxManifest.xml” instead of a relationship resource folder.

AppV (Legacy Applications)

While the AppX package format can be generated during modern application development (http://blogs.msdn.com/b/windowsappdev/archive/2012/12/04/designing-a-simple-and-secure-app-package-appx.aspx) your existing applications can be sequenced with the App-V sequencer and deployed, managed, and serviced as App-V packages that have the binary equivalency of the Windows Store APPX format. Even better, these can be deployed to Windows 7 computers running the App-V 5 Client (where store-based modern applications cannot.) Be advised however, that while App-V 5 uses the same file format as modern applications, it does not mean you can deploy or publish an App-V package as a Windows Store application. They only share the same modern package format.

That’s not all . . .

Document Formats have gone that way as well. Ever opened a DOCX or XLSX file in 7-ZIP? You can see the OPC-based layout this way! This is by no means new. This began with Office 2007. In fact, other vendors besides Microsoft have started to adapt this standard including Autodesk, Siemans, and Mathworks. There is an excellent historical reference on MSDN that introduced the OPC document format and relationships back in 2009 that is very helpful in understanding the Open Packaging standards as they apply to Office document formats here: http://msdn.microsoft.com/en-us/library/ee361919(v=office.11).aspx

Before you ever want to begin testing client publishing, you want to ensure that your entitlements (assignments of packages and package configurations to groups) are properly set and the publishing metadata document is properly updated with the package, configuration, and entitled groups. You could otherwise find yourself in a sea of frustration testing client publishing especially when there is nothing new to retrieve.

Assuming all of the services were installed properly, you will have two primary web services responsible for entitlement and publishing. They may reside on the same machine or they may reside on different machines. Both the Management Service and the Publishing Services run as worker processes within IIS as all services are web-based leveraging RESTful (representational state transfer) technologies. (http://en.wikipedia.org/wiki/REST.) The clients sync with the Publishing Service to retrieve data from the Publishing Service only. The clients do not sync with the Management Service which means the Management Service and the back SQL database no longer create the potential for a single point of failure as was the potential with previous versions of App-V.

Package Entitlement Process

Understanding the steps from entitlement to publishing will help you if you need to isolate actions for troubleshooting issues with packages are not properly publishing. When you open the Silverlight-based management console, just like in previous versions, you are communicating via the management web service to the App-V data store.

 
When a new package is added or modified in any way, after administrative access is verified, the manifest is extracted from the APPV package to obtain key information and configuration (shortcut’s and FTA’s). This information is then placed into the database. The method in which the package is added governs what the package URL location format is captured. This of course can be overridden at the client with the PackageSourceRoot configuration item. In addition to having appropriate administrative access for the user running the Management Console, the services will need to have proper access to the content being added.

If you specify an SMB (UNC) path to the package and file share is located on the same machine as the Management Service, you must ensure that the NT AUTHORITY\Network Service account has at least read access to the package location. If you specify an SMB (UNC) path to the package and file share is located on a different machine than the Management Service, the computer running the management service must have at least read access to the packages. If you specify the source using an HTTP-based URL, then the computer running the management service must have at least read access to the packages. Take note that you would replace the computer account with a service account should you elect to use a service account for the Management Service work process.

Publishing Sequence Number

Upon successful add or modification of the package the next step is to update the Publishing Sequencing Number. Any change in Package Configuration warrants a change in overall publishing data. This begins by incrementing the Publishing Sequence Number in the database in the Configuration table.

 
This is a crucial value as when the Publishing Service syncs with the Management Service, the Management Service compares the sequence number between the one contained in the publishing metadata versus the one in the database. If the metadata and database match sequence numbers, the existing metadata is returned to the Publishing Service. If the database number is different, then new metadata will be generated to the file system then returned to the Publishing Service. The Publishing Service will then store the data in its file system (PublishingMetadata.xml.)

 
Triggering Synchronization between the Management and Publishing Services

The Publishing Service syncs with the Management Server under the following conditions:

1.) At a periodic interval: The registry value PUBLISHING_MGT_SERVER_REFRESH_INTERVAL located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Server\PublishingService governs the interval. It defaults to 600 seconds (10 minutes.) You can tweak this value but remember it is in effect whether the Publishing Service runs on the same machine or on separate machines. If the Publishing Services runs on a spate machine, it must be added as a publishing server in the Management Console.

2.) Upon Start\Recycling of the Publishing Service Worker Process. Since the services exist as worker processes in IIS and not as services controlled in the Service Control Manager, you must restart the services by either rebooting, resetting IIS through IISRESET, or cycling the service directly by stopping and starting the worker process within the IIS Manager. If the Management Service and the Publishing Service reside on the same machine, I would be careful using IISRESET to cycle the services as you cannot control the order as to which service starts up first. You could possibly run into sync issues where the Publishing Service is unable to sync with the Management Service because it may still be in the process of restarting.

Take Note of Hotfix 2 for the App-V 5.0 Service Pack 1 Publishing Service

Hotfix 2 for App-V 5 SP2 (http://support.microsoft.com/kb/2897087/en-us) updates the Publishing Service to query Active Directory directly for the user’s group membership rather than using the Access Token. This allows for entitlements to take effect without the user having to log off (or in the case of computer targeting) having to reboot. Be advised that in addition to the hotfix being applied, you must make the following registry adjustment:

Key: HKLM\Software\Microsoft\AppV\Server\PublishingService
Data Type: DWORD
Value: RefreshGroupsFromAD
Data: 1

Prior to version 5 of App-V, when you sequenced an application that required a reboot, the reboot was simulated in that the sequencer would process the reboot action including the Pending File Operations and the RunOnce registry keys (RunOnce, RunOnceEx, GuiRunOnce, etc.) when monitoring ceased. In most cases, the simulation would be fine and all of the necessary reboot tasks would be processed properly. There were some exceptions – notably the famous disappearing Google Chrome application famously mentioned  in “Stealth Puppy’s” [I love that handle] “Case of the Disappearing Application During Sequencing http://stealthpuppy.com/the-case-of-the-disappearing-application-during-sequencing/“ where after the reboot tasks processed and the monitoring of the installation of GoogleChrome completed, the Program Files directory simply disappeared.

In defense of the sequencer, this was not as much the fault of the App-V sequencing process, but also an issue with the mechanism of the installation. This was easy to prove by going through the sequencing process and verifying the contents prior to stopping the monitoring process. The files were indeed correctly located prior to the stopping of monitoring:

However, when we ran PENDMOVES.EXE (http://technet.microsoft.com/en-us/sysinternals/bb897556)  from Sysinternals, we found this:

The operation pending was to DELETE the actual files. This would explain why the files got deleted after the monitoring process ended. The next logical step would be to see if this was a properly captured operation and not just some bug in the sequencer and install the application natively. Prior to rebooting the machine, run the PENDMOVES.exe utility again. Upon doing this, you will find the EXACT same pending file operation – DELETE C:\Program Files\Google\Chrome.

So the native installation does indeed remove the files upon a reboot. The difference is after the reboot, the files are back where they need to be! How is this possible? Google triggers updates using the Google Update service which is set to start automatically. The missing files would force the Google Update service to pull down the most up to date version. Indeed a prime example of some of the exceptions to the rule that the 4.6 sequencer was not catching.

Going back to the original issue – and never passing up an opportunity to showcase a Sysinternals utility – I would recommend a workaround. Given the issue was a DELETE operation, you could leverage another Sysinternals tool to add in a recopy function as a workaround with 4.6. Before actually stopping the monitoring process, first copy the files in question to a safe area.

Then I used the MOVEFILES.EXE utility (http://technet.microsoft.com/en-us/sysinternals/bb897556) from Sysinternals to have them moved back during the simulated reboot.

Changes in the V5 Sequencer

So to ensure that the sequencer works better with installations that require reboots (or even multiple reboots) the sequencer was changed to actually reboot. When the sequencer detects that the application is requesting a reboot, all tasks are recorded and deleted (except for the PendingFileRenames key) to force resume only after the system is rebooted and the monitoring has resumed, otherwise, these tasks could occur prior to the sequencer resuming. This information is recorded to disk (although obfuscated) and the system will reboot as normal

After the reboot, the PendingFileNames key will be processed as it would in a normal reboot. Upon the user logon, the sequencer will be launched (as it registered itself to do that prior to reboot.) Upon relaunch of the sequencer, the sequencer reads its state from the registry and the file system and restarts monitoring. The first tasks that will be processed will be the RunOnce tasks that were captured prior to the reboot.

One Exception

While the Sequencer User Interface allows for the preservation of settings and a real system reboot, this is not the case for applications sequenced using the PowerShell Sequencer Cmdlets. Since this is mostly reserved for scripted MSI packages, those usually have suppressed reboots anyway.

I have been working issues where it was difficult to determine why a specific application in a virtual application would not launch or trigger under certain circumstances. In particular, when another application called the application directly in order to pass data to that virtual application. Normally, when a native application is brought into the virtual environment through a package or a connection group, it can call other applications and virtual applications for the purposes of sharing data. In App-V 5, a native application, through the shell, can also call a virtual process and pass a file to it. In most cases, this will work with some exceptions – however – I have been able to overcome most of these issues through troubleshooting.

In this particular case the application being called is a virtual application. The application calling it was a home-grown line of business (LOB) application written by the customer to retrieve archival data from a secure portal. When the data was retrieved the data would open up within their preferred ZIP archival utility 7-Zip. 7-Zip was virtualized in this environment with App-V 5. While the virtual application would run would run fine when launched from a shortcut, when called from another virtual application within the same package or from another shell-based application as I later found, it would fail. Monitoring the customer’s custom application from Process Monitor yielded a 135 (hex 0xc0000135 or decimal 11073741515) exit code and the application yielded a pretty direct error message:

Now, before going down any deep troubleshooting, I did my due diligence and attempted reproduction on other machines including a machine as CLEAN as possible. On the clean machine and all but two machines, this issue was NOT reproducible. The plot thickens. Time to eliminate variables.

No, it wasn’t Bad Environment Variables

This was one of the first things I verified. In fact, neither the working or non-working setups had 7-Zip in their search path. Surely including it would fix the problem, and it did make the issue go away – but – while this is a fix – we had not found root cause. I don’t like not having root cause. Besides, the workaround was obviously not needed on the machines not experiencing the issue.

Time for Procmon

I took two different Procmon traces – one from a working machine and one from a non-working machine. I then created a simple filter with “7Zfm.exe” – the primary executable for 7-Zip – under the where “Path” “Contains” filter:

Once I looked at the non-working one through this filter, I had all of the answers in hand. I just needed confirmation from the customer’s developer. You will notice in the trace below, before any search of the path occurred, there was a query to the app paths key within the registry:

The app path returned a local path and not a virtual path. The path was also not existent on the machine. Once that failed, the search path was parsed and the subsequent searches failed. Upon confirming with the developer, the application was calling 7-Zip using the ShellExecuteEx function (http://msdn.microsoft.com/en-us/library/windows/desktop/bb762154(v=vs.85).aspx) which can be interrupted easily by a “rogue” app path. Upon digging into the registry, we found that the working machines had the correct app path in HKCU . . .

And the Procmon trace showed it was quickly found in the app path:

. . . but the non-working machines had the wrong app path in HKCU:

Removing this rogue app path (which came from their roaming profile) resolved the issue.

More on App Paths

One of the reasons why a native application can call a virtual application is due to the support of app paths in App-V version 5. We did not have this luxury in previous versions of App-V. App Paths allow the shell to call the application by executable without having to use the PATH environment variable. Now with App-V 5, you can call a virtual application by typing in the application in the search dialog box or the “Run” menu or even through API’s (ShellExecuteEx.) App Paths are further documented here: http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx

When publishing the package to the user in App-V 5, the path to the application is registered in HKCU\ Software\Microsoft\Windows\CurrentVersion\App Paths. When the package is published globally, it will register in HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths

The App-V 5 catalog is the client collection of package information and package group (Connection Groups) information organized by GUID containing downloaded package manifests and dynamic configuration. The metadata stored in the catalog governs the overall behavior of the application with regards to virtual operations and operating system integration. The catalogs are divided up by the global machine catalog (packages deployed machine-wide – globally published) and the user catalog (targeted to the user.)

Catalog Locations

The catalog locations are as follows:

Machine Catalog:

• Packages: %ProgramData%\Microsoft\AppV\Client\Catalog\Packages
• Connection Groups: %ProgramData%\Microsoft\AppV\Client\Catalog\PackageGroups

User Catalog:

• Packages: %AppData%\Microsoft\AppV\Client\Catalog\Packages
• Connection Groups: %AppData%\Microsoft\AppV\Client\Catalog\PackageGroups

Unlike options with integration and VFS folders which has both local romaing AppData settings, the Catalog is always set to roam with AppData for user-published packages.

Catalog Components

XML components vary between user and machine catalogs.

Machine Catalog

The default location of the machine catalog is in %ProgramData%\Microsoft\AppV\Client\Catalog. For each package there is a:

• Manifest.xml – This will be here regardless of publishing target.
• DeploymentConfiguration.xml - This will also be here regardless of publishing target.
• UserManifest.xml – This will be present if the package is globally published.
• UserDeploymentConfiguration.xml - This will also be present if the package is globally published.

For each connection group, there is a:

• PackageGroupDescriptor.xml - This will be here regardless of connection group target. It is created upon Add/Configure operation. This is a copy of the Connection Group descriptor document. It come either manually or delivered via the management system (App-V publishing server or Configuration Manager.)
• UserPackageGroupDescriptor.xml - This will be present if the connection group is globally published.

User Catalog

The default location of the user catalog is in %AppData%\Microsoft\AppV\Client\Catalog. For each package, in the user catalog, there is a:

• UserManifest.xml – Always present and generated from the base manifest within the machine catalog but not identical.
• DynamicConfiguration.xml – If additional dynamic user configuration has been supplied. If not then there will be a default UserDeploymentConfiguration.xml

For each connection group, there is a:

• UserPackageGroupDescriptor.xml – A copy of the connection group descriptor document.

One way to tell if the packages and or connection groups have been properly published, will be the presence of the Dynamic Configuration or descriptor documents.

Catalog Operations on Package Add/Configure

When a package is added or Configured, a deployment configuration file and a package manifest are created for each package and package version regardless of how the package will be published. The manifest in the machine catalog is copied out of the immutable package cache location. There will always be a Dynamic Configuration document in the Catalog, even if one is not specified manually (through PowerShell Add-AppVClientPackage) or through the delivery system.

Catalog Operations on Package Publish

The UserManifest.xml, UserDeploymentConfiguration.xml, and UserPackageGroupDescriptor.xml documents are created in the catalog during the publishing operations for packages and connection groups. For all of the documents that are generated by the App-V publishing server, these will have time stamps that correlate to the time stamps on the publishing metadata contained on the server.

Registry Storage

Catalog registrations are stored as follows:

• Global Packages: HKLM\SOFTWARE\Microsoft\AppV\Client\Package\<GUID>\<GUID>\Catalog
• Global Connection Groups: HKLM\SOFTWARE\Microsoft\AppV\Client\PackageGroups\<GUID>\<GUID>\Catalog
• User Packages: HKCU\SOFTWARE\Microsoft\AppV\Client\PackageGroups\<GUID>\<GUID>\Catalog
• User Connection Groups: HKCU\SOFTWARE\Microsoft\AppV\Client\PackageGroups\<GUID>\<GUID>\Catalog

The machine catalog registrations contain the local package store folder and the publishing source. The user catalog only contains the publishing source. All registrations contain policy file timestamp.

Catalog Caching

There are two registry values that govern the behavior of client catalog caching found in HKLM\SOFTWARE\Microsoft\AppV\Client\Catalog

• CacheMachineData: DWORD value defaults to 1 – enabled.
• CacheUserData: DWORD value defaults to 0 – disabled.

When a value is enabled, the catalog is cached and remains even after the package is unpublished. In the case of machine catalog information, this is the behavior on default. In the case of user catalog data, it is removed when a user-targeted package is unpublished or a user-targeted connection group is disabled. When a package is removed, the machine catalog information is also removed regardless of these settings.

Lingering Catalogs

Lingering Catalogs can prove problematic if they persist past a system reset in those non-persistent environments where the App-V catalog may reside on a persistent disk. You may find errors in the App-V Client service failing to start. The quick solution to this is to either ensure that the catalog root is located on a non-persistent disk, or simply remove the dead catalog upon system reset.

Environment variables are managed on a per-package basis in App-V 5 just as they have with previous versions. During sequencing, the Environment Variable Virtualization Subsystem (say that 10 ten times fast) will capture snapshots of the user and system variable list before and after the monitoring process. Then lists are compared and any differences are added to the package manifest. This means the package will default to the variable data entered in during sequencing. The variables are then stored in the package manifest using the following format:

<appv:Include>

<appv:Variable Name="TMP" Value="[{LocalAppData}]\Temp" />

</appv:Include>

Where the “Name” is the variable and “Value” is the new, tokenized (if necessary) value of the environment variable.  On the client, the named variable will be set to the new value within the virtual environment and properly translated.

The one time there is an exception to this process is when the PATH value is being handled. Applications never “set” the PATH variable – they only append, or add to it therefore if changes to the PATH value are detected during sequencing, the changes will be captured and will appear slightly different in the manifest, with a self-referential value. The PATH variable that is captured in manifest will look similar to:

<appv:Variable Name="PATH" Value="<dirpath1;%PATH%;dirpath2" />

Where dirpath1 would be a prefixed Path segment to the current PATH and dirpath2 is a suffixed path segment to the current PATH.

The sequencer can also detect the deletion of existing variables and will apply those in the manifest using the following format:

<appv:Delete>

<appv:Variable Name="TEMP" />

</appv:Delete>

In this case, the Environment Variable TEMP will be deleted within the virtual environment of the application.

These captured values can be modified and overridden using dynamic configuration. An administrator can modify DeploymentConfig and/or UserConfig to edit Environment Variables. The <Include> element beneath the <EnvironmentVariables> section is where new or modified variables should be placed. The <Delete> element is where values need to be removed. In the example below, the PATH variable is modified, two additional variables are added and one will be deleted (if exists.)

The Virtual Environment Variable Subsystem reads the package manifest and the option deployment and user dynamic configuration files, and produces two lists – variables to add and variables to remove.  This is all done when the application launches. As the catalog documents are processed, newly processed values overwrite previously processed values, so last writer wins. It is important to make sure all needed variables from the manifest are transferred over to the dynamic configuration files when leveraging them to change variables post-sequencing.

As with sequencing, there is an exception and it again involves the PATH variable. The PATH variable is injected after a process has completely loaded. This is why it is not a good idea to try to use the PATH value to help a virtual application to find a static binary dependency (even inside the immutable package cache.)

Caveat with Connection Groups

An area that confuses sequencers is how environment variables are handled with Connection Groups. Environment variable lists overwrite each when combining packages into Connection Groups. Like with registry convergence, variable convergence is a last writer win scenario in the case of overlapping variable names. The package with the highest order within the connection group descriptor document wins variable name conflicts.

Exception with Multi-String Values

Be advised though that some variables are treated specially, as they have been identified as having multi-string values.  If a multi-string variable is present in multiple packages, the resulting value is the combination of values from all packages, instead of the last writer winning. The list of variable names which are treated as multi-strings is stored in the registry at HKLM\SOFTWARE\Microsoft\AppV\Subsystem\EnvVarMultiStrings

Exception with Cross-Bitness

App-V deploys special additional tokens used to denote information that has to be adjusted depending on the bitness of the sequencing machine and the correlation of the client machine. These tokens apply to environment variables impacted by Wow64 redirection. They enable the proper translation when an application that was sequenced on a 32-bit machine gets deployed on a 64-bit client machine.

The two are:

• AppVEnvironmentVariableCommonProgramFiles: Can be %commonprogramfiles% or %CommonProgramFiles(x86)%

• AppVEnvironmentVariableProgramFiles: Can be %ProgramFiles% or %ProgramFiles(x86)%

The rules for this are as follows:

• If the application is a 32-bit application, sequenced on a 32-bit operating system, deployed on a 32-bit operating system, then these tokens are expanded back to the original values.

• If the application is a 32-bit application, sequenced on 32-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to X86 versions of the values.

• If the application is a 64-bit application, sequenced on 64-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to the original values.

Verification of Virtual Environment Variables

When testing environment variables within a virtual application package, the environment variables will not be visible outside of the virtual environment. That is why you will see no changes when you list the variables using the internal “set” command:

However, when you open the command prompt inside of the virtual environment, you will see the variables from above:

One of the most consistent recommended practices throughout the history of App-V sequencing is to always sequence on a clean sequencer. Starting with App-V 4.6 SP1, a detector was put in to warn users if they were about to sequence on a machine where a previous package was sequenced.

When the App-V sequencer is installed, it will create a registry key called ReadyBit located beneath HKLM\Software\Microsoft\AppV\Sequencer and set this value to 1. As soon as a sequence begins to go forward (creating a PVAD, Package Name, etc.) this bit will be set to 0 to inform the sequencer that we are no longer working with a clean sequencer.

So, the obvious next question would be, should we be manually resetting this bit. Only in certain circumstances. Let’s say you gave an incorrect package name or specified the wrong PVAD and went forward with the wizard and accidentally began monitoring. You had yet to install any binaries but you realized you made a mistake. Is there another option other than reverting to a previous snapshot of the virtual machine? What if you were doing this on a physical workstation? Yes, you can exit out of the sequencer, set that registry setting manually, and restart the sequencer and not have to worry about having that warning pop up during the computer preparation stage.

Please note that this is the ONLY time I would recommend doing this.

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.

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 (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.

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 (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)

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:

HKLM\SOFTWARE\Microsoft\AppV\Client\Streaming

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_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming\Packages\<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.

The latest version of the Microsoft Desktop Optimization Pack has been released! This release includes UE-V 2.1 plus App-V 5.0 SP3!

For UE-V, this includes some significant addition of features including:

• Credential Roaming Support
• Improved Office 2013 integration (especially email signatures)
• Support for cloud-based storage paths!◦

For App-V 5.0 SP3, we have fixed several issues and added some key features such as:

• Mixed Targeted Connection Groups integrated into the Management/Publishing System
• User-Targeted RunVirtual
• Consolidated Event Logging
• Improved Connection Group Performance

See the official Windows for your Business Blog for more details:

http://blogs.windows.com/business/2014/12/08/mdop-2014-r2-now-available/

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 (\\server\share 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.

This week, we have released more guidance on deploying Office 2013 with App-V 5.0 through MVA. In this 4 module course, I discuss licensing, planning, package Creation, deployment, and caveats when delivering Office 2013 through App-V 5.

The full course content can be found here:

http://www.microsoftvirtualacademy.com/training-courses/deploying-office-2013-with-app-v

If you want to bypass the course and just view the videos, you can do that on Channel 9 directly using the links below:

• Module 1: Overview - http://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/01
• Module 2: Package Creation - http://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/02
• Module 3: Deployment - http://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/03
• Module 4: Caveats - http://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/04

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_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming.

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_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming. 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.

It has been addressed to me by the MVP community that more clarification is needed with regards to the architecture of how App-V 5 implements COM and how that may now differ as a result of the changes in Service Pack 2. The differences are simplified to the difference between the standard COM virtualization subsystem for normal virtualized applications and how Dynamic Virtualization handles COM objects for native processes that do not initially start off running virtually.

COM Virtualization

I have included a visual diagram to represent how the base virtual COM subsystem works to process virtual COM in-process and how out-of-process COM servers are managed in conjunction with the App-V Client Service and the Virtual Services component in preventing COM server conflicts among native and virtual applications and among applications running in different virtual environments.

The COM API’s are hooked by way of the injected App-V DLL. Depending on the COM settings, the Virtual COM service will be responsible for dynamically cloning COM registration within the virtual environment using generated spoofed GUIDS (or CLSIDs if you prefer that term – I use them interchangeably.) It will maintain a per-package (or Connection Group) GUIDS mapping of these spoofed-to-actual GUIDS. It will also be responsible for instantiating the cloned COM server(s) needed.

Enter App-V 5 Service Pack 2 and Dynamic Virtualization

Do not confuse the above with the added support for Dynamic Virtualization (also may be referred to as just-in-time virtualization or JITV.) The basic concept behind Dynamic Virtualization is that it allows the virtualization of shell extensions and ActiveX controls automatically within the native processes which would house them (Explorer.exe and Iexplore.exe) allowing for more tighter integration with the operating system.

Dynamic Virtualization modified App-V to allow:

• Multiple Virtual Environments (VEs) to be associated with a single process.

• Processes not running as a virtual process to have VEs associated with it.

App-V 5, through dynamic virtualization, allows virtualization of an in-process COM object implementing a shell extension or ActiveX control from the process that hosts it so long as that process appears under the ProcessesUsingVirtualComponents configuration item within the registry. Dynamic virtualization switches on for a thread that is executing within the object’s code or other code that is called from the object – rather than at the process level with standard virtualization. You can read up more on Dynamic Virtualization in a previous article mentioned here: http://blogs.technet.com/b/gladiatormsft/archive/2014/02/05/app-v-5-on-run-virtual-rds-run-virtual-virtualizable-extensions-and-dynamic-virtualization.aspx

A native process never has a package’s virtual environment associated with it by default unless it is hooked by App-V. Without dynamic virtualization, the only way for it to be hooked and associated with a primary VE would be to have a shortcut configured to the application within the package (in the case of App-V 5, also configured within dynamic configuration as being a virtual application.)

With dynamic virtualization, a process can have secondary virtual environments. These secondary virtual environments are differentiated from the primary virtual environment in that they are associated with one or more DLLs that are loaded into the process, and are used for virtualization only when they are dynamically activated and associated with a particular thread of execution. For any thread in which dynamic virtualization has not been activated, virtualization will be controlled by the primary virtual environment, if any.

When a shell extension DLL handler from a particular package is loaded into a native process or a process from a different package, a new secondary virtual environment will be created to associate the shell extension’s package with the process. When a thread of execution enters that DLL, dynamic virtualization will be switched on for that thread only and associated with the correct VE. When the thread exits the DLL, dynamic virtualization will be switched off for that thread, and finally, when the DLL is unloaded from the process, the corresponding secondary VE will exit.

If you want to control Virtual ActiveX controls (huh-huh – cheap pun there) in the old fashioned way for Internet Explorer where you launch a Shortcut to IE within the virtual environment, and not allow any other native instance of IE to launch that control you will want to remove Iexplore.exe from the ProcessesUsingVirtualComponents key within the registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Virtualization.

I would advise against turning off Dynamic Virtualization altogether as the dynamic virtualization features work great with the shell extensions that would be leveraged by Explorer.

It’s actually not entirely new to Service Pack 2

Dynamic Virtualization was actually part of the flattened Office 2013 package from the initial release of App-V 5.0. The Integration subsystem included with Office allowed for native processes that needed to load a DLL from the Office package – i.e. MAPI.

If - by that question you want to know if you must start an instance of Process Monitor within the virtual application like you did in 4.x – no. You could run process Monitor inside the virtual bubble, but it will not yield you much more results. The reason behind this is simple: unlike previous versions of App-V, the REAL registry as well as the native file system – NTFS – is used in App-V 5.

In App-V 4.6 and earlier, if you did not launch process Monitor in the virtual application’s environment (usually through a command prompt) all you would capture related to the virtual application would be operations to file and registry resources outside the virtual environment. In Version 5, running Process Monitor as normal will capture access to the actual locations including registry, package store, as well as VFS (Virtual File System) COW (Copy-on-Write) locations. Why just that? Because that’s where things “actually” are located. What you will have to understand is that once the operations to where the application “thinks” it is located has been hooked in the file system and/or registry every subsequent operation will continue as such to include operations only to the:

• Package Store

• Integration junction points to the Package Store

• Actual package Store paths

• VFS COW (Copy-on-Write) checks and locations

You can see examples of these in the following screenshots from Process Monitor:

Procmon and File Operations:

As you can see above, the query to the initial location of where the virtual applications thinks it is browsing (C:\program Files (x86)\Java) is clearly not natively where it thinks it is. The App-V engine picks up for this (through relationships in memory) and the operations are redirected to the appropriate converged locations in both the User VFS COW and Package Store.

Procmon and Registry Operations

You will see similar operations when tracing specific activities to registry entries. First, where the application thinks it is supposed to be located followed by subsequent operations to the actual state-separated locations in the actual registry.

Why does Process Monitor not show every Single Operation to “Virtual Paths”

The answer is quite simple - because the App-V Client takes care of all of this behind the scenes which is why you will need to have access to and understand the FileSystemMetadata.xml file as it contains all of the file system mappings for both non-tokenized paths and tokenized paths. The easiest and most automatic relationships are the KNOWNFOLDERID paths which automatically resolve to App-V tokenized paths in memory. For non-tokenized paths, it is handled differently on process creation.

Altitude Adjustment of ProcMon Driver

When you look at the altitudes of the App-V file system drivers and their relationship to the driver altitude, you can see that the Procmon driver sits at a lower altitude by default.

This might make you explore the possibility of raising the altitude to see if Process Monitor will capture more information. Please be careful doing this as this could create problems and system instability. Altitudes are managed and allocated by Microsoft  (https://msdn.microsoft.com/en-us/library/windows/hardware/dn641617.) When developers want to register altitude locations for their filter driver, they fill out a special request form. That is how tightly controlled they are in order to prevent instability.

Microsoft Office: A flagship product suite ubiquitous within the enterprise. The average enterprise IT environment runs multiple versions of Office not only as a suite of applications for the average information worker, but also as a platform for custom and mission critical LOB applications and workflows. As Office continues to grow or evolve, the question of whether or not to virtualize all or parts of one or more versions of Office are revisited on a regular basis.

Reasons to Use App-V with Office

There are many significant reasons why you would want to deploy office through App-V. Some of the more common are:

1. Legacy Add-in Version Isolation through Virtualization: Office is also constantly evolving. As a new version is released, applications that work with or interact with an Office application may not work on a new version of an Office application. For example, you may have a legacy Add-in that works on Excel 2007, but does not work on Excel 2013. For that reason you create an App-V package that contains Excel 2007 along with that legacy add-in (or linked through connection groups.) This allows the application add-in/plug-in to continue to be used alongside of the newer deployment.

2. Temporary Coexistence: Multiple versions of most Office applications can run side-by-side with a few caveats smoother with App-V than with native deployments. While App-V can be used with many applications to run multiple versions of the same applications, Office has some additional guidance [which will be discussed in a later blog in much greater depth.]

3. Package Modernization Strategy Alignment: App-V allows for Office to be delivered via streaming in a flexible, portable format and take advantage of features of App-V such as the Shared Content Store.

In many cases, the version of Office you choose to virtualize will align with the reasoning. For example, you may be involved with a deployment of Windows 8.1 with Office 2013, and to ease transition, deliver an App-V package of Office 2010 applications for temporary use. You could also deploy Office 2013 via App-V to an existing Windows 7 base running Office 2010 due to a change in packaging strategy.

A Little History

A common question asked revolves around which versions of Office can be virtualized and what specific limitations will be encountered. To answer this – even at a 50,000 foot level – involves a historical discussion to better understand how the process and guidelines evolved with customer desires. As a result, the history affects version capabilities when running under App-V.

Office 2003/2007

Back in the day, when App-V was called Softgrid, prescriptive guidance documents were published on how to sequence Office 2003 and Office 2007 with Softgrid. It was a complicated process, but the isolation allowed for the resolution of some compatibility issues. There were a few caveats:

• Applications could not self-heal.

• Integration was limited without disabling some virtual subsystems.

• Volume-licensed installation media was required.

There were other limitations involving client-server capabilities as well. When App-V 4.x and 5.x were released, no additional integration was developed due to the age of these products. Still generally, in most cases, these versions of Office are virtualized primarily for legacy add-in scenarios where only specific Office applications are packaged with App-V (Excel, Access, etc.) and they can still be done with success.

Office 2010

With Office 2010 came a few changes that would affect how Office would be deployed with App-V. First, Office moved over to the software protection platform that previously only used for operating system product activation. As with previous versions of Office, only volume-licensed media was supported for sequencing. In addition, a special component needed to be laid down natively in order to allow the activation of Office through either MAK (Multiple Activation Keys) keys or through a KMS (Key Management Server) Server. Hosts activated via a KMS have to report back to that key server once every 180 days. Like with the native Office format, you could also verify activation status with the OSPP.VBS script.

In addition to the software protection platform, the native component (which would become known as the ODK – Office Deployment Kit) included special virtualization handlers (or proxies) that would allow for better Office integration than we had before (MAPI, Search, SharePoint, OneNote) with previous versions of Office with App-V. This special integration allowed for the base applications to remain isolated but have better native integration with enterprise components. This would become a fine line to walk. Isolation is the opposite of integration. It is impossible to fully have both. The ODK would become the best solution.

2010 – App-V was not Click-2-Run

Beginning with Office 2010, a new format that was based on App-V technology was introduced for only Microsoft Office Home and Student 2010, Microsoft Office Home and Business 2010, and Microsoft Office Starter 2010. This was a portable streaming solution called Click-2-Run or Click-to-Run. Click-to-Run was not available in the Enterprise initially and was not to be confused with the enterprise deployment of Office using App-V. Click-to-Run behaved like a native Office installation to the introduction of dynamic virtualization technologies thus, in essence, it was simply an alternative installation format that allowed for speedy quick deployment and/or upgrades to Office 2010 for consumer users.

2013 – App-V IS Click-2-Run

Well, kind of. It comes from Click-2-Run. With the success of Office 2010 Click-to-Run, the birth of Office 365 and subscription-based deployments, and the desire for better virtual integration within the Windows shell on top of the existing integration components brought forth the solution for Office 2013 – flattened Click-to-Run.

The ODT

Instead of having to manually sequence the Office package, you will use the ODT (Office Deployment Toolkit) to download and create (flatten) the APPV package. The Click-to-Run download from Microsoft will serve as the APPV package once it has been flattened. The packaging process with flattening involves converted the STREAM.DAT file into the AppV package format alongside of generating the registries and manifests. Finally an INTEGRATOR.EXE component is embedded into the package and configure to deploy automatically via a package script when the APPV package is deployed. This integrator is the next generation of the virtualization handlers that were introduced with App-V 4 and Office 2010 integration.

The Office Deployment Toolkit is periodically updated and is also the primary tool for updating the App-V package. The flattener component puts in a permanent package GUID that simplifies updating and allows for updating with the Office 365 update cycle which is in line with patch Tuesday. The Office Deployment Toolkit is also the mechanism for determining which Office applications are part of your overall Office package.

While the Office 2013 AppV package originates with Click-to-Run from the Office365 CDN, starting with Service Pack 2 of App-V 5, the App-V package can also be activated via Volume Licensing as well as Office 365 subscription licensing. This means that the Office AppV package is now the most flexible option for licensing as it is the only package format that can be activated through either subscription or volume licensing. Bear in mind the activation method will be embedded into the package upon flattening.

Dynamic Virtualization

The Office 2013 APPV package was also the first introduction to JITV (Just-in-Time Virtualization) or what is known as “dynamic virtualization.” This allowed for better shell integration and enhanced the behavior of the virtualization handler components through tighter integrated extension points. This would be available for other AppV applications beginning with App-V 5 Service Pack 2.

In Essence, the newer the version of Office is, the tighter the integration options are. This allows for Office to be incorporated into your overall App-V application factory where the new Office can be leveraged for primary use under App-V while legacy versions can be leveraged (and) isolated for special circumstances.

Better Dynamic Application Delivery through UE-V & App-V:

Aaron Ruckman and myself will be discussion recent and forthcoming innovations with App-V and UE-V as well as some general recommendations including some you may have never heard of before.

http://meme.ms/d5cdr3p

App-V 5.0 SP3: Advanced Connection Groups:

Briton Zircher and the Virtual Vibe Guy Thamim Karim will be discussing how to implement advanced Connection Groups and the recent development involving creating complex virtual environments.

http://meme.ms/d5ki5is

Fundamentals of Microsoft Azure RemoteApp Management and Administration:

You should turn out for this one as it is jammed pack full of information relating to Azure RemoteApp including some information on App-V possibilities.

http://meme.ms/d5jqcah

Microsoft Office 365 ProPlus: Have It Your Way!

Office365 offers many flexible options for deployment of the Office Client. This presentation will cover these options.

http://meme.ms/d5e74fu

Deploying Office 365 ProPlus Using System Center Configuration Manager:

This presentation outlines the pros/cons of the new Application-model versus Package-model deployment types and introduce a hybrid Application-model deployment using a Cloud DP.

http://ignite.microsoft.com/session/sessionmoreinfo/?topicid=1dd80124-2795-e411-b87f-00155d5066d7

I have been meaning to follow-up my previous discussions of the App-V registry staging subsystem with an article on the virtual registry in App-V 5. I will admit I am a little late to the follow up, however, as they say “better late than never.” In previous article I discussed registry staging and its effect on publishing and streaming. Now the discussion continues with how the virtual registry handles operations once the virtual registry has been staged.

The Virtual Registry in App-V was implemented in a much more streamlined way in version 5 than in previous versions. First of all, real hive files are packaged with the APPV package format. In addition, the real registry is used where the actual locations are state-separated while the Virtual Registry component provides the correct redirection and COW (copy-on-write) operations merging 3 elements into a single registry view:

• The native registry

• The immutable staged package registry (built from the registry.dat file within the package)

• The user and machine COW registry

Like with file assets, the view of each merged registry is done for each package and package group (virtual environment)

Functionality

At runtime, registry operations are hooked, and special sauce is made to ensure the redirection, registry merging, and copy-on-write operations of changes are done.

Registry reads are done in an ordered approach by layer and you can easily confirm this with Process Monitor. The order is:

• The COW registry is read first

• Followed by the Package Registry (constructed from REGISTRY.DAT)

• Finally the native registry for the requested location.

For registry writes, things are much simpler. Registry writes always go to the COW location corresponding to the original key that was opened. Registry data that is written to the user’s roaming registry is tokenized so that it is portable across machine boundaries.

Bear in mind, this is based upon the predication that the registry location is viewed as virtual (opaque) to begin with and was not excluded or configured to be translucent in the sequencer. There are special pointers contained in the registry that will govern opacity that I will mention later.

Registry COW Locations

The Virtual Registry will manage and track all COW locations for registry storage. The locations will vary depending on security context and type.

Roaming User Registry COW data will go here:

• HKCU\Software\Microsoft\AppV\Client\Packages\<GUID>\REGISTRY

• HKCU\Software\Microsoft\AppV\Client\PackageGroups\<GUID>\REGISTRY

Non Roaming User Registry and non-elevated Machine Registry COW data will go here:

• HKCU\Software\Classes\AppV\Client\Packages\<GUID>\REGISTRY

• HKCU\Software\Classes\AppV\Client\PackageGroups\<GUID>\REGISTRY

For Machine registry data coming from elevated processes, the Registry COW data will go here:

• HKLM\Software\Microsoft\AppV\Client\Packages\<GUID>

• HKLM\Software\Microsoft\AppV\Client\PackageGroups\<GUID>

Special Registry Key and Value Metadata

You may have noticed that for some keys, you will also see some additional data:

This data is not on all keys but when it is, it is reflective of the specific state of the key when responding to registry operations. Particularly, whether the key was previous deleted or if it was configured to be opaque and not merged with the other registry layers.

• 0x00010000: Key Deleted

• 0x00020000: Value Deleted

• 0x00040000: Key Opaque

If the value above also contains a 1 at the end of the type, this means there are sub keys present stored within the value data.

Purging the COW

The Registry COW data is purged along with the rest of the user state when the package has been deleted or when the package is repaired with the –userstate switch.

In App-V in general, the Content Store (also referred to as the package source or streaming source) is the most critical in both traditional streaming (stream-to-disk) scenarios and Shared Content Store mode clients (stream-to-memory.) Traditionally, Microsoft recommends placing Content Stores as close as possible to end user devices when possible leveraging on-premise technologies such as DFS-R to for replication and location. But what about those customers who are looking to leverage cloud services for App-V content for either:

• Disaster Recovery/Business Continuity solutions

• Internet-Facing Scenarios

• Part of an overall strategy to migrate from on-premises resources to hosted cloud services.

When looking to deploy Content Servers in Azure for application streaming, it is important to plan for regional proximity with a mechanism for replicating uniform copies of the App-V content just as you would have done in an on-premises environment.

Why Azure Web Roles can work for App-V Streaming

The App-V Content Server in the cloud is simply a hosted web server virtual machine with attached storage configuration and a corresponding set of cloud services configured to allow downloading of APPV package content via HTTP or HTTPs.  This package source requires no additional management (other than security and MIME configuration for .APPV files) of the static package content and is simple to deploy and scale out as needed.

Cloud Services and Endpoints

Assuming you have established an Azure subscription, setting up the necessary services is essential however, a lot of the minor configuration will vary depending on how these cloud resources are integrated within your existing App-V infrastructure. For the sake of example, I will use the scenario of deploying a Content Server to the cloud for the purposes of providing cloud-based content.

In most cases, the order will be to:

• Create the Cloud Service - to allow access to hosted Content VM's over the Internet

• Create the Storage Account to store the VHDs.

If you want to learn more about Storage Accounts, the reference “What is a Storage Account?” http://azure.microsoft.com/en-us/documentation/articles/storage-whatis-account/ is a good start especially when understanding storage redundancy options.

• Create the Virtual Networks

In addition, you will be leveraging external-facing Virtual IP’s (Public IP) an internal DIP, and an Azure Traffic Manager resource

Why do I need a Cloud Service, Virtual Network, VIP and DIP?

If you want to learn more about Cloud Service, Virtual Network, VIPs and DIPs, I highly recommend Young Chou’s (My buddy in DPE from Charlotte, NC) article on Windows Azure Infrastructure Services IP Address Management - at: http://blogs.technet.com/b/yungchou/archive/2014/03/17/windows_2d00_azure_2d00_infrastructure_2d00_services_2d00_ip_2d00_address_2d00_management_2d00_part_2d00_1_2d00_of_2d00_2.aspx

In addition, the following tutorials can walk you through the process:

• How to Deploy a Cloud Service: http://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-create-deploy/

• Setting up Endpoints: http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-set-up-endpoints/

• Content Management and Upload: http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/

VM Creation and Sizing

Content Servers in Azure can be any operating system supported for web services. In the case of Azure, it will be Windows Server 2008 R2, 2012, and 2012 R2 SKUs.

For Virtual Machine sizing purposes, it is recommended to align and plan capacity for Azure VM’s using the same guidelines for on-premises using the official App-V Sizing document: https://technet.microsoft.com/en-us/library/dn595131.aspx

I have found in my early testing with customers and myself, it is economical to scale out Standard Tiers using A1 or A2 series VM’s and load-balance as needed since we are only serving up web content essentially. I’ll also explain another reason when diving into the streaming protocol selection.

Internet Facing Scenarios

For App-V client retrieving content from cloud-based servers, there are three important factors to consider:

• Streaming/Performance

• Streaming/Bandwidth Costs

• Security

Streaming

For Azure Web Services, streaming APPV package content from the cloud is quicker using HTTP although the tradeoff of non-secure transmission may not meet all security requirements of some organizations. For those organizations, additional security of the cloud services for HTTPS communications will be required. Also you will need to flip the App-V clients to use single-range HTTP communication as opposed to multi-range.

BranchCache is Your Friend

To ensure fast, optimal delivery for on-premises App-V clients, and to provide the best experience possible for devices that may use the stream-to-disk scenario with clients – it is recommended to have the clients configured for BranchCache in either hosted mode or distributed mode. In addition, it is NOT recommend the use of Shared Content Store mode for on-premise clients due to limitations of offline access and heavy latency with the single-range HTTP protocol. Potential latency that may come with Single-range protocols would be offset and optimized by use of the BranchCache protocol. In addition, BrancheCache can reduce traffic overall to the cloud.

Security

In addition to security content transmission, you will want to secure access between your on-premises clients and the Azure-hosted cloud services. If the on-premises domain for which the App-V Client’s belong is federated with an Azure AD domain, you can secure access through individual users. Otherwise, you will need to leverage an alternative solution for restricting access.

Whitelisting IP Address Access

You can restrict access by IP address range in at least two ways. You can leverage the existing IP and Domain Restrictions feature in IIS. This will also work to secure Azure App-V Content servers to only allow access to IP addresses and domains that you have specified in a whitelist. https://technet.microsoft.com/en-us/library/cc731598%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

You can also secure access to the cloud endpoints using ACLS.  http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-set-up-endpoints/

Regardless of how the web service is secured on the back end. For streaming seamlessly, it is also recommended to add the URLs of the resources to the App-V Client’s Intranet Zone policy.