LiquidFiles Outlook Plugin
The Outlook plugin will enable you to send files from Microsoft Outlook 2010-2019. Microsoft Outlook for Windows coming with Office 365 subscription is also supported.
Topic is closed for comments. Please open a Support Ticket with us to ask questions or provide feedback.
End of Support Notications
The following versions of Outlook are no longer supported:
Outlook 2010: End of Support
Microsoft discontinues Outlook 2010 on 10 October 2020. While our plugin 2.0 is built to support Outlook 2010, as of September 2019 (version 2.0.108) we no longer test its release version with Outlook 2010. The forthcoming Outlook plugin 3.0 will not be compatible with Outlook 2010.
Outlook 2007: End of Support
Extended support for Outlook 2007 ended on 10/10/2017. While our plugin 2.x 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.
Windows XP & Outlook 2003: End of Support
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.
Requirements, based on latest available official version
- LiquidFiles virtual appliance v2.0 or later (latest version recommended).
- Windows 7 SP1 or later
- .NET v4.0 or higher (.NET 4.8 recommended). For TLS 1.3, .NET 4.8 is required.
- Microsoft Outlook 2013-2019 or latest version of Outlook 365 for Windows
TLS 1.3 support
LiquidFiles Outlook plugin requires TLS 1.3 support on Windows, which is not the same as TLS 1.3 support in the browser.
- .NET 4.8 is required. TLS 1.3 is not supported with earlier versions of .NET.
- TLS 1.3 is not enabled on Windows 10 by default, and is not supported on Windows 7 (even if the browsers running on Windows 7 support TLS 1.3).
- We have successfully verified that TLS 1.3 is supported by the plugin on Windows 11 in its default configuration with .NET 4.8 installed.
LiquidFiles Outlook plugin requires HTTP/2 support on Windows, which is not the same as HTTP/2 support in the browser.
- We have successfully verified that HTTP/2 is supported with recent Windows 11 and .NET 4.8 installed. It might not be enabled in earlier versions of Windows.
- Windows net stack automatically downgrades to HTTP/1.1 in case HTTP/2 is not supported. No action needed.
- Support for HTTP/2 is implemented with the Outlook plugin 2.1.2, Outlook plugin 3.1.12, and CLI 3.7.4
- With the Outlook plugin 2.1, HTTP/2 is only used when Windows Agent is used to contact the server, which is the default configuration but the plugin might contact the server directly if the Agent is not available. With the plugin 3.*, all communication with the server happens through the Windows Agent only.
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.
- As of version 3.0 (currently in beta), only Outlook 2013 and higher is supported.
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
/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 is also 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.
Support for Single sign-on (SSO)
SSO is fully supported starting with Windows Agent 2.1 and server 3.7. You can also 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; it also may require advanced configuration of Active Directory. Please see the Windows Auth Proxy Documenation for more informationm.
SSO vs Windows Authentication Proxy
Windows Authentication Proxy is designed for automatic authentication without entering credentials. It uses Windows integrated authentication, and relies on a user being logged on into the corporate network, and the network having been configured in such a way that integrated authentication is possible between the user's computer and the IIS.
Windows Authentication Proxy is therefore fundamentally incompatible with multi-factor authentication.
We recommend using SSO in most cases. SSO is supported starting with Windows Agent 2.1, and has limited support starting with 2.0.127. SSO does not require configuration of Windows Agent/Outlook plugin. Please only consider using Windows Authentication Proxy if you understand the requirements for trust relationships in your domain and can configure and maintain the security in the way required for it to operate.
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.
Issues with Office from Microsoft store
Office from Microsoft Store virtualizes both HCLM and AppData folders, which makes it very hard to maintain any COM plugins installed on per-user basis.
- Symptom: when in Compose mode, text of email visibly changes, window flashes, or locks out so that it's impossible to edit.
This happens more often in Inline Response mode, but sometimes can happen when user composes an email in a separate window.
Reason LiquidFiles Outlook plugin tries to inject an HTML marker to mark the start of the signature, and to mark email with its unique ID to track the attachments belonging to the email. Sometimes it does not work well due to compatibility issues or complicated HTML layout of the email.
Solution: Create a registry key
HKEY_CURRENT_USER\Software\LiquidFiles\SFT PreventInjectionOfIdIntoHtml=1 (DWORD)
See Registry Configuration page for more details.
Known side effects: The most severe downside is that the BeforeSignature injection mode will not work. Sometimes the secured attachments could not be sent.
- Symptom:When Outlook compose window is in Plain Text mode, LiquidFiles plugin does not always intercept files drag-and-dropped on the Editor surface.
When that happens, LiquidFiles plugin will not fire, and users might see error message "This file is too large to be attached".
Reason Outlook does not always allow to override the Drag&Drop handler on its editors. We have only seen this on Text editor.
Solution: Educate users who need to use Plain Text editor by default to either switch to HTML before drag&dropping large emails, or drag and drop files above the editor (for example, on Subject line, or on the surface reserved for attachments). They can also use Attach or SecureAttach button from Outlook interface instead of drag&dropping.
- 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?
We advise you to turn on verbose logging when troubleshooting. To enable verbose logging,
regedit, create registry key HKEY_CURRENT_USER\Software\LiquidFiles\SFT if it doesn't already exists;
- Create a new string value TraceLevel and set its value data to Verbose;
- Quit Outlook and exit/kill Windows Agent (use TaskManager to make sure that the process has been restarted).
Depending on version and permissions of the file system, the following files can be found under `%temp%\LiquidFiles*` folder, or under `%localappdata%\liquidfiles\logs` folder. Please check timestamps of the log files and look in all possible locations. Prior to 2.0.105, all logs by default were put into "Add-in Express" folder under "My Documents" folder of the user who's been installing setup package (both _user_ and _admin_ versions).
|Filename||Default location||Log description|
|adxregistrator.log||%temp%\LiquidFiles*||Log of install/uninstall process (add-in only). Can be shared between several add-ins.|
|adxloader.log||%temp%\LiquidFiles*||Log of add-in loading process. Can be shared between several add-ins.|
|LiquidFilesOLPlugin.log||%LocalAppData%\LiquidFiles\Logs||Log file of LiquidFiles Outlook plug-in|
|LiquidFilesWindowsAgent.log||%LocalAppData%\LiquidFiles\Logs||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/2019/365: 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 under DoNotDisableAddinList with value=1
Plugin IDs are:
- Per-user version: LiquidFilesOLPlugin.AddinModule
- Per-computer version: LiquidFilesOLPlugin_Admin.AddinModule
If a per-User plugin does not show up
- Do you really have a rationale to install it per user? Per-machine setup uses different, more reliable loading technique. Do not use per-user setup unless you have a legitimate reason not to use the per-machine setup.
- Was it installed under the correct user profile? Make sure you don't run the setup as administrator.
- Do you use Office from Microsoft Store or other per-user virtualization software?