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!

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.

Short takes: pairing my headphones, firewalls and Exchange SMTP communications, tethered photos with a Mac

Some more snippets that don’t quite make a blog post…

Because I always forget how to do this: how to pair a Plantronics BackBeat PRO headset with a mobile device.

And a little tip whilst troubleshooting connectivity to an Exchange Server server for hybrid connectivity with Office 365… if telnet ipaddress 25 gives a banner response from the SMTP server then that’s a good thing – if the firewall is interrupting transmission then I’ll get nothing back, or asterisks ********. Joe Palarchio (@JoePalarchio) writes about this (see issue 7) in his post on Common Exchange Online Hybrid Mail Flow Issues. Note that firewalls doing any form of blocking between Exchange servers are unsupported but that doesn’t stop customers from putting them between their email servers and anything running in the cloud (e.g. Hybrid server in Azure).  If you need to do this, then you should have any ANY/ANY rule (i.e. allow free flow of traffic) between the Exchange Server servers.

Take photos with OS X Image CaptureFinally, back in 2009, I  wrote about tethering a DLSR to a computer and taking pictures using Windows PowerShell (I think I’ve also written about using software to do this). Well, it turns out that the OS X Image Capture utility can also take a photo on a supported camera – either on a timed basis or by pressing a key.  Could be useful to know if setting up a time-lapse, or for studio work…

Clutter and Junk Email in Exchange Online

One of my Office 365 customers has been asking about Clutter and Junk Email – with concerns that Clutter doesn’t move all the mail they think it should and also that more email is being trapped as junk than they expect (or experienced with on-premises Exchange.  I thought it might be useful to cover a few bits and pieces on the topic…


Looking first at Clutter, it’s a new capability introduced in Exchange Online a year ago which uses the Office Graph to move lower priority messages out of your way and into a new Clutter folder, with the intention that users can focus on the most important messages in their Inbox.  In essence, not everything received from third parties trying to sell things is junk – you may have newsletters and other updates that are not essential but that you don’t need to read right away. And, as your reading habits change, Clutter learns and adapts.

It’s a nice idea, but sometimes Clutter needs a little helping hand. You can switch Clutter on/off, or help it to learn your preferences by following Microsoft’s advice to use Clutter to sort low priority messages in Outlook on the web. Office 2016 users can also train Clutter in Outlook (the capability is not there in Outlook 2013).

In addition, messages sent from yourself, or from your management chain or direct reports (if you’re an Office 365 Business user) will never be identified as Clutter. It’s also possible for administrators to use a transport rule to ensure that certain messages are not treated as Clutter.

If you want to know more, Tony Redmond (@12knocksinna) has an FAQ with answers to common Clutter questions that I recommend reading.

Junk Email

Junk Email filtering has been around for a lot longer than Clutter and Office 365 uses intelligence built up over time to ?determine which messages are “spam” or junk email. Many messages are trapped before they even get to your Inbox. Sometimes, it’s not clear whether a message is Junk or not and something you intended to receive may be moved to your Junk Email folder in error. In my customer’s case, after a mailbox had been transferred from the on-premises Exchange to Exchange Online, we effectively have a new mailbox in a new Exchange organisation and it needed to re-learn some of the personal preferences around Junk email.

It’s unlikely that internal email will be classified as Junk; however you can edit this following the advice in Microsoft knowledge base article 2545137. It’s also possible to use a transport rule to set the spam confidence level (SCL) to -1 (i.e. definitely not spam) based on given criteria.  In addition, allow and block lists can be created within the spam filter in the Exchange Admin Center.

There’s more information on safe and blocked senders and the various mechanisms that are used in the Microsoft TechNet safe sender and blocked senders FAQ as well as consumer advice on using Junk Email Filters to control which messages you see.

The whole process

The whole filtering/organising process works like this:

  1. Messages identified as possible junk email are automatically moved to the Junk Email folder, and any potentially dangerous content, for example links or attached programs, are disabled.
  2. Next, any Inbox rules are processed.
  3. If you use Sweep in Outlook on the web, it will then organize your Inbox.
  4. Finally, Clutter will analyse the remaining messages and filters those that match a pattern for being ignored or not responded to, based on past behaviour.

Lync client does not retrieve conversation history and meeting information from Exchange

In addition to the challenges created by the unified contacts store, my recent Office 365 migration project saw some issues where a user’s Lync/Skype for Business client failed to pick up a change in Exchange Web Services (EWS) as part of the move to Skype for Business Online.

The reason for this is unclear but I’m not the only one who’s experienced it – Richard Brynteson describes exactly the same scenario where, after a migration from an on-premises Exchange mailbox to Exchange Online, the Lync 2013 client is unable to connect to the Exchange server and pull conversation history and meeting information.

If we looked at the configuration information for the Lync client (by Ctrl+right clicking on the Lync taskbar icon), we could see that the client was not autodiscovering the move to Exchange Online and still showed on-premises Exchange details, instead of a blank EWS Internal URL and an entry of for the EWS External URL.

One suggestion given to me to force a new autodiscovery search was to wipe the user’s cached client information (in %appdata%\Local\Microsoft\Office\15.0\Lync\sip_alias@domainname.tld). That sounded a little destructive but Richard’s post suggests removing a single registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync\username@domainname.tld\Autodiscovery.

Even better though is the solution from a comment on Richard’s blog post, from “Chad”:

We’ve resolved this by having users sign out of Lync and then choose “Delete my sign-in info”, then just sign back in and their Lync client now connects to 365. We provide this as post-migration steps to users once we move their mailboxes to 365. Hope that helps and is typically easier than deleting [registry] entries.

That’s a much more user-friendly fix (which worked for me) – and it’s one to add to the project FAQ list.

Unified Contact Store requires Lync user to be migrated to Office 365 before Exchange mailbox

In a recent Office 365 project, I came across an issue where, if we migrated a user’s Exchange 2013 mailbox to Exchange Online before we migrated their Lync 2013 user to Skype for Business Online, the Move-CsUser cmdlet generated an error:

Move-CsUser: Exception of type ‘Microsoft.Rtc.Management.AD.Helpers.RollbackException’ was thrown

This is described in Camille de Bay’s blog post and appears to be related to the Unified Contact Store, which is enabled by default with Lync 2013 and Exchange 2013.  There appear to be two options:

  1. Migrate Lync before Exchange
  2. Use the -force switch with the Move-CsUser cmdlet (which will result in a loss of contacts)

Dave Stork goes on to describe some issues with a combination of the UCS, Lync on-premises and Exchange Online (and these appeared to apply to my Lync 2013/Skype for Business Online hybrid solution too).

Microsoft knowledge base article 2614614 has lots more information on integrating Exchange Online with Skype for Business Online, Lync Server 2013, or a Lync Server 2013 hybrid deployment

Tools for troubleshooting Outlook autodiscover

In my post last week about Office 365 and proxy servers, I mentioned issues with Outlook autodiscover.  These were not exactly easy to troubleshoot, often with multiple subject matter experts looking from different angles (network, client applications, Exchange, firewalls, etc.). During the process, we used a few tools (as well as examining the traffic hitting the proxy servers) and I thought I’d highlight them here (if only for my own future reference):

Connected accounts in Office 365 (Exchange Online)

I have a customer who is adopting Office 365 – but in a targeted manner for certain parts of his business. The business case just doesn’t stack up for a total deployment but he does want to make the most of the features and functionality that are available, to showcase how it really can be used to those who are on the platform.

Because his email is still on the corporate mail platform (where the MX records point), and there is no Exchange hybrid connectivity configured, we’ve been looking at the use of connected accounts in Office 365 – so that certain key members of staff can use Exchange Online mailboxes without actually migrating their email service.

It’s an unusual scenario, and generally only mentioned as a quick and dirty solution to get people using Office 365 in pilot.  Even so, there’s no reason why it shouldn’t work for a more permanent solution – provided that the on-premises mail server can be reached from the Internet using POP3 or IMAP4 (preferably secured with SSL) and that it’s well-understood that Exchange Online will poll for new mail less frequently than a direct connection from Outlook to the source mail server would.  It’s also useful for pulling email from third party mail platforms into your Exchange Online mailbox (I use it for Hotmail).

The latest advice from Microsoft on using the feature can be found in the connect email accounts in Outlook on the web Office support page and there’s also some useful information on connected accounts in the Office 365 community.

Moving mailboxes to/from Exchange Online using the EAC

One of the advantages with deploying Exchange Online in a hybrid configuration (i.e. Exchange on-premises and Office 365 Exchange Online in the cloud) is that you can easily move mailboxes back and forth.

It can be done with PowerShell but one of the straightforward methods is from the Exchange Admin Center (EAC), where there’s an option (to the bottom right of the mailbox panel, under recipients in the Enterprise tab) to move a mailbox to Exchange Online, or to another database (locally), with most of the settings pre-populated for you (like the target mail domain or

Moving back requires a slightly different process though and needs to be performed from the migration panel in the Office 365 tab of EAC.

You’ll also need to know the name of the database you want to move the mailbox to on-premises, and the mail domain name.

One of the challenges I found with moving mailboxes to/from Exchange Online using the EAC was that I sometimes see a migration batch marked as “Completed” but with 0 of 0 synced, 0 of 0 finalized, 0 failed.  This seems to happen if a previous mailbox move had failed; deleting the failed migration batch before re-attempting seems to allow the mailbox move to run successfully.

Looping on the authentication prompt for the ECP virtual directory in Exchange 2013

I had an “interesting” problem on an Exchange server last week… I could access the Exchange Control Panel using https://localhost/ecp but it I tried to use its externally-accessible namespace (which I needed to in order to run the Exchange Hybrid Configuration Wizard), it kept looping on the authentication prompt. The password was correct but it just came straight back to a prompt again…

It turned out to be an issue with HTTP redirection in IIS and, following the MSExchangeGuru post on HTTP redirection issues with the ECP virtual directory I set up HTTP redirection on the Default Website but turned it off for OWA, ECP and the various other virtual directories. I also checked that SSL was not required for the PowerShell virtual directory.

Bipin Giri’s post on configuring URL redirection in Exchange 2013 suggests I need to repeat the same steps for the Exchange Backend Server website too but I didn’t find that necessary (and I’m sure I’ve also read to leave that alone!).

There’s a useful table in the MSExchangeGuru post that summarises the need for an HTTP redirect and whether SSL should be enabled for the website and for each virtual directory but it’s also worth knowing that Morten Nielsen has listed the default virtual directory settings for Exchange 2013 in great detail.

Manually removing servers from an Exchange organization

I’m starting this blog post with a caveat: the process I’m going to describe here is not a good idea, goes against the advice of my colleagues (who have battle scars from when it’s been attempted in a live environment and not gone so well) and is certainly not recommended. In addition, I can’t be held responsible for any unintended consequences of following these steps.

Notwithstanding the above, I found myself trying to configure the Exchange Hybrid Configuration Wizard (HCW) in a customer environment, where the wizard failed because it was looking for servers that don’t exist any more.

I had two choices:

  1. Recover the missing Exchange servers with setup.exe /m:RecoverServer, then uninstall Exchange gracefully (for 12 servers!).
  2. Manually remove the servers using ADSI Edit.

I explained the situation to my customer, who discussed it with his Exchange expert, and they directed me to go for option 2 – this was a test environment, not production, and they were prepared to accept the risk.

Fearing the worst, I made a backup of Active Directory, just in case. This involved:

  1. Installing the Windows Server Backup Command Line Tools feature on the domain controller.
  2. Running wbadmin start systemstatebackup -backuptarget:driveletter:
  3. Sitting back and waiting for the process to complete.

With a backup completed, I could then:

  1. Run ADSI Edit.
  2. Open the configuration naming context.
  3. Navigate to CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=organizationname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domainname,DC=tld
  4. Delete the records for the servers that no longer exist.
  5. Restart each of the remaining Exchange servers in the organisation in turn.
  6. Check the server list in ECP.

(Incidentally, FYDIBOHF23SPDLT is “Caesar’s Cipher” for EXCHANGE12ROCKS).

Murat Yildirimoglu’s Windows IT Pro article entitled “How to Uninstall a Stubborn Exchange Server” goes into more detail, including completely removing an Exchange organisation from Active Directory, should that be required (Christopher Dargel covers that too).

The process seemed to work but the danger of manually removing servers from an Exchange organization like this is the potential side effects of “unknown unknowns” (which you can be sure won’t surface immediately). It did let me progress to the next stage of the HCW though. More on that in a future blog post…