Exchange 2016 End of (mainstream) support

As you should (must) know, Exchange 2010 support will end this October. At that point, Microsoft will stop all support for Exchange 2010, including all security fixes. If you are still running Exchange 2010, you must act now and start moving to Exchange 2016 or to Office 365. For an Exchange 2010 to Office 365 migration I have written a couple of blogs before:

Moving from Exchange 2010 to Office 365.

Moving from Exchange 2010 to Office 365 Part II.

But what most people don’t realize is that Exchange 2016 mainstream support will also end this October. From that point forward, Exchange 2016 will be in extended support. This means no more Cumulative Updates and only Security Updates will be released when there updates are marked as ‘critical’.

Note. There’s no direct upgrade path from Exchange 2010 to Exchange 2019, so if you want to follow this route, you must move to Exchange 2016 first, followed by a migration to Exchange 2019.

If you move to Office 365 and have moved all your Mailboxes to Exchange Online, things are getting interesting. In this situation, you still need at least one Exchange server on-premises for management purposes. Microsoft supplies a free Exchange 2016 hybrid license for this situation (there is no free Exchange 2019 hybrid license!), and Microsoft is committed to support this configuration. At least until the moment a final solution is delivered by Microsoft to remove that last Exchange server from your on-premises organization. According to Microsoft, “this does not increase your risk profile in any way” as stated in their article “Exchange Server 2016 and End of Mainstream Support”.
If you still have mailboxes on-premises, the Microsoft recommendation is to move to Exchange 2019. Mainstream support for Exchange 2019 will end on January 1st, 2024, and extended support for Exchange 2019 will end on October 14, 2025 (this is the same date as end of extended support for Exchange 2016).

What to do

  1. If you are still on Exchange 2010, I would urge you to move to Exchange 2016 as soon as possible. Mainstream support for Exchange 2016 will stop this October, but according to Microsoft you are still safe since Security Updates will be released when needed. There’s no direct need to upgrade to Exchange 2019 at this moment, but this is something you must consider the upcoming time. I do know customers however that only want products that are in mainstream support, so if you are in this boat you must move to Exchange 2019 of course.
  2. If you are running Exchange 2013, you must start moving to Exchange 2019 anytime soon for optimal support and skip Exchange 2016.
  3. If you are in an Exchange 2016 hybrid scenario and all your mailboxes are in Exchange Online, you are safe to stay in this situation until Microsoft releases a final solution for that dreaded last Exchange server on-premises for management purposes.
  4. If you are in Exchange 2016 hybrid and you still have mailboxes on-premises, you must move this to Exchange 2019 hybrid to stay in a supported configuration. Please keep in mind that Microsoft only supports the version n-1 in a hybrid scenario, which means automatically Exchange 2019 after this October.



Office 365 Groups not showing up in Outlook 2016

I have had this annoying issue with Office 365 Groups (Groups, not Teams). In our IT team we have several Office 365 Groups. Some users do see these groups in Outlook 2016 almost immediately, other users do not see anything (I’m in this group). When I select Browse Office 365 Groups in Outlook, I see an error message saying We can’t show you group right now. Make sure Outlook is connected and try again as shown in the following screenshot:

we cant show you right now

In Office 365 Teams there are the HiddenFromExchangeClients and HiddenFromAddressListsEnabled properties (see the Hiding Office 365 Groups Created by Teams from Exchange Clients article from Tony Redmond for more information) , but this is only Office 365 Groups and not an Office 365 Team. And both properties are set to FALSE, so this is not the case.

I am using Office 365 ProPlus Click-to-Run which checks Exchange Online first for Autodiscover purposes, but then I realized I had been experimenting with some registry keys to change Autodiscover behavior. When checking the registry, I found the ExcludeExplicitO365Endpoint DWORD set to 1 as shown in the following screenshot:


So, Autodiscover checks on-premises Exchange server and is redirected to Office 365 for Exchange Online information. Unfortunately, this does not retrieve any information regarding Office 365 groups. After changing this value to ‘0’, Autodiscover starts with Office 365 and does retrieve the correct Office 365 Groups information.

Related to this, there are also scenarios where Outlook does not detect Office 365 groups using Autodiscover where the (primary) SMTP address of the Office 365 group is not correct. For example, where the SMTP address of the group is (for example) You can change the primary address of the group using the following command in Exchange Online PowerShell:

Set-UnifiedGroup Alias -PrimarySmtpAddress

Or when you want to add the SMTP address as a secondary address:

Set-UnifiedGroup IT-Calendar -EmailAddresses @{add=""}

This should also solve the problem.

Azure AD Connect versions

Be honest, how often do you check the software versions on your Azure AD connect server? I have to admit, Exchange is not an issue, this is updated regularly, but Azure AD Connect is a different story. At the moment of writing my Azure AD Connect version is running (installed on December 31, 2019 so more than 6 months ago) while version is already available for some time now (source: Azure AD Connect: Version release history). And although Azure AD Connect supports auto upgrade (Check with the Get-ADSyncAutoUpgrade cmdlet), not all updates of Azure AD Connect support auto upgrade and thus need to be upgraded manually.

Azure AD Connect older versions

It is important to have a look at the versions of Azure AD Connect, I was bit surprised (but can totally understand) to read the following on the Microsoft site:

“Starting on November 1st, 2020, we will begin implementing a deprecation process whereby versions of Azure AD Connect that were released more than 18 months ago will be deprecated. At that time we will begin this process by deprecating all releases of Azure AD Connect with version (which was released on 4/24/2019) and older, and we will proceed to evaluate the deprecation of older versions of Azure AD Connect every time a new version releases.”

You can download the latest versions of Azure AD Connect from After starting the Azure AD Connect package, enter the global tenant admin credentials and follow the wizard.

Upgrade Azure AD Connect

The upgrade should be finished in a minute or two.

Starting with Azure AD Connect version Microsoft implemented the Azure AD Connect sync V2 endpoint API (public preview) which will improve performance to Azure AD synchronization. You can enable the new endpoint using the following commands in a PowerShell window on the Azure AD Connect server (elevated permissions):

Set-ADSyncScheduler -SyncCycleEnabled $false
Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
Set-ADSyncAADConnectorExportApiVersion 2
Set-ADSyncAADConnectorImportApiVersion 2
set-ADSyncScheduler -SyncCycleEnabled $True

Azure AD Connect v2 endpoint

In the first screenshot you can also see the Azure AD Password Protection proxy. This was installed on December 17, 2019 and the version installed is This is also the latest version, which you can check on Azure AD Password Protection agent version history.

The Azure AD Password Protection proxy also supports auto upgrade, you can check the settings using the Get-AzureADPasswordProtectionProxyConfiguration cmdlet on the Azure AD Connect server.

More information

ExoPrise Cloud Monitoring solution

When you are running an on-premises IT environment you most likely have some kind of monitoring solution. If something goes wrong in the infrastructure you are notified almost immediately, and you can take appropriate action.

Things are different when using cloud services. Your services are running in a datacenter somewhere else, controlled by another organization and with an internet connection (that sometimes can be unreliable).

For a customer I checked out ExoPrise, a SaaS (Software as a Service) based cloud monitoring solution. With surprising results.

ExoPrise private site

Exoprise is a cloud monitoring solution which is offered as a SaaS solution. This means Exoprise is running in a datacenter somewhere, and you have a subscription for using the services. Because it is a SaaS solution, installing and configuring the monitoring solution is just a matter of minutes.

Exoprise is running in a datacenter somewhere, but when using Exoprise you configure your own private site. A private site is a WIN32 service running on a Windows server in your own environment. From this private site, cloud services are monitored. From an end-user perspective, the private site has the same user experience as your local users have.

You can install and configure multiple sensors in your private site. Each service has its own sensor, there are sensors for Exchange Online, Microsoft Teams (Messages and A/V), Skype for Business, Free/Busy, ADFS, OneDrive, SSLCheck, Amazon, Google, Salesforce …. Tons of sensors are available.

When configured, a sensor performs synthetic transactions against the cloud service. For example, the Exchange Online sensor looks at the average logon time, message transfer speed and network latency. The results are shown graphically for your own sensor, but because it is a SaaS solution Exoprise can compare your results against the results of the rest of the world which they call ‘crowd’. This is shown in the following screenshot, the lower line is my own sensor, the upper (thinner) line is the crowd average.

With all this working from home due to the Covid-19 crisis a lot of organization have been implementing Microsoft Teams rapidly. As an admin you want to know you Teams is performing from your local environment. When configuring a Teams AV sensor it performs all kinds or synthetic transactions, very similar to the transactions a regular user is performing. The sensor is using a test identity in your Teams environment and it uses a bot in Exoprise to communicate with. This way it can measure the call quality of Teams and it measure logon time, A/V streams (audio jitter, packet loss, bitrate), frames per second etc.

When configuring a sensor, an alarm is automatically created. This alarm can be configured during creation:

When the sensor is triggered because of a transaction, an alarm is sent to the email address that is configured and this gives you an immediate overview that something is wrong with the service. And to be honest, I was a bit surprised how often alarms are generated and thus how often you will receive an email. The email will show which sensor is generating the alarm, some analysis information and alarm details as shown in the following screenshot.

Besides the alarm message you’ll also get a weekly overview with real user performance data that is gathered from ‘the crowd’ so it averages over all Exoprise sensors that are deployed. This will show overall trends for all cloud services, for example:


There are multiple cloud monitoring solutions available and I had the opportunity to have a look at the ExoPrise solution. I was surprised by the ease of configuration and ease of use. It is a cloud based service, pull your credit card and you’ll be working within 20 minutes. It is a great tool for monitoring your environment, but at the same time it is a great tool for troubleshooting purposes (when you are a consultant).

I was also surprised by the data that was gathered by the ExoPrise sensors. It shows immediately when something is wrong, and you are notified before your users start calling the servicedesk that something is not working. And that happened more often than I thought before.


HCW8001 – Unable to determine the tenant routing domain

As a consultant in messaging and collaboration I have created dozens of Exchange hybrid configurations that last years, ranging from Exchange 2010 to Exchange 2019.
Today we’ve run into an issue I have not seen before, the HCW8001 – Unable to determine the Tenant Routing Domain error:

Unable to determine the tenant routing domain

Note. In one of my earlier blogs Moving from Exchange 2010 to Office 365 somebody mentioned this specific error in the comments in September 2018.

When you click Learn more you are redirected to the following Microsoft page: which states you have to enable Directory Synchronization using the following command:

Set-MsolDirSyncEnabled -EnableDirsync $true

Which of course we did, but no success.

Azure AD Connect was running fine, I checked the configuration (optional features) and found nothing strange and no errors were logged.

Optional Features

When checking the Microsoft Portal I could see Directory Synchronization was running:

Azure AD Connect

The tenant routing domain is typically something like <tenantname> and this is set in Office 365 when installing Azure AD Connect. But when checking the Accepted Domains (in Exchange Online) this domain is not available:

Accepted Domains

There’s no way you can add this <tenantname> domain manually (also not via the Microsoft Online Portal) so you are out of luck (I tried the Azure AD Connect server multiple times, but it didn’t work).

You can open a ticket with Microsoft Support or see if you can create a new tenant and start over again. Since this happens rarely I would be surprised you run into this again with a new tenant.


Microsoft UC Specialist