App-V: Still More on Those Office Add-ins

As you can tell, I have been obsessed with Office Add-ins lately. Shifting gears from troubleshooting, I would like to address the different approaches to virtualizing add-ins with App-V. While the last two articles on the subject could easily be applied to both App-V 4.x and 5.x, my focus today will be specifically on App-V 5 because it offers more options and flexibility in the virtualization of add-ins. As I discuss each method, I will give my thoughts on the advantages and disadvantages of each method.

The Most Obvious: Sequence the Application and Add-in Together

While this method may seem to be the easiest, this method is only viable from a servicing standpoint if you:

• Have only one deployment of the application.
• In the case of Office, everybody will use the same group of Office applications.
• Everybody needs and/or is allowed access to the included add-in(s).
• For App-V 5, all add-ins will use the same COM settings inside the dynamic configuration files.

With this method, we do not likely run into issues with user state data and we do not have to involve any complicated sequencing recipes (other than the ones you would be using anyway – as the case with Office.)

Local Office Brought into Virtual Add-in Package during Sequencing

In this scenario, the add-in is totally virtualized but the parent application (Office App) is native. During sequencing, shortcut extension points were added to the package (dynamic configuration and FB0) so these shortcuts will launch inside the same virtual environment as the add-in. This scenario works best when there is a desire to keep the parent application native to the operating system.

 

The extension point format in the Deployment_Config.XML points to the local instance using a tokenized path. In the example below, here is a local shortcut extension point for Excel 2010 that is labeled as “Contoso Processing” because it will launch inside the virtual environment of the virtualized Contoso Processing add-in.

        <Extension Category=”AppV.Shortcut”>

          <Shortcut>

            <File>[{Start Menu}]Microsoft OfficeExcel (ContosoProcessing).lnk</File>

            <Target>[{ProgramFilesx86}]Microsoft OfficeOffice14excel.exe</Target>

            <Icon>[{ProgramFilesx86}]Microsoft OfficeOffice14excel.exe.0.ico</Icon>

            <Arguments />

            <WorkingDirectory>[{ProgramFilesx86}]Microsoft OfficeOffice14</WorkingDirectory>

            <ApplicationId>[{ProgramFilesx86}]Microsoft OfficeOffice14excel.exe</ApplicationId>

          </Shortcut>

        </Extension>

 

The problem you may run into when using this deals with user workflow. This particular shortcut will launch this specific instance of Excel, but a regular shortcut to the local Excel will only launch the native Excel (with whatever native Excel customizations are in place.) You will not be able to share user state across the two instances of Excel unless you leverage UE-V or another user state solution.

 

Local Office Brought into Virtual Environment using “On-the-Fly” Shortcut

Yes, it’s a long name, but it was the best I could come up with! What happens here is very similar to the previous method where the local/native installation of Office is brought into the virtual environment but not using an embedded shortcut. Instead, we are using an “on-the-fly” shortcut solution where the shortcut leverages the following syntax:

 

<AppName.EXE /appve:<GUID>_<GUID>

This is convenient and quick way to link a local application with a virtual plug-in or add-in. Before you jump to this option, understand there are a few potential issues that could arise. The first will be the provisioning and management of these “out-of-band” shortcuts. Delivery of these shortcuts would have to come outside of the normal publishing block. You also will have to modify these shortcuts whenever a package version has changed. Also user state, registry opacity, and other configuration-relation issues could arise as you have similar issues with this method as you did with the previous one if you are moving back and forth between a local instance and one that has been brought into the virtual environment of the add-in.

Virtual Office Linked with Virtual Package using a Connection Group.

With the introduction of Connection Groups in App-V 5, we now have more flexibility in linking different packages together into a single virtual environment. The most common way of using connection groups to link Office applications with Add-ins is to create one that links Office as a virtual application with the virtual add-in applications.

Once you introduce connection groups into the mix, the order of packages in the connection group is important. This is regardless of how you are deploying these groups (publishing server, configuration manager, or stand-alone.) The connection group order specifies the order in which registry and file system data of individual packages are merged. What this means if Office is first in the connection group and the Add-in package is second, the Office application will take precedence in terms of registry opacity.

Local Office Application Brought into Virtual Package Using Empty package/Connection Group Solution

This is very similar to the above scenario except the assets for the local Office applications are local.

 

In this scenario, Office is installed locally/natively but there is an empty virtual package that contains local shortcuts to the Office applications. This virtual package is linked with the virtual add-in package through a connection group. The ramifications are combined in that you may encounter workflow issues for users. Connection group order will also be important in terms of user state and registry opacity.

Local Office application brought into the Virtual Add-in Package using “Run Virtual”

If you are working within RDS environments, and have a package that is published globally, you can also take advantage of the “Run Virtual” feature. You basically add process executable names as subkeys of the following key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientRunVirtual

For example, if I have a locally installed application called MyApp.exe and I would like this application to run within the virtual environment, I would create a subkey called MyApp.exe (perhaps a helper application like Adobe Acrobat that may need to be called from a virtualized web application.) I would then put in as the default entry a REG_SZ value that contains the package GUID and the version GUID separated by an underscore (i.e. <GUID>_<GUID>.

If the package is a standalone package, the process will be launched in that package’s virtual environment. If the package is in a connection group, the process will be launched in the virtual environment of the connection group for which the package belongs.

 

 

 

 

App-V: More on that Failed Office Add-in

Continuing from my previous post a few days ago, let’s talk more about application errors when Office add-ins are virtualized. It is pretty easy to resolve most add-in issues with the right methodology. One of the first steps in my methodology is to first determine if the issue is related to the add-in loading or a general application error occurring after the add-in has loaded.

“First Launch Only” Issue or “Every Launch” Issue?

If you have isolated the problem to a load issue, now determine if the problem occurs on first application launch only or on every launch. If it is a first launch issue, the issue resides most likely with the package. If it is on every launch, the issue could be easily in the package or within the configuration and/or user state of the client machine. As mentioned in my previous blog post on the subject, the first place you want to check is the LoadBehavior key in the registry. After that I follow a basic process where on first launch issues, I eliminate LoadBehavior as an issue first, then I determine if registry opacity might be a factor. Registry opacity is where the virtual registry key is configured to either “merge” with the local key or “override” the local key.

If it is an issue that is occurring on all launches, I first eliminate user state as a potential culprit whether it is an incorrect configuration or corrupted configuration. I’ll repair the package first as well as eliminate any other elements related to user state management before I start actually digging into the package configuration.

If the add-in is still failing to load or function properly after loading then you may have to look to ensuring that you have done the basics of planning prior to virtualization. Time to back track a little:

Have We Verified Bitness?

Do we have matching bitness – (i.e. a 64-bit Office application requires a 64-bit COM add-in.) App-V does not change the fact that Office requires the add-ins to match the bitness of the office application. In other words, if you are using a 64-bit version of Office, you do not want to be loading 32-bit add-ins

Are you sure we aren’t missing requirements somewhere?

Have you confirmed that any pre-requisites or middleware required for the add-in have been either included in the add-in package or are installed locally on the client machine? I have been burned by this before. This is the most common reason why an add-in may actually “load” according to Office, but may actually still fail (by either crashing or giving a strange error.) Sometimes the application dependency may appear to be installed but may actually be partially installed. Let’s look at an example:

The Case of the Crashing Add-in

Now here is an interesting case: Let’s say the Office Add-in loads according to the Event Viewer, yet the Add-in still errors out. What is the best way to go about troubleshooting it? In the example below, a component called Cisco ViewMail for Outlook has failed to load in Outlook 2010. We initially get the following error:

‘VMOAddIn’ has fired an exception. Click the ‘Details’ button to see the detailed information about the error.

This error will contain details including a stack trace. This information may prove to be valuable later. This error is exactly what it says. It is not a load error – it is a handled exception or a crash. In this example, it is then followed by a more user-friendly message:

Cisco ViewMail encountered an error while starting and was not able to recover. ViewMail functionality is not available.

So when you get this error, the first thing you will want to do is take a look at the details of the crash. Based upon the error screen – this appears to be a managed code exception (.NET.) When you get these errors – look at these key elements:

Assembly Codebase: file:///Q:/Microsoft_Outlook_2010_V1/VFS/CSIDL_PROGRAM_FILES/Cisco Systems/ViewMail for Outlook/VMOLibrary.DLL

Assembly Full Name:    VMOLibrary, Version=9.0.2.1, Culture=neutral, PublicKeyToken=null

Assembly Version:      9.0.2.1

Exception Source:      VMOLibrary

Exception Type:  System.IO.FileNotFoundException

Exception Message:     Could not load file or assembly ‘Microsoft.DirectX.DirectSound, Version=1.0.2902.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

So in the case of the above error, we see something very straight forward: A missing file – Microsoft.DirectX.DirectSound. Looking at the list of installed programs and updates, I see that the DirectX components are indeed installed.

Know the Add-in

Before you troubleshoot further – it would probably be a good idea to have a known good installation (where the add-in is installed and working normally on a native installation.) I usually compare Process Monitor captures of the known good with a trace of the reproduced error. Before I even do this, though, I need to know what I will be looking for. In most cases with add-ins, there will be a loading of the add-in (usually a DLL) by a base executable (in this case, the Office application is Outlook so the EXE will be OUTLOOK.EXE.)

What are the EXE’s and DLL’s for ViewMail?

To get this information, I can either look at a local installation or I can open a command prompt in the bubble and browse the VFS. Once I know what these DLL’s are and where they are located, I can then proceed to weed through a Process Monitor capture of the failure. I first add a PATH filter in ProcMon using the CONTAINS operand and the use the keyword “ViewMail.” This takes my filter down from nearly 30,000 events down to 1,217 items. Next I look to add another filter. Since the error “Could not load file or assembly ‘Microsoft.DirectX.DirectSound” was in regards to a file or assembly, I now add an additional filter for the
operation “LoadImage.” This knocked the entries down to 29 events but EVERYONE OF THEM SHOWED SUCCESS!

Does this mean we are taking crazy pills? No, this just means you have eliminated the simple issue of a failure to load a DLL. The “file” aspect of that error has been eliminated. We are now simply chasing down a .NET assembly. So now we need to hone in on the codebase of the error – narrowing the context:

Assembly Codebase:    file:///Q:/Microsoft_Outlook_2010_V1/VFS/CSIDL_PROGRAM_FILES/Cisco Systems/ViewMail for Outlook/VMOLibrary.DLL

I’m going to go back to the Process Monitor capture and return to the point where the successful LoadImage operation of VMOLibrary.DLL occurred. I reset the filter from this point (making sure this selection remains highlighted.) Anything before this point is irrelevant. I begin to start walking down the trace, systematically eliminating irrelevant processes (right-clicking them and selecting “exclude” – BUT –  BE SURE YOU KNOW WHAT YOU ARE EXCLUDING IS IRRELEVANT.)

I walk through the loading of the file VMOLibrary.DLL until the result is END_OF_FILE which means the file has been completely loaded.  Continuing on in the trace, I notice it is now walking the .NET assembly registrations and finding begins to hit PATH_NOT_FOUND error and events start to occur where it begins to write to an error log. I take note of the assembly name in the error: ‘Microsoft.DirectX.DirectSound.’ It is as if it thinks that the DirectSound component of DirectX is not installed – but I verified it was installed prior to troubleshooting. However, I go to the C:WindowsAssemblies folder and sure enough, it is not there.

How did I know to look there?

Activity to this special folder (C:Windows Assemblies) involves looking for actual activity going to the .NET Global Assembly Cache (GAC.) When looking at Process Monitor traces, all activity  in the Global Assembly Cache is logged by direct path in ProcMon as

• C:WINNTassemblyGAC_MSIL
• C:WINNTassemblyGAC
• C:WINNTassemblyGAC_32

So the problem we had was that while DirectX was installed, the proper .NET DirectX assemblies were not registered in the GAC. Now if this ever happens you want to make sure the binaries for the DirectX managed Code components are there. In this case – the files were actually in C:WINNTMicrosoft.NETDirectX
for Managed Code1.0.2902.0 BUT they were not actually registered to the GAC. If the files were not even on the machine – a reinstallation of DirectX is in order (plus updates.) If the files are there but not registered in the global assembly cache then you could leverage REGASM:

REGASM.exe – http://msdn.microsoft.com/en-us/library/tzat5yw6.aspx

And register those assemblies manually – my recommendation would be to simplify things and just reinstall DirectX. Then you will see the assemblies properly registered.

 

 

NOTE: Unregistered assemblies may not show up in a DXDiag report but the .NET assemblies inventory for DirectX is part of the output as demonstrated with a before and after comparison using BeyondCompare.