This morning, I was on a joint webinar with Flexera (http://learn.flexerasoftware.com/AR-WBNR-Microsoft-AppV-Best-Practices) on App-V best practices and I reminded many on the call why I always prefer to use the term "current recommended practices" as opposed to "best practices." Today I explained that I know longer insist on avoiding the use of the PVAD (Primary Virtual Application Directory) and sticking to strictly VFS sequences. True, I did make this recommendation nearly a year and a half ago (http://blogs.technet.com/b/gladiatormsft/archive/2014/08/25/app-v-5-installing-to-the-pvad-don-t-do-it-yes-i-said-it.aspx ) however, at the time, App-V 5.0 Service Pack 2 required VFS sequencing to ensure connection group convergence as well as a few others mentioned in the blog post. With the addition of the merged roots feature as well as the correction of issues with the convergence of environment variables, there is no longer any major reason to force packages to VFS sequences for the purposes of making connection groups work.
Some Applications Need the PVAD for Proper Functionality
As App-V 5.0 SP3 was released over a year ago and App-V 5.1 was released a few months back, it has become known that due to issues with pathing limits and other issues related to the App-V VFS subsystem and its native NTFS integration, there are some applications which still require the use of the PVAD. By this, I mean to actually expose the Primary Virtual Application Directory (PVAD) within the App-V sequencer and selecting that same directory during the installation of the application during the monitoring phase of the sequencer. You will find many examples of applications within the App-V community. While the number of applications requiring the use of the PVAD is a relatively small percentage, the applications that are affected represent a significant footprint that involve nearly every major enterprise organization's application library. For example, Office 2010 is one of those applications. In fact, if you were to look at the virtual file system structure of the App-V package generated by the ODT (Office Deployment Tool) you would also find that the flattened Office 2013 and Office 2016 packages are actually PVAD sequences.
Better Dynamic Application Delivery through UE-V & App-V:
Aaron Ruckman and myself will be discussing 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.
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.
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.
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.
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.
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:
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.
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.]
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.
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.
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.
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.
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.
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:
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 – https://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/01
- Module 2: Package Creation – https://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/02
- Module 3: Deployment – https://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/03
- Module 4: Caveats – https://channel9.msdn.com/Series/Deploying-Office-2013-with-App-V/04
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.
We had quite a few breakout sessions on App-V at TechEd North America this year! If you were there and were not able to attend all of them or missed TechEd altogether, you can view the recorded sessions here on Channel 9:
My Presentation 🙂
Sizing App-V 5.0: Planning and Designing a Highly Available, Scalable, and Resilient Management and Delivery System
Then we have an excellent presentation by Briton Zircher on deploying Office 2013 with App-V 5:
Everything You Need to Know for a Successful Microsoft Office 2013 App-V Deployment
You also will want to see Project VRC's presentation on their independent performance analysis of App-V 5.
Project Virtual Reality Check: Microsoft App-V 5.0 Performance, Tuning, and Optimization (App-V PTO)
Are you thinking about or planning to deploy App-V 5 with Citrix XenDesktop and studio integration? You will want to see this:
Deploying Microsoft App-V 5.0 and Citrix XenDesktop 7
New to Intune? Want to understand how applications are managed with Intune? Want to know your App-V options with Intune, check out this presentation:
Application Management with Microsoft System Center Configuration Manager and Windows Intune
Finally, my favorite of the event – done by the Virtual Vibe guy himself -Thamim Karim:
The Circle of Life for an App-V 5.0 Package: From Sequence to Termination
Yes, I’m still obsessed with the subject of add-in virtualization. I felt it also necessary to ensure that there was a discussion of add-in types and multiple Office add-ins (particularly Excel) before I finally leave this topic of discussion. Have you ever noticed that when you are managingloading add-ins in Excel that you have multiple distinct types of add-ins. The two most common types are COM add-ins (common format for 3rd-party applications) and Excel Add-ins or what we refer to technically as Automation Add-ins (VSTO, XLAM add-ins.)
COM add-ins act as in-process COM servers (like an ActiveX DLL) that is built off the IDTExtensibility interface. These are pretty much event-driven and present themselves to the user in the form of custom menus, commands, etc. When a COM Add-in is installed on a user’s system, registry entries are created for the Add-in. In addition to normal COM registration, a COM Add-in is registered for each Office application in which it runs. COM Add-ins used by Excel are registered in the following registry key:
For example, if I have an Add-in called “Data Transfer Excel Add-in.” it would register in a key similar to the image below:
NOTE: Do not get confused. This registration may be used with the other add-in registrations that Office applications may use (in the HKLM or the HKCUSoftwareMicrosoftOffice<VERSION><App>Addins key.) That can also be a source of troubleshooting sometimes.
Dynamic Configuration is important when leveraging an add-in when it comes to COM settings. If the Add-in will be packaged with the application, it should remain isolated – which is the default. If the add-in is virtualized but Office is locally installed, then the COM add-in must have its COM mode configured as “Integrated” with in-process registration. If you are linking the add-ins with a virtual instance of Office via a connection group, this is also recommended (using the element “<COM Mode=”Integrated”>”)
NOTE: LOCAL_INTERACTION_ENABLED set to TRUE in the 4.6 OSD file achieves this same result.
Automation Add-ins build on COM Add-ins in that functions in Automation Add-ins can be called from formulas in Excel worksheets. While COM Add-ins must be in-process COM servers that support the IDTExtensibility2 interface; however, Automation Add-ins can be in-process or out-of-process COM servers and implementation of IDTExtensibility2 is optional. Understanding what type of COM server will determine how the add-ins COM configuration may need to be configured in the applications dynamic configuration file.
Order of Add-Ins
When you make additions to the list in the Add-Ins dialog box or when you select and clear Add-ins in the list, Excel stores your changes in the registry. First, Excel uses the following registry setting to determine whether or not an Automation Add-in in the Add-in list is loaded:
String OPENx (where x is the numerical order.)
Sample Value: /A “ServerName.Classname”
Note: The /A switch denotes it is loading an automation add-in *AND* unlike COM Add-ins, automation add-ins are loaded on demand so the LoadBehavior registry key is not necessary for these types of add-ins.
When an Automation Add-in that is listed in the Add-Ins dialog box is cleared, a subkey with a name equal to the Add-in’s Program ID is created in the following registry key:
This registry setting ensures that Automation Add-ins that you have added to the Add-ins list are retained in the list even when you have chosen not to load them. Both the Add-in Manager and OPENx registry settings need to be managed properly when virtualizing add-ins.
Caveats when Virtualizing Multiple Add-ins with App-V
When Excel loads these automation add-ins it will expect to see a ordinal series of OPEN entries in the registry (OPEN, OPEN1, OPEN2, OPEN3, etc.) If it is the first add-in to be installed, the registry value created will be “OPEN.” When the second add-in is installed, it will register “OPEN1.” The third add-in installed will then register “OPEN2” and . . . well, you get the idea.
So here is the problem that often arises: Let’s say you are virtualizing three Excel Add-ins separately and you want to link them with a virtualized Office package (or even linking local Office by pulling into an empty package and linking that with these three add-ins.) Chances are the first time you do this, you will fail – as the case with many of us.
If I sequence all of these add-ins separately and link them all with Office through a connection group, I have the following factors to consider with regards to these overlapping OPEN values:
- Registry opacity within the add-in package
- Resultant registry opacity upon Connection Group deployment
During sequencing, the normal behavior to determine default registry opacity goes as follows:
This of course, can be adjusted using the virtual registry tab within the sequencer. If you virtualize each add-in separately (which is normal) and add the add-ins into Excel with each sequence, you will find that each one appears as an OPEN registration. When you combine the add-ins together, you will likely find only one of the add-ins working upon first launch.
Another problem to avoid but one that is less likely to occur is to ensure that your OPEN registrations are in a direct sequence (OPEN, OPEN1, OPEN2, etc.) They have to be consecutive. If you have OPEN, OPEN3, OPEN5, etc. configured then you find Excel stops loading after the first one because OPEN2 is missing.
What I am Currently Doing
I take advantage of the knowledge of knowing that when you use Connection Groups, the number one entry in <appv:packages> section of the Connection Group XML descriptor document takes precedence. So if I were to employ a connection group that contained a local instance of Office, I would simply import a custom REG file containing the OPEN registrations in the correct order into an empty package (during sequencing) that also contains the shortcut extension points to the local Office applications. I then ensure that the empty package is at the top of the order within the Connection Group.
<appv:Package DisplayName=”Local Office” PackageId=”<GUID>” VersionID=”<GUID>”/>
<appv:Package DisplayName=”Add-in #1” PackageId=”<GUID>” VersionID=”<GUID>”/>
<appv:Package DisplayName=”Add-in #2” PackageId=”<GUID>” VersionID=”<GUID>”/>
<appv:Package DisplayName=”Add-in #3” PackageId=”<GUID>” VersionID=”<GUID>”/>
You have to ensure that the resultant virtual registry used by the parent Excel application has a correct OPEN sequence of registrations. You also have to ensure that the opacity will not conflict with any local registrations. Keeping these things in mind, I have the following recommendations when I am devising a add-in strategy for my customers.
Virtualize NO Excel automation add-ins.
Virtualize ALL Excel automation add-ins. Use Connection Groups to bridge a local or virtual Excel instance or package everything together if necessary,