Short takes: what to do when Outlook won’t open HTTP(S) links; how to disable Outlook Clutter; and don’t run externally-facing mail servers in Azure!

This content is 7 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Once again, my PC is running out of memory because of the number of open browser tabs, so I’ll convert some into a mini-blog post…

Outlook forgets how to open HTTP(S) links

I recently found that Outlook 2016 had “forgotten” what to do with HTTP(S) links – complaining that:

Something unexpected went wrong with this URL: […] Class not registered.

The fix was to reset my default browser in Windows. Even though I hadn’t changed it away from Edge, a Windows Update (I expect) had changed something and Edge needed to be reset as the default browser, after which Outlook was happy to open links to websites again.

Globally disable Outlook Clutter

I had a customer who moved to Exchange Online and then wanted to turn off the Clutter feature, because “people were complaining some of their email was being moved”.

Unfortunately, Clutter is set with a per-mailbox setting so to globally disable it you’ll need something like this:

get-mailbox | set-clutter -enable $false

That will work for existing mailboxes but what about new ones? Well, if you want to do make sure that Clutter remains “off”, then you’ll need a script to run on a regular basis and turn off Clutter for any new users that have been created – maybe using Azure Automation with Office 365?

Alternatively, you can create a transport rule to bypass Clutter.

Personally, I think this is the wrong choice – the answer isn’t to make software work the way we used to – it’s to lead the cultural change to start using new features and functionality to help us become more productive. Regardless, Clutter will soon be replaced by the Focused Inbox (as in the Outlook mobile app).

Don’t run externally-facing mail servers in Azure

I recently came across a problem when running an Exchange Hybrid server on a VM in Azure. Whilst sending mail directly outbound (i.e. not via Office 365 and hence Exchange Online Protection), consumer ISPs like Talk Talk were refusing our email.  I tried adding PTR records in DNS for the mail server but then I found the real issue – Azure adds it’s IP addresses to public block lists in order to protect against abuse.

It turns out that Microsoft’s documentation on sending e-mail from Azure compute resource to external domains is very clear:

“[…] the Azure compute IP address blocks are added to public block lists (such as the Spamhaus PBL).  There are no exceptions to this policy”

and the recommended approach is to use a mail relay – such as Exchange Online Protection or a third party service like SendGrid. Full details can be found in the Microsoft link above.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.