Table of Contents
Time to Consider How to Handle Outlook Add-Ins for New Clients
A recent Practical365.com article about user submissions of suspicious email caused me to think. Not about the proposal because it’s obvious that allowing people to report suspicious messages that Exchange Online delivers to their inboxes is a good idea.
After all, if someone receives an email that looks like malware, smells like phishing, and has a faint hint of spam, it’s probably not a good thing. And if it gets to a mailbox, it’s a failure of Exchange Online Protection (EOP) or whatever email cleansing service the message passed through en route. Reporting this kind of message to their administrator or Microsoft for further analysis is right and proper. Everyone benefits when Microsoft receives copies of messages that get past the EOP tests.
Customizable Notification Messages
The article explains how Exchange Online now allows organizations to customize the messages displayed when people report bad email. It’s a nice feature that allows organizations to reassure people that something happens when they take the time to report a problem. No one likes their efforts to disappear into a black hole. Figure 1 is an example of a customized message sent to people in my tenant when an administrator reviews a reported message. The format of the message contains corporate branding to reassure the recipient about its source.
The End of COM Add-ins
But the goodness of being able to create customized notification messages for reporting bad email is not what caused me to think. My attention was drawn to the assertion that the Report Message/Report Phish add-ins will stop working at some point in the future. These add-ins allow users to report messages as junk mail or phishing and have been around for a while. Their long-term replacement is a built-in Report message button that can report messages as either phishing or junk. In other words, a consolidation of add-ins.
At this point, you might wonder why I focus on such an arcane subject. Does it matter if Microsoft decides to replace some Outlook add-ins? Of course, it doesn’t, except when it’s a pointer to a change that might affect customer organizations and ISVs. The older Outlook (for Windows) add-in model is COM-based. Many such examples of these add-ins exist, whether built by ISVs or in-house.
Monarch and OWA Don’t Use COM
This brings me to the point of this note: Microsoft is updating its Outlook add-ins to move away from COM. Is the same happening for the add-ins created by ISVs or in-house development? With its knowledge of where the Outlook puck is going, Microsoft has first-mover advantage here, but the fact that it’s making the change should signal a warning to tenant administrators and architects that it’s time to understand what COM-based add-ins are in use and the plans to evolve them to work with the new Outlook, or even with today’s OWA client.
ISVs know what’s happening and will have plans to evolve their products. I wonder if the same attention is paid for in-house code. Given the longevity of the current Outlook for Windows architecture, it’s possible that some add-ins are in situ that no one wearing an administrator hat knows much about. It would be a shame if an obscure but necessary add-in surfaced to disrupt future deployment plans, so do yourself a favor and check now.
Keep up to date with developments like Project Monarch by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.