When you install something on a Citrix/Terminal server, you do this as an administrator (or someone with administrative privileges), otherwise you won’t be allowed to install.
The server automatically detects that you are installing something, and will therefore put the server into installation mode.
The installer will ALWAYS install the application for All Users, i.e. all registry keys will be written to the HKEY_LOCAL_MACHINE registry hive.
This means that there is no way we can force keys to be written to the HKEY_CURRENT_USER and get the shadow-key system  to work.
What happens when you install? Where are keys written to and why?
When you install the SuperOffice-client, all registry keys will therefore be written to the HKEY_LOCAL_MACHINE hive. Since the SuperOffice client relies less on COM to resolve its dependencies than MailLink, these registry settings are usually trouble free and will make SuperOffice work.
When it comes to the Maillink and Ribbons components, things starts to get more complicated. First of all the installer creates registry keys that identifies existence of the MailLink system. This is written in the following registry key:
The installer writes a COM GUID that point to a COM-registration that resolves to the MailLink components and will make these usable at runtime. This is the first place you might encounter problems.
Since the SuperOffice 7 installer writes everything to the HKEY_LOCAL_MACHINE registry key, we might come in to a situation where the search order in SuperOffice will give us problems. SuperOffice can look for settings both in a user context (using the HKEY_CURRENT_USER) and in the machine context (HKEY_LOCAL_MACHINE).
SuperOffice will ALWAYS look in the user context before checking the machine context.
This means that if a previous installation of SuperOffice 6.3 was installed, you might experience that SuperOffice will read the wrong COM GUID for the MailLink component and fail to start MailLink.
The first thing to check for if this situation happens, is if there are any settings in the user context (HKEY_CURRENT_USER\SOFTWARE\SuperOffice\Mail\Senders\OutlookSender) to resolve which COM Component should be instantiated to start MailLink.
If you have previous registrations, you need to write a simple login-script that deletes these settings for every user that logs on to the Citrix/Terminal Server.
The next step to start troubleshoot is the way the Ribbons and MailLink Addins are registered with Microsoft Office. This is also a place where a few things can go really wrong.
First of all, the Outlook Addin itself is only an Addin, not a Ribbon . An Addin can be registered in a machine context, and is therefore written to the HKEY_LOCAL_MACHINE registry hive (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\SuperOffice.OutlookAddin to be more presise). This will mostly work without too many problems, but be aware of the same issues with previous user-context registrations (HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins\SuperOffice.OutlookAddin) overwriting the one written by the installer.
The Ribbon components on the other hand are more complicated, since they need to be registered in a user context . To make sure that every user gets these Ribbons, Microsoft Office has a system where you can tell Office to create some registry settings in the user context when you are about to start any Office application. This is the mechanism we’ve used to make sure every user gets the correct Ribbons when they log on. The registry propagation system uses a set of registry keys describing what to create that can be found here (for 64-bit machine):
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\User Settings\SuperOfficeOfficeRibbons HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\User Settings\SuperOfficeRibbons
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\15.0\User Settings\SuperOfficeOfficeRibbons HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\15.0\User Settings\SuperOfficeRibbons
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\14.0\User Settings\SuperOfficeOfficeRibbons HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\14.0\User Settings\SuperOfficeRibbons
* Please note a bug with Office 2016
If you don’t want to have Ribbons installed for all users, you can delete these registry keys and enter their values into a login script that adds this for only those of your users that should have MailLink available.
Web Extensions issue on Citrix/Terminal server
In some situations you can experience that Web Extensions leave a permanent "shadow" and block programs running behind it.
To stop this happening you have to activate a registry key named "UseBorderedWindows".
Add the below content in to a text file, name it filename.reg and execute it for every user on the Citrix/Terminal server. You have to logout an login to let it work.
Windows Registry Editor Version 5.00
 The shadow key system is part of the terminal-server and is a system that tracks changes made to the HKEY_CURRENT_USER registry hive when someone is performing an installation and has set the server in install mode. All values written to the shadow key will be deployed to all users logging into the Citrix/terminal server.
 A Ribbon is a user interface element in Microsoft Office 2007 and upwards that adds buttons and other menu elements to the Ribbon user interface.
 For Office 2010 and newer HKEY_LOCAL_MACHINE can be used, but this will not work with Office 2007 without a patch.