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_MACHINE\SOFTWARE\Microsoft\Office\14.0\CVH
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.