App-V: On Virtualizing Multiple Excel Add-ins

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 3^rd-party applications) and Excel Add-ins or what we refer to technically as Automation Add-ins (VSTO, XLAM add-ins.)

 

COM 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:

HKEY_CURRENT_USERSoftwareMicrosoftOfficeExcelAddins

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

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:

Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice<VERSION>ExcelOptions

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:

HKEY_CURRENT_USERSoftwareMicrosoft<VERSION>ExcelAdd-in Manager

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:Packages>

  <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>”/>

</appv:Packages>

 

 

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.

-or-

Virtualize ALL Excel automation add-ins. Use Connection Groups to bridge a local or virtual Excel instance or package everything together if necessary,

 

 

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.

App-V: On that Failed Office Add-in

Troubleshooting virtualized Office add-ins are always fun. Correction: troubleshooting Office add-ins are always fun for people like me – not necessarily normal human beings. Whether you are using add-ins with a local instance of Office or are packaging add-ins with virtualized Office, you need to be to understand how Office knows which add-ins to load and how these will be loaded.

There are generally three ways to virtualize add-ins for Office:

1.)    Where Office is installed locally and the Add-in is virtualized – The Office application must have a shortcut/OSD file provisioned in order to be brought into the virtual environment. Starting with App-V 4.6 SP2, the App-V Sequencer has a specific workflow that allows for this.

Be advised that when you do this, you will be bringing in the local instance of Office into the virtual environment in order to load the add-in. What this can lead to is other add-ins which may not be virtualized not loading if the configuration is not set properly for this. Having a clear understanding of your Office add-in ecosystem will help in developing a strategy in advance to avoid this.

2.)    Through Connection Groups or Dynamic Suite Composition (Depending on the Version) –  You can also take advantage of both the Add-in/Plug-in workflow and the “Expand Package to Local Disk” feature of the sequencer in order to package Office and Add-in applications separately but still connect them into a common virtual environment.

This method works best (in my opinion) when your strategy is to virtualize both Office and the add-ins. This is also the only way I use Add-ins with Office 2013.

3.)    Office and add-ins packaged together into one package (often sequenced using a single pass.) This way is the least common and not always recommended as it may require you to deploy multiple Office packages.

Verify the Add-in Registry Keys

When an add-in is installed, it can be registered to either the user or to the whole machine. When an add-in is sequenced, it will also be virtualized and depending on the registry opacity configuration, will override whatever is locally present. User-registered add-ins go to HKEY_CURRENT_USER while add-ins registered to the entire machine go to HKEY_LOCAL_MACHINE. Whether Office is local and being brought into the virtual environment or Office is virtualized with the Add-in, Office needs to be able to understand the “Load Behavior” of the add-in. This will be found under

HKEY_LOCAL_MACHINESoftwareMicrosoftOffice<APPLICATION>Addins

Each Add-in appears as a subkey beneath this key. The LoadBehavior DWORD value determines how it will load. This key is the #1 culprit when it comes to Add-ins not working right whether it is a “1^st launch-only” issue or an “always-launch” issue. It is a DWORD value. By default, this entry is set to 3, which specifies that the add-in is loaded at startup but an many cases, especially if the add-in was launched during sequencing, you may run into a situation where the value may be set to something else depending on what was done during sequencing. If the value is 0, then the add-in will have to be enabled once the user launches the application. If the package is repaired it will have to be enabled again. The value 1 can be misleading and I encounter this a lot in virtual add-in troubleshooting. Add-ins dialog box indicates that the add-in is loaded after the application starts, the add-in isn’t actually loaded. If the application successfully loads the add-in, the LoadBehavior value changes to 0, and remains at 0 after the application closes. The value 2 means If the application successfully loads the add-in, the LoadBehavior value changes to 3, and remains at 3 after the application closes. With App-V this means potential issues in prompts including annoying “success messages.”

LoadBehavior at 3 is good for App-V

Hey, I made a rhyme!  If the LoadBehavior value is set to 3, it will always try to load the add-in and if the add-in fails, will set it back to 2. This is what we want in the virtual registry of our App-V package most of the time. You can usually verify/set this in the Virtual Registry tab after sequencing prior to saving the package.

Should I Verify Registry Opacity?

Yes. While you are there you may want to verify your registry opacity settings. Are those Add-in keys set to “override” or “merge” with the local key. If you have local add-ins that you will use alongside of these virtual add-ins, you will want to ensure that the Addin key is set to merge.

What about Outlook Add-Ins?

For Outlook, you will most assuredly need to manually import/add these virtual registry entries during sequencing (or package upgrade) since you do not want to be launching Outlook during sequencing.

Check the Event Logs when Troubleshooting

While the event logs may not have the event handlers registered for office (since it is virtual, you will still see unregistered event ID’s of Outlook (Event ID 45) which will list all of the add-ins loaded and their subsequent load times.

Event ID: 45

Outlook loaded the following add-in(s)

Office 2013 and Mismatched Virtual Subsystem Settings

If you are using Virtual Office 2013 with App-V 5, this is the #1 issue. Given all of the changes with Office 2013 virtualization, one would think the Add-in story would become complicated. It is not. The recommended practices are pretty straight-forward:

On the Sequencing Machine:

1.)    Install the App-V 5 Sequencer.

2.)    Install Office 2013.

3.)    Start a new package.

4.)    On the “Type of Application” page, select “Add-on or Plug-in.”

5.)    Select the installer for the plugin.

6.)    In the “Install Primary” page, select “I have installed the primary parent program” and continue.

7.)    Install the plugin and save the package.

8.)    Depending on the add-in, you may need to run it during sequencing.

 

Client Configuration

1.)    Copy your Office 2013 to the client machine

2.)    Copy the sequenced add-in to the client machine

3.)    Modify the add-in’s DeploymentConfig.xml file and modify the following:

4.)    Search for:

“<COM Mode=”Isolated”>”

modify to

“<COM Mode=”Integrated”>”

5.)    Search for:

“<Objects Enabled=”true” />”

modify to

“<Objects Enabled=”false” />”

The Connection Group will fail if the above changes are not made.

6.)    Build a Connection Group document for both Office 2013 and the Add-In. You can do this with stand-alone testing by using the following resource on creating a Connection Group XML document: http://technet.microsoft.com/en-us/library/jj713474.aspx

7.)    Enable Package Scripts

Set-AppvClientConfiguration -EnablePackageScripts 1

8.)    Add the Office 2013 package; publish it Globally

Add-AppvClientPackage –path <path_to_office_package_>.APPV | Publish-AppvClientPackage –Global

9.)    Add the Add-In package; publish it Global

Add-AppvClientPackage –path <path_to_office_addin>.APPV | Publish-AppvClientPackage –Global

10.) Add the Connection Group pointing to the Connection Group document you created earlier. Enable it Globally

Add-AppvClientConnectionGroup –path <PATH_TO_CG_DOC>.xml |Enable-AppvClientConnectionGroup –Global

 11.) Launch the Office application the add-in uses.

 

App-V 4.6: Troubleshooting A09 Errors (04-00000A09) with Office Deployment Kit Proxies

One touchy feature that has frustrated packagers has been the issues arising when the ODK (Office Deployment Kit) proxies are not configured properly. When this happens, search will not properly work, MAPI configuration will not work properly, and even headaches with “Mail” Control Panel. The erro displayed is very quick and very terse.

The Application Virtualization Client could not launch the application you requested.

The specified application does not exist. Check the name you specified, and then try again.

Error code: xxxxxxx-xxxxxx04-00000A09

The error is pretty straight-forward. The App-V client went to launch an application using the SFTTRAY command, and it does not match anything published on the client – but you know it’s there, right? You checked. The OSD matches. Even launching the OSD manually with the SFTTRAY works. So what in the heck is going on?

4.6 Proxies – Trail of Consistency

 

 

 

By design, what you specify during the deployment of the ODK (Office Deployment Kit) is extremely important in the automation and integration of these proxies, or virtualization handlers as they are more appropriately called. When you are sequencing Office 2010 and deploying via App-V, you have to also deploy the virtualization handlers using the Office Deployment Kit. As you can see from the diagram above, the command to call the virtual application (in this case – the mail search) will be constructed based upon two options specified when deploying the Office Deployment Kit – PACKAGEVERSION and the name of the Proxy (i.e. MAPIPROXY, MLCFG32CPL, etc.) In the case of the mail search, it is VIRTUALSEARCHHOST. This information is mentioned deep inside the Prescriptive Guidance document, but is often overlooked. What is not mentioned is that these will be registered locally in the following key: HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CVH

In the case of the Virtual Search Host, a subkey called Click2runWDSProxy should exist with an entry for the Package GUID in {GUID} format followed by the SFTTRAY command to launch the application.

So let’s say you install the Office Deployment Kit using the following parameters:

ADDDEFAULT=Click2runMapi,Click2runWDSProxy,Click2runWDS,Click2runOutlookProxies,OSpp,OSpp_Core,Click2runOWSSuppProxies PROPLUS=1 OUTLOOK=1 KMSSERVICENAME=booger.contoso.com OUTLOOKNAME=”Microsoft Outlook 2010″ PACKAGEVERSION=”14.0.6025.1000″ PACKAGEGUID=”{GUID}” MAPISERVER=”Microsoft Virtual Office Simple Mapi Proxy Server” VIRTUALSEARCHHOST=”Search MAPI Protocol Handler Host” MLCFG32CPL=”Mail” OWSSUPPServer=”Microsoft SharePoint Client Support Manager” 

The Office Deployment Kit will have the expectation that the following will be configured during sequencing:

Option	Application Name	OSD File
MAPISERVER	Microsoft Virtual Office Simple Mapi Proxy Server 14.0.6025.1000	Microsoft Virtual Office Simple Mapi Proxy Server 14.0.6025.1000.osd
VIRTUALSEARCHHOST	Search MAPI Protocol Handler Host 14.0.6025.1000	Search MAPI Protocol Handler Host 14.0.6025.1000.osd
OWSSUPPServer	Microsoft SharePoint Client Support Manager 14.0.6025.1000	Microsoft SharePoint Client Support Manager 14.0.6025.1000.osd
MLCFG32CPL	Mail 14.0.6025.1000	Mail 14.0.6025.1000.osd

 

If you leave out the PACKAGEVERSION option, that’s bad. That will add an additional trailing space to the constructed SFTTRAY command. Even if you include the version in the name, leaving out the PACKAGEVERSION option still causes this. This means you will need to make sure all of the versions specified in the application names (created during sequencing) are identical so the right virtual application will then be launched and you can avoid those A09 errors.

 

App-V: Adding Additional Languages to Office 2010 Packages (. . . and pre-setting the Outlook Default Language)

Here is the scenario: You have gone through the trouble of sequencing Office 2010 with either 4.6 or 5.0 and you have it working like a champ. You then get a call. “We need this also deployed for our users in <FILL_IN_THE_BLANK_NATION_THAT_REQUIRES A DOUBLE BYTE CHARACTER SET>. Did I mention we need it by the end of the week [It is Thursday, by the way.]

Don’t panic. Adding an additional language pack is a pretty straight forward process as long as the sequencing workstation is set up properly in advance. You will also have to do some additional tweaking to get yourself out of a “chicken/egg” scenario if you want the “Outlook Startup” to now be in a different localized language. Since we cannot open up Outlook to change the default input and display languages, this will need to be applied through registry imports.

Enabling OS Language Support on the Sequencer

First Add the OS Language Support on the Sequencer. This can be done easily using the “Region and Language” Control Panel in Windows 7

For more specific information on how to change/add languages in Windows 7, please refer to this link: http://windows.microsoft.com/en-US/windows7/Add-or-change-an-input-language

 

With Windows 8 this is done in the “Language Control Panel.”

 

For more information on how to change/add languages in Windows 8, please refer here: http://support.microsoft.com/kb/2607607

Office 2010 Language Files

Now you will need the supporting language files for Office 2010. This will require you have the files at the ready on or attached to the sequencer as well as the locale XML configuration file. You will then re-run setup with the /config switch pointing to the locale configuration file. For example, if you were applying the Japanese language support files to the existing office package you would only need the *.ja-jp directories and the ja-jp.xml file.

 

Custom Registrations

Outlook Display Language, Help Language, and Editing Language changes can either occur after the user has run Outlook in the default English (and makes the modifications post deployment) or before the fact. In this particular scenario, you already have a virtualized office package that was English-only. If you desire that the automatic startup language for existing and new Outlook profiles be already configured to default to another language for the display, help, and editing language, you will need to include some custom registrations in order to change the language. You will first need to know the decimal and hex equivalents of the LCID structure. You can look those up using the following reference:

http://msdn.microsoft.com/en-us/library/cc233968.aspx

For example, English is 0x409 in hex (1033 in decimal.) if you were wanting use Japanese instead, it would be 0x411 (or 1041 in decimal.)  You will then need to ensure that the following registry keys are set to that specific LCID during sequencing:

• Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0Outlook
  Value: LastUILanguage
  Data Type: REG_DWORD
  Data (hex): <LCID Code in Hex>
• Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0OutlookOptionsGeneral
  Value: LastUILang
  Data Type: REG_DWORD
  Data (hex): <LCID Code in Hex>
• Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonLanguageResources
  Value: UILanguage
  Data Type: REG_DWORD
  Data (hex): <LCID Code in Hex>
• Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonLanguageResources
  HelpLanguage
  Data Type: REG_DWORD
  Data (hex): <LCID Code in Hex>
• Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonLanguageResources
  InstallLanguage
  Data Type: REG_DWORD
  Data (hex): <LCID Code in Hex>
• Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonLanguageResources
  OutlookChangeInstallLanguage
  Data Type: REG_SZ
  Data: Yes
• Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonLanguageResources
  Value: FollowSystemUI
  Data Type: REG_SZ
  Data: Off

Procedure for Modifying Sequence

Whether you are using App-V 4.6 or 5.0, the process is the same. You will need to open the existing application virtualization package using the procedure to “Add new application.”

This will invoke the monitoring phase. During monitoring, you will need to first run the command to add in the language files. For example, if you were to add support for the Japanese language files, you would type the following command:

setup.exe” /config ja-jp.xml

 

This would then install the native Japanese language files for office 2010.

Following that, you would need to add in the registrations. What I usually do is put all of them into a REG file and import them from the command prompt during sequencing. For example, if I were to import defaults for the Japanese language interface, I would import the reg file below:

Windows Registry Editor Version 5.00

 

[HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0Outlook]

“LastUILanguage”=dword:00000411

 

[HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0OutlookOptionsGeneral]

“LastUILang”=dword:00000411

 

[HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonLanguageResources]

“UISnapshot”=hex(7):31,00,30,00,33,00,33,00,3b,00,31,00,30,00,34,00,31,00,00,

  00

“UIFallback”=hex(7):31,00,30,00,34,00,31,00,3b,00,30,00,3b,00,31,00,30,00,33,

  00,33,00,00,00

“HelpFallback”=hex(7):31,00,30,00,34,00,31,00,3b,00,30,00,3b,00,31,00,30,00,33,

  00,33,00,00,00

“UILanguage”=dword:00000411

“HelpLanguage”=dword:00000411

“InstallLanguage”=dword:00000411

“OutlookChangeInstallLanguage”=”YES”

“FollowSystemUI”=”Off”

 

Upon completion of these two procedures, I would then save the package and proceed to test.

 

The Case of the Three Second Delay (a.k.a What is SFTDDE?)

A while back I encountered an issue that forced me to become introduced to the DDE Launcher used by App-V (SFTDDE.)  A customer was encountering an issue where, no matter how much they tuned their terminal servers, even with pre-cached virtual applications; Office applications appeared to always have a three second delay when they double-clicked on an Office document associated with a virtualized instance of Office. Regular launches of these applications (from the shortcut) did not encounter this delay.

What is DDE?

DDE (Dynamic Data Exchange) is one of the oldest IPC (Interprocess Communication) mechanisms in Windows. Since it relies on using the Windows message layer for functionality it still works even though it has been superceded by many far superior technologies. The factor involved in this particular App-V scenario is whether DDE (Dynamic Data Exchange) has been enabled for the application. The main difference between double-clicking a document or launching the application then loading the document when DDE is enabled is that SFTDDE.EXE is used as a DDE launcher instead of SFTTRAY.EXE.

Investigating the customer’s issue found that there was indeed a three-second delay and a Process Monitor trace revealed it:

Double-clicking and triggering the SFTDDE.EXE process:

0              7:47:03.3683129 AM        sftdde.exe          848         Process Start                      SUCCESS              Parent PID: 2844

Then the SFTTRAY Start:

3007       7:47:06.1107902 AM        sfttray.exe          3408       Process Start                      SUCCESS              Parent PID: 848

By default in App-V when sequencing Office, DDE is enabled. When setting up a file type association that requires DDE support, the client uses a DDE Launcher command. It pulls the command based on the value specified in the following registry location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\UserInterface

Value: DDELaunchCommand

The default value is “C:\Program Files\Microsoft Application Virtualization Client\sftdde.exe” “<APP>” <DDE>

If present, the strings <APP> and <DDE> will be replaced with the app’s name and version and the DDE app name, respectively.

When virtualizing Office with App-V, the sequencer enables DDE functionality by using the SFTDDE launcher for each application. One important item to consider is that when double-clicking on a file where the association is with SFTDDE rather than SFTTRAY, App-V will act as a DDE client and sends DDE message broadcast to all open windows. If an instance of word is open, then it will reply back and that instance of WinWord will open the file – regardless of the version of the winword.exe process running.  If not, it will trigger the SFTRAY command to launch.

Is this why my Custom File Type Associations Don’t Work Sometimes?

Yes. This explains why in some cases you may have a local or virtualized instance of Microsoft Word 2003 running side by side with Microsoft Word 2010 running local or virtualized. Let’s say you have the .DOC extension associated with Microsoft Word 2003 and the .DOCX extension is associated with Microsoft Word 2010. If Microsoft Word 2010 is currently running and you double-click on .DOC file, it will still open in the existing Winword.exe process (which in this case would be Microsoft Word 2010.)

Why sometimes a delay?

The delay occurs when there is one or more hung top-level windows on the system. When using ShellExecute or ShellExecuteEx to open a document in its associated application and the file is registered to use DDE, the shell will first try to establish a DDE conversation with a running instance of the application by broadcasting a DDE initiation message to all top-level windows.

The DDE initiation message is broadcasted by calling SendMessageTimeout with a 3 second timeout. When there is a hung top-level window when the DDE message is sent, SendMessageTimeout will be blocked until the message is handled by the hung window or the timeout expires. Once the timeout expires, the shell will launch the application associated with the document.

Should I remove this?

For Office, it would be a bad idea. Every trigger of a document double-click will spawn an SFTTRAY launch of the Office application chosen. I have had many customers remove the DDE section, and have %1 as the only option. The DDE message broadcast does not happen and a new instance of the application opens the file. Eventually they restore the functionality and live with the DDE delay.

Steve Thomas

App-V: Unable to click “Join Meeting” from Virtualized Outlook when Live Meeting 2007 is Installed Locally

If you have virtualized MS Office and have decided to use a local installation of Live Meeting, you may run into this issue. When a user attempts to click on a Live Meeting link (click on “Join Meeting” link) within a virtualized Office application (primarily Outlook) to join the Live Meeting session, they may get the following error:

Failed to initialize critical resources!

Make sure you have all languages installed.

This was caused by the Office application process not having Read permissions as part of the sequencing to the following directory:

 %PROGRAMFILES%\Microsoft Office\Live Meeting 8\Console

If Live Meeting is not going to be included with the package, it will need to at least be installed on the sequencing machine in order to correct this in advance otherwise, you will need to enable the <LOCAL_INTERACTION_ALLOWED> tag in the OSD and ensure the directory “Live meeting” does not exist.

App-V: Important App-V/Softgrid KB’s and Documentation Links

Office 2010 Sequencing

http://support.microsoft.com/kb/983462

Office 2007 Sequencing

http://support.microsoft.com/kb/939796

Problems Sequencing Office 2007

http://support.microsoft.com/kb/931914

Information about how to use Office 2010 suites and programs on a computer that is running another version of Office

http://support.microsoft.com/kb/2121447

Issues Sequencing Office 2010

http://support.microsoft.com/kb/2481474

Server Command Line Installers Options

http://support.microsoft.com/kb/2384955

Troubleshooting w/ Process Monitor

http://support.microsoft.com/kb/939896

Introduction To Softgrid Networking

http://support.microsoft.com/kb/932017

App-V White Paper Portal

http://technet.microsoft.com/en-us/appvirtualization/cc843994.aspx

App-V Technet Documentation

http://technet.microsoft.com/en-us/library/cc843848.aspx

App-V Blog

http://blogs.technet.com/appv

Top 5 App-V SQL KBs:

25119 Upgrade Issue

http://support.microsoft.com/kb/976641

Moving 4.1 Databases

http://support.microsoft.com/kb/932136

App-V Server fails to start when SQL is on the same machine

http://support.microsoft.com/kb/959459

Concurrent Licenses

http://support.microsoft.com/kb/2447513

MWS Administrative Issue

http://support.microsoft.com/kb/930564

App-V: Description of Feature Flags When Configuring the Office 2010 Deployment Kit for App-V

For the Feature Flags that come with the Office Deployment Kit, customers may have questions as to what feature options under ADDLOCAL and ADDDEFAULT align with the specific feature.When you deploy to the sequencer, we are determining what elements will be bypassed and leveraged by the handlers during the sequencing process

32-bit:

ADDLOCAL=Click2runMapi,Click2runOWSSupp,Click2runWDS,OSpp,OSpp_Core

64-bit:

ADDLOCAL=Click2runMapi,Click2runOWSSupp,Click2runWDS,OSpp,OSpp_Core,OSppWoW64

The options here:

• Click2runMapi: For MAPI Overrides 
• Click2runOWSSupp: Microsoft SharePoint Client Support 
• Click2runWDS: Search MAPI Protocol Handler and Host Search MAPI Protocol Handler Manager Overrides. This allows for Fast Search in Outlook 
• OSpp: Microsoft KMS Client. 
• OSpp_Core: Office Software Protection Platform
• OSppWoW64: Microsoft KMS Client for x64.

Then on the client, we deploy the handlers which place in the host-side handlers. This will expose the proxies.

ADDDEFAULT=Click2runOneNoteProxy,Click2runOutlookProxies,Click2runWDSProxy,Click2runOWSSuppProxies

• Click2runOneNoteProxy: Send to OneNote printer Proxy
• Click2runOutlookProxies: All MAPI and Mail control panel applet 
• Click2runWDSProxy: Search Proxy and Office Document indexing 
• Click2runOWSSuppProxies: Sharepoint Client