A customer I work with encountered an issue where a specific add-in was causing Outlook to lose its network connection. Essentially, we were unable to get the “Click here to view more on Microsoft Exchange” (in cached mode) to light up. Here is what we saw:
Here is what we wanted to see:
It was always grayed out and no mater what we did in Outlook with the connection state, it never same back.
After a lot of troubleshooting we found one particular in-house add-in was causing the problem. Oddly, everything worked great with the same add-in in previous versions of Outlook, but in Outlook 2016, we started seeing this problem. Therefore, we knew it had to be a change made in Outlook 2016. What we found is that Outlook 2016 had been greatly reconfigured in the startup code to optimize network connections as it now connects to the cloud (Office 365). So we started working with the product team on identifying the root cause and in the end we were unable to find a solution (in time). My customers deployment was delayed.
As such, I had to come up with a workaround. We found that if the add-in was not loaded when Outlook started, but was manually enabled after Outlook launched, the problem would NOT occur. This got me thinking: What if I created an add-in that loaded add-ins AFTER Outlook was done loading all other add-ins?
The Outlook Delayed Loading of Add-ins for the Enterprise was born. By the way, that name is credited to my customer. The catchy acronym stuck: D-LAME Add-in. 
I have posted the project for it here on GitHub here:
You will need to load it into Visual Studio and compile it and then sign it with a certificate on your own. The code is provided AS IS. The README.md on the page explains the installation, configuration and usage of the a add-in once you have it ready for deployment. Some key points:
- You will want to make sure it is not disabled by setting the Resilience policy key for the add-in.
- You will want to move the add-in(s) you wish to delay from HKLM to HKCU registry locations.
- You can load DLAME as either HKCU or HKLM. The suggestion is HKLM.
So, what can you use this for? Well, it turns out this add-in has a lot of uses and as I have started discussing it with other support folks at Microsoft, several use cases came out:
- You have a lot of add-ins that you need to have loaded with Outlook. They keep getting disabled by Outlooks resiliency feature, so you add policy settings to prevent them from being disabled, but now Outlook takes forever to launch. You can now set only DLAME to be resiliency policy blocked and then delay load all your other add-ins.
- Because it is a .NET/VSTO add-in, added to the above scenario, you can have all your VSTO add-ins load after Outlook has completed loading all other add-ins.
- Because the loading occurs on a background thread, the user will see Outlook fully load and then will start to see the other add-ins load (Ribbons and buttons appearing) after they are able to see their inbox and start reading/selecting items.
Bottom line, this add-in is useful for helping an enterprise manage their add-in without impacting the loading of Outlook or user productivity.
However, there is ONE major caveat. You will need to thoroughly test your add-ins because some add-ins might not like being loaded AFTER the fact. Technically, I have not found any that behave this way, but there could be some that register to certain events (like Application_Load and NewExplorer) that will not get fired if loaded after Outlook is already fully loaded.