Virtualized Office 2010 and Extended MAPI

In the forums there are a couple of threads which state that using the Send file via default mail-client fails in certain instances (most commonly when using any Adobe software) when using a virtual Outlook with the Office Deployment-kit.
In short, they open their application (Adobe Reader) and choose  a menu which allows them to directly forward their document to a new e-mail (click the letter in Adobe Reader available from the toolbar). Most commonly this fails with an error stating that there is no default mail client (and sometimes afterwards a more obscure error)

The below article explains MAPI and is quite useful;
http://support.microsoft.com/kb/315458
Which under #3 states the following;

3.It then looks under the client’s key to find the path of the correct DLL to load. If the function is a Simple MAPI function, it loads the DLL specified by the DllPath value, and then calls the function. If the function is an Extended MAPI function, it loads the DLL specified by the DllPathEx value. After finding the appropriate DLL, it then calls the function.

 

In the case of Microsoft Outlook, for example, it looks for the value of DLLPath or DLLPathEx under the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Microsoft Outlook

Reviewing a procmon log to see what the application does – the following was found;
Within %TEMP% there are two log-files for the Mail proxy;
MapiProxyServer.log
MapiProxyClient.4916.log

Its nice to know there are log files for troubleshooting- they don’t tell us a whole lot about the behavior currently under investigation though and will only show if the proxy is initiated. Adobe Reader (in this case) fails before the proxy is actually used – so the two log-files were only located during a successful attempt to kick-start the proxy (right-click a file and choose send-to).

The following is being accessed by Adobe Reader while invoking the action to send an e-mail;

image

Considering the above statement this tells us;
1. Adobe Reader uses an Extended MAPI function
2. That’s not supported when using a virtual Outlook with the Office deployment kit since DLLPathEx isn’t created when using the kit

The Process Monitor capture above shows us that there are several registry keys and files that are traversed – to understand the flow the previously mentioned KB-article can be used to decipher why certain things are accessed in the very specfic.

First of all – if one of the below functions are used;
◦MAPIAddress
◦MAPIDeleteMail
◦MAPIDetails
◦MAPIFindNext
◦MAPIFreeBuffer
◦MAPILogoff
◦MAPILogon
◦MAPIReadMail
◦MAPIResolveName
◦MAPISaveMail
◦MAPISendDocuments
◦MAPISendMail

Its called Simple MAPI and the registry value DLLPath is used to locate the default main client. This seems to correspond to the most commonly used parts of the mail-client, however if any other function is used – DLLPathEx is lookedup to find the extended MAPI. Read more about MAPI from Microsoft in the article Differences between CDO, Simply MAPI and Extended Mapi.  If the lookup fails for the above registry value needed – a search for mapi32x.dll is started. Mapi32x.dll is a fallback and quite often not available at all on  a system. If you program starts searching for this – it means something has most likely failed.

Last stop is to present the user with a message that there is no mail-client – defined therefore it will check the PreFirstRun-key (perhaps you have a mail-client, buts its not setup?) or the NoMailClient for the corresponding message to present the users.

If reviewing a package containg a copy of Outlook – the keys looks like this;

image

Opening the file with PE Explorer or Resource Hacker reveals the below information regarding the OLMAPI32.dll file;

image

It seems that the file originated from MAPI32.dll – however offering an upgraded set of functionality.

Traversing the registry and comparing what Office 2010 layed down under the HKLM\Software\Clients key and what the Office 2010 Deployment Kit layed down showed some staggering limitations. A native install creates the following;

image

The Office 2010 App-V Deployment Kit creates the following;

image

We have 1 proxy with the deployment kit and 4 when using a native install. The MAPI, as we now know, is not complete either.

Threads;

http://social.technet.microsoft.com/Forums/en-US/appvgeneralsequencing/thread/0df815ae-19d6-4a2a-b028-b636952c91c9

http://social.technet.microsoft.com/Forums/en-US/appvgeneralsequencing/thread/8b028304-866d-4288-89df-01fd81e56b3e

http://social.technet.microsoft.com/Forums/en-US/appvgeneralsequencing/thread/149602b4-f894-4955-8b0e-fc7bff56e65e

http://social.technet.microsoft.com/Forums/en-US/appvclients/thread/a0f6e9ac-d3f7-4c86-831c-f93daee11511

2 thoughts on “Virtualized Office 2010 and Extended MAPI

  1. Virtual Evanagelist Reply

    This article has some great info but I am struggling to find the solution exactly for a virtual Adobe Reader needing to use the send to mail function, same with the virtual IE to Outlook function. Did you find a solution?

    • nickekallen Post authorReply

      The article in itself is only about Virtual Office, and not a Virtual Adobe Reader. I suggest you check the forums online for information

Leave a Reply

Your email address will not be published. Required fields are marked *