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;
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:
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;
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;
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;
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;
Opening the file with PE Explorer or Resource Hacker reveals the below information regarding the OLMAPI32.dll file;
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;
The Office 2010 App-V Deployment Kit creates the following;
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.