LiquidFiles Outlook Plugin
The Outlook plugin will enable you to send files from Microsoft Outlook 2007-2013. As of beta 2.0.60, Outlook 2016 is also supported.
Topic is closed for comments. Please open a Support Ticket with us to ask questions or provide feedback.
New: Support for Outlook 2016
As of 2.0.67, stable version of Outlook plugin is fully compatible with Outlook 2016 (part of Office 365 suite).
New: end of support for Outlook 2007
Extended support for Outlook 2007 will be discontinued by Microsoft on 10/10/2017. While our plugin is built to be compatible with Outlook 2007, as of June 2016 (version 2.0.67) we no longer test the release version with Outlook 2007. If you are using Outlook 2007 in your organization, we encourage you to beta test the plugins before deploying them. Please contact us for more information.
End of support for Windows XP and Outlook 2003
As Microsoft's extended support for Outlook 2003 and Windows XP ended on April 8, 2014, we have deprecated support for Outlook 2003 as of version 2.0.44. We also discontinued support for Windows XP in setup executable files. While MSI files may execute fine under XP, EXE files will not. If you are still using Outlook 2003 or Windows XP in your organization, please contact us and we'll try to arrange custom solution.
- LiquidFiles virtual appliance v2.0 or later.
- Windows Vista or later
- .NET v4 or higher
- Microsoft Outlook 2007-2016
Outlook plugin will pop up a window asking credentials on first attempt to secure-attach file.
How to select proper version to install:
- Add-in comes in two variants: _Admin_, to be installed per-machine, and _User_, to be installed to roaming user's profile. These are two different applications, and they may come in conflict as each will expose its own user interface. So, only one of them should be installed.
- If you install by downloading the file to the computer and launching it through Windows/Explorer/Shell/command prompt, please use EXE version of setup as it will ask for elevated permissions if necessary.
- If you push setup by GPO, please use MSI. IMPORTANT: do not launch MSI to install Admin version from command prompt, it may result in lack of elevated permissions and therefore plugin will not install properly. Use EXE file instead.
- As of version 2.0.10, both _USER_ and _ADMIN_ packages contain Windows Agent setup.
- As of version 2.0.10, VC++ runtime is no longer required or redistributed with the setup packages. You only need to install VC++ runtime when you are using Exchange server with Outlook 2003, which is now considered a rare scenario.
- As of version 2.0.44, Outlook 2003 is no longer supported.
- As of version 2.0.67, we no longer test plugin with Outlook 2007.
You should run normal installation (launching MSI or EXE file). Starting with 2.0.51, patches which can be deployed by copying new executable files over previous versions are marked as such.
Starting with 2.0.29, you can deploy registry policies by specifying /qn REGKEYSCRIPT parameter to MSI, passing semicolon-separated key/value pairs to command line, such as:
msiexec /i liquidfiles.msi /qn REGKEYSCRIPT="AutoSignInServiceUrl=http://lfauthproxy.yourcompany.com/getapikey.ashx;BaseUrl=https://filetransfer.yourcompany.com"
Using proxy server
By default, both LiquidFiles Outlook Plugin and LiquidFiles Windows Agent use .NET's default proxy, which is what IE uses. So basically as long as you can reach LiquidFiles server with IE, Windows components should work, too. However there`s a problem with authentication. By default, .NET does not use Windows authentication for proxy servers.
To enable that for all .NET applications (not just for LiquidFiles), you need to change machine.config under both
Add or modify <system.net> section. If it does not exist, insert it at the end of config file but before closing </configuration> xml tag:
It is also possible to specify non-default credentials, but that would require non-trivial steps: http://stackoverflow.com/questions/186800/is-it-possible-to-specify-proxy-credentials-in-your-web-config
If you do not want to apply this change to all .NET applications, you need to change or create config files for the individual executable files:
- LiquidFilesCLI.Windows.exe (or older LiquidFilesCLI.exe)
- Outlook.exe (in its own folder). Plugins do not have their config files, and configuration files exist only at executable level. NOTE: you only need to update configuration of outlook.exe if you do not use LiquidFilesWindowsAgent. By default, connections are made through LiquidFilesWindowsAgent, but Outlook plugin will use self-hosted transfer engine if it cannot reach LiquidFilesWindowsAgent due to misconfiguration of named pipes.
For each of those files, locate appropriate .exe.config file (create it if it does not exist) and insert/update the <system.net> configuration setting as above. If config does not exist, use this template for default config file:
Starting with version 2.0.63, it will also be possible to read non-default configuration from a config file, by specifying path to that file by registry policy ProxyConfigFilePath. However the recommended way to handle this situation is to modify LiquidFilesWindowsAgent.exe.config (and/or configuration files of CLI applications) and make sure that connections are made through LiquidFilesWindowsAgent, or to tweak machine.config file. As of today, there's no official support with .NET for reading default proxy configuration from non-default configuration files, and there's no support to turn on default authentication at runtime either.
Therefore, the best solution would be to either tweak machine.config or change individual config files.
Limited support for Single sign-on (SSO)
At this moment, single sign-on through browser interface is not supported. You can configure LiquidFiles Authentication Proxy to provide seamless, automatic and silent authentication of Windows Agent and Outlook plugin in LiquidFiles. LiquidFiles Authentication Proxy is Microsoft IIS application and needs to be run using Integrated Windows Authentication. Please see the Windows Auth Proxy Documenation for more informationm.
msiexec /q /i LiquidFiles_Admin_2.0.53.msi /l* c:\temp\Liquidinstall.log
Selecting Admin or User version
When in doubt, use Admin version. Admin version will be installed per machine, so all users sharing same computer will use it. If computer is not shared (e.g., laptop computer), it works alright, too. Basically you need to use User version if you cannot install Admin version due to security policies or compatibility issues, if you have roaming user profiles and want to control which users are going to have plugin and which won't, or if you want user to be able to control his software. (user will not be able to enable/disable plugin if it's installed through Admin setup, because users without administrative permissions cannot alter per-machine configuration), or have similar concerns.
- When installing _Admin_ version of plugin, use EXE file to install from user interface/command prompts, and MSI plugin only for GPO setups. We have confirmed that launching MSI alone will result in running setup package under non-elevated permissions, therefore installation will fail.
- Version 2.0.40 provides support for Inline Responses (Outlook 2013 and higher versions) but Outlook may ask to 'save' drafts when closing Outlook if it's used. Also, version 2.0.40 would force Inline Response to be displayed in popup window when processing upload. Both issues are completely fixed with beta 2.0.72
- LiquidFiles does not intercept "Send to ... Mail recipient" command from Windows Explorer
(and with similar APIs). As of version 2.0.72, there is limited support for this scenario. LiquidFiles plugin will eventually process attachment when it has command over Outlook window.
However, if you attempt this command on a very large file, MAPI policies will prevent file from being sent before Outlook Plugin has a chance to intercept the action. So the only way to allow sending very large files through LiquidFiles is to adjust Exchange policies and allow very large files to be attached in Outlook.
Problems on/after install?
Besides Windows event log, the first place to check is "Add-in Express" folder under "My Documents" folder of the user who's been installing setup package (both _user_ and _admin_ versions).
|adxregistrator.log||Log of install/uninstall process (add-in only). Can be shared between several add-ins.|
|adxloader.log||Log of add-in loading process. Can be shared between several add-ins.|
|LiquidFilesOLPlugin.log||Log file of LiquidFiles Outlook plug-in|
|LiquidFilesWindowsAgent.log||Log file of LiquidFiles Windows agent|
If in doubt, please zip contents of that folder and send us the logs through filing support ticket.
Re-enabling the plugin
On occasion, Outlook or an anti-spyware application may disable a plugin. Here's procedure to troubleshoot
1. Check that the Auto-start is still enabled for the plugin
Outlook will auto-load plugins when when registry key LoadBehavior=3 is set for that specific plugin.
Check the following locations
|per-machine install, 32-bit Outlook on 64-bit OS||HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Outlook\Addins\LiquidFilesOLPlugin_Admin.AddinModule|
|per-machine install, Outlook has same bitness as OS||HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\LiquidFilesOLPlugin_Admin.AddinModule|
2. Check/Update Resiliency settings
Check the following registry key:
- Outlook 2016: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Resiliency\
- Outlook 2013: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Resiliency\
- Outlook 2010: HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Resiliency\
If Outlook has blacklisted the plugin, you might just delete everything under CrashingAddinList and DisableItems nodes under that registry keys (or use Outlook's "Disabled Items" dialog to re-enable plugin individually).
Alternatively, you can add plugin's ID to unde DoNotDisableAddinList with value=1
Plugin IDs are:
- Per-user version: LiquidFilesOLPlugin.AddinModule
- Per-computer version: LiquidFilesOLPlugin_Admin.AddinModule