Delay Loading Outlook Add-ins

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:

connect error

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. wlEmoticon-disappointedsmile.png

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 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:

  1. 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.
  2. 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.
  3. 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.

Counting down…

With one month and one week to go, it is time to start moving off Windows XP and Office 2003. Here is another great article from Microsoft about how/why:

Support for Windows XP and Office 2003 ends April 8, 2014 — what’s next?

A few interesting highlights from the article:

  • Windows XP and Office 2003, however, have been supported for more than a decade, or since “Baywatch” went off the air.
  • Computers currently running Windows XP and Office 2003 won’t stop working on April 9, but over time security and performance will be affected: Many newer apps won’t run on Windows XP; new hardware may not support Windows XP; and without critical security updates, PCs may become vulnerable to harmful viruses, spyware and other malicious software that can steal or damage personal information and business data.
  • Office 365 — the next generation of familiar Office productivity applications in the cloud. The subscription-based service offers familiar Office tools and maintains file integrity and design when documents are edited by multiple people, and it provides enterprise-class security and privacy.

If you are considering the move and have questions about your Microsoft Office Integrated Line of Business Applications, there are many ways Microsoft and Microsoft partners can assist you in assessing and remediating these solutions.

You can learn more about Office 365 for your business here:

XP/2003 Deadline Looms

If you are still on Windows XP and Office 2003, if you have not already started your migration, you should start ASAP. The end of support for BOTH is this April. Here is a great link that explains all the reasons you should start today:

I have heard from a number of folks that are “stuck” in XP/2003 land. Namely, because they have a large number of Office based solutions, Excel VBA add-ins, XLL’s, UDF’s, macros and Access 2003 databases that must be migrated and no idea how to begin to remediate them. There is help out there and a number of partners and even service offerings from Microsoft that can help you.

If you have a solution in Office 2003 that you need help to remediate, please contact me. Send me a private tweet or send me an InMail on LinkedIn.

Excel File Cleaner

Last year I worked with a major fortune 500 company on an issue they were having with their Excel files increasing in size by major proportions, slow load times, and cell formatting errors. Each of the problems are documented by well known issues in the Microsoft Knowledge Base:

The company had problems with the workarounds listed in the articles. Those tools/options did not work well because they targeted files created in Excel 2003 and did not take into account the extended cell range capabilities in Excel 2007/2010. As such I created a new tool to help combat this issue. They have since deployed this tool throughout their organization to great success.

Just recently, in an effort to increase the adoption of this tool, I placed it on CodePlex (source code and all). The tool uses the OpenXml toolkit to correct files that exhibit issues (file size, slowness and cell format errors). You can access it here:

Excel File Cleaner

Office 2010 Application Compatibility Tools are Live

As per my previous post, the Microsoft Office 2010 Code Compatibility Inspector and Microsoft Office Environment Assessment Tool are now available for download from the web. Documentation for usage is here:

Additionally, the Office 2010 Compatibility Assessment and Remediation Guide is also available. These tools and documents are in BETA form until the full release of Office 2010 in the first half of next year, but you can still use them and provide feedback.

Microsoft Office 2010 Application Compatibility

Well, it has been a while and I have neglected this page for quite some time – but for good reason. smile_embaressed

I have been very busy writing a set of tools and documents for Microsoft Office 2010 Resource Kit around Application Compatibility Assessment and Remediation. Over the years, while working as an Escalation Engineer in the Microsoft Office Premier Support organization, I have learned that Office itself is easy to install: Run setup.exe. It is trying to get everything that interacts with Office to work that is the hard part. As Microsoft Office has become a development platform for all sorts of line of business applications, add-ins and complex templates with macros, it has become harder and harder to manage a "simple" or "easy" deployment of Office. Getting everything to play well is hard and for a long time Microsoft really has not provided a great deal of support and documentation around how to resolve these issues.

In 2008 a co-worker and I sat down and devised a tool called Microsoft Office System Add-in Scanner or MOSAS. MOSAS was an attempt to assist customers in one of the hardest problems with deploying Office. Assessing their environment for add-ins that interact with Office. This tool along with Office Migration Planning Manager (OMPM) was really all Microsoft had in the way of an “Office tool bag” for Office 2007. But this tool was so well received that it is now getting formally included in the Resource Kit, albeit with some considerable upgrades.

MOSAS is now the Office Environmental Assessment Tool (OEAT). You can get it here (if you are part of the Office 2010 Beta):

I updated the tool – with the help/sponsorship of many others – to help customers deploy Office 2010 much faster. Here is what it does:

  1. Scans computers in your environment for add-ins and applications that interact with Office.
  2. Also collects information about your computer systems (RAM, Office and Windows installs, Service Pack Levels, Antivirus state, and disk space).
  3. Compiles the scans from all the computers in your organization and provides you with a summary and detailed report of everything at was found.
  4. The plan – still in the works – is that by the time Office 2010 releases, vendors will have had an opportunity through this site to provide Application Compatibility information about their applications and add-ins that interact with Office. OEAT (in future updates) will use this information to give you a GREEN/YELLOW status on all your discovered applications and add-ins from your scans. From there you can determine what your best remediation options are.

For more detailed information about this tool, check out Gray Knowltons blog.

But, this is just one tool. There are two others I have been working hard on as well (more information to come):

  • Microsoft Office Visual Basic for Application Code Compatibility Inspector – scans and comments known compatibility issues with your VBA code.
  • Microsoft Office Visual Studio Tools for Office Code Compatibility Inspector – scans and comments known compatibility with your C# and VB.NET VSTO solutions.

Additionally, there will be an extensive guide – available as a green book from TechNet called: The Microsoft Office 2010 Application Compatibility and Remediation Guide. This guide will cover the process of how to use all these tools (and others) to asses your environment, process and remediate any issues found and get you prepared for a successful deployment of Office 2010. Keep an eye out for each of these tools and the guide in coming months as they will be placed on the beta site.

Now, there are several folks to thank (gobs), but here are TWO names of those that have really driven the project, given advice, support and generally helped make these tools a reality:

  • Michael Kiselman – Senior Product Manager (the project lead). Michael is passionate about this project and really GETS the need for these tools and guide. He has made all the contacts with MSDN, TechNet, Sales, Marketing, Office Development, Office Support Program Management and many more to bring everyone together around a common strategy for Office 2010 Application Compatibility.
  • Joe Giunta – Senior Consultant (Migrate, LLC) – Joe is a former Microsoft Senior Consultant, now working for Microsoft through a vendor. Joe helped me originally design and implement this tool and is probably most responsible for its broad adoption throughout Microsoft Services. As a vendor he helps me part time (while helping driving the TAP program the rest of the time). He assist with Specification review, documentation technical review, and sheer brain power. smile_shades

Thank you guys! smile_teeth