One of the most popular tools for Citrix ShareFile is the ShareFile Outlook Plug-in. It’s a very lightweight install that allows a user to use ShareFile to share and request files without ever having to leave Outlook. The way the plugin works is ingenious and leverages the user’s existing email attachment workflow, they don’t have to learn a new way of doing things. It will generate a web link and embed it into the body of the email automatically if the file is detected to be over a certain size (5 MB is the default and you can set it to whatever you like). When the user sends the message, that’s when the file is actually uploaded into the ShareFile environment. For this usability factor alone it has become what I would call a critical tool you need to deploy as part of every Citrix ShareFile deployment. The ShareFile Sync for Windows physical endpoints, ShareFile On-Demand Sync for XenApp/XenDesktop, and the newer ShareFile Drive Mapper are also important clients you should leverage in your environment but nothing is an essential as the ShareFile Outlook Plugin in my opinion.
About the Citrix ShareFile Outlook Plug-in
The description from the download page does a great job summarizing what the Outlook plugin offers:
The ShareFile Outlook Plug-in automatically detects and uploads attachments to your ShareFile account and provides the recipient with a link to the attachment in the body of the email. This integration provides users with the ability to send large attachments via email with ease and verify attachments are delivered securely. This plug-in supports both 32-bit and 64-bit versions of Outlook 2007, 2010, 2013 and 2016. ShareFile account authentication is supported as well as accounts using Active Directory credentials and Single Sign On (SSO).
The latest version of the plugins is 4.0 which changes the plugin options UI (just options, not the actual attach and request UI) as well as bring some additional features many people have been waiting for. The biggest addition is support for View-Only sharing. Friendly reminder, if you leverage the View Only Sharing Option, remember in addition to getting Citrix ShareFile Support to flip it on the back end, you may need to make some content switching changes on your NetScaler depending on how your environment is setup. In most organizations I’ve come across these days I’ve not had to do this:
If you do things right you should see something like this when you share a file in View Only mode:
When downloading the plugin for XenDesktop/XenApp usage on a master image for use with Provisioning Services, make sure you download the per machine .msi package, it will be the third one down:
The plugin options UI now looks like this:
the per email Attach Files options (aka Use Custom Settings) now looks like this:
and the per email Request Files options (aka Use Custom Settings) looks like this:
Using AppSense Environment Manager to do a controlled deployment
Pooled non-persistent VDI environments using Citrix PVS usually have 1 master “gold” image with all necessary apps baked in, just a core set of apps baked in, or no apps baked in with everything streamed in via XenApp or App-V or even any number of other app delivery methods using layering, masking, containerization, etc. such as AppDisk, FSLogix, Liquidware Labs, Unidesk, Turbo, etc. You can even use a combination of technologies (and believe me, many companies do). The one thing I want to stress no matter what method you are using, if you are wanting to deploy a whole other master image just for a gradual deployment of an Outlook plugin you’re doing it wrong. The whole point of PVS is to have the OS layer managed centrally while keeping the app layer separately managed and flexible. I have to make sure and say this because I have to explain this delivery concept to people almost weekly now. It’s too easy to make a mistake and have to deal with image sprawl and all the headache that goes with it. Don’t manage your PVS environment this way.
Since the Citrix ShareFile Outlook plugin is an Outlook Add-In you can’t really gradually deploy it to your user base in a controlled manner the same way as any other app in a pooled VDI environment. In environments where AppSense Application Manager is being used to enforce application usage and licensing, you simply enforce the app policies at the executable level. You can’t really do this with an Outlook plugin since it runs under the OUTLOOK.EXE process. Trying to enforce a gradual deployment of the Outlook plugin at that process level would cause many users to not be able to use Outlook and that’s usually frowned upon in most enterprise environments. So the simple answer is to use AppSense Environment Manager to condition out the ShareFile Outlook Plugin to a security group. The security group will contain users that will be allowed to use the ShareFile Outlook Plugin so you can perform a controlled roll out. This will allow you to give access to the plugin to only those that are part of your pilot/QA testing until you decide to flip the switch and give your whole user base access.
Here are the steps you need to perform in your AppSense Environment Manager config:
1. Create a new Pre-Desktop node in your AppSense config for the ShareFile Outlook Plugin.
2. Add any SSO related keys you may need. If you are using AD FS, SAML IdP, etc. you will need these 3 keys:
To break these keys down:
Main key = HKEY_CURRENT_USER
Sub key = Software\Citrix\ShareFile\SSO
Value name = Method
Value type = REG_SZ
Value = saml-forms
Note, depending on your environment there’s a few options here:
- ‘standard’: Authentication will be done with username/password entered into the plug-in options menu
- ‘saml-basic’: Uses SAML provider to authenticate users to ShareFile using their domain (not ShareFile) username/password in the options menu.
- ‘saml-integrated’: Uses SAML provider to authenticate users to ShareFile using their Windows credentials
- ‘saml-forms’: Uses SAML provider to authenticate users through forms authentication to ShareFile using their domain (not ShareFile) username/password in the options menu.
- ‘receiver’: Uses the Receiver/ FollowMeData authentication to sign a user into ShareFile
Main key = HKEY_CURRENT_USER
Sub key = Software\Citrix\ShareFile\SSO
Value name = Subdomain
Value type = REG_SZ
Value = yourcompanyname
Main key = HKEY_CURRENT_USER
Sub key = Software\Citrix\ShareFile\SSO
Value name = UserConfigurable
Value type = REG_DWORD
Value = 00000000 (Hexadecimal)
3. Now let’s move on to the conditioning part. The ShareFile Outlook Addin is controlled by a subkey in your registry called Malone.AddinModule. So we need to create an If Else Group like this:
to break this down, the “If Citrix ShareFile Plugin Access” portion should be the security group that permits the ShareFile Outlook Plugin to run. All users in this group will be able to use the plugin:
The setting for the If is to set the registry value to allow the plugin on the Malone.AddinModule. In this case we need to set it to a value of 00000003 which allows it to run:
Main key = HKEY_CURRENT_USER
Sub key = Software\Microsoft\Office\Outlook\Addins\Malone.AddinModule
Value name = LoadBehavior
Value type = REG_DWORD
Value = 00000003 (Hexadecimal)
4. Lastly we move on to the Else part. We need to tell Malone.AddinModule to not allow the plugin to run for all other users by using a value of 00000002.
Main key = HKEY_CURRENT_USER
Sub key = Software\Microsoft\Office\Outlook\Addins\Malone.AddinModule
Value name = LoadBehavior
Value type = REG_DWORD
Value = 00000002 (Hexadecimal)
And that’s it! Test logging into a virtual desktop with with a user that has access vs. a user that does not. Hope this helps. Please leave a comment or questions below if you need help.
