All posts by jaapwesselius

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.


Event ID 1 MSExchange Autodiscover

Recently I had to install an Exchange 2016 CU16 server as part of an Exchange 2010 migration project. When the server was running as I started moving mailboxes to it, I noticed an increasing number (linear to the number of users it seems) of event ID 1 MSExchange Autodiscover errors in the Application Eventlog of the server:

Event ID 1 MSExchange Autodiscover

Unhandled Exception “Object reference not set to an instance of an object.”
Stack trace: at Microsoft.Exchange.AutoDiscoverV2.FlightSettingRepository.
GetHostNameFromVdir(ADObjectId serverSiteId, String protocol) at Microsoft.Exchange.AutoDiscoverV2. AutoDiscoverV2.ExecuteOnPremEndFlow(AutoDiscoverV2Request request)
at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.Execute (AutoDiscoverV2Request request, ITenantRepository tenantRepository) at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2HandlerBase.<>c__DisplayClass11_0.b__0() at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)

This issue was resolved in Exchange 2016 CU15 en Exchange 2019 CU4, but occasionally pops up in newer versions, and unfortunately on my Exchange 2016 CU16 server.

Although I don’t know the cause of this the workaround is simple. Set the ExternalURL property of the Autodiscover virtual directory, like this:

Get-AutodiscoverVirtualDirectory -Server | Set-AutodiscoverVirtualDirectory -ExternalUrl

This was (is) a known issue at Microsoft and I brought this again to their attention. When something develops, I’ll update this blogpost.

Microsoft Teams without an Office 365 license

Now with all this Working from Home going on you might want to use Teams, even if you don’t have a valid Office 365 license that contains the Teams software. For this Microsoft has introduced the Microsoft Teams Exploratory license. This Exploratory license replaces the previous Microsoft Commercial Cloud Trial.

When a user without a (Teams) license logs on for the first time to Teams via he must login (of course) and the standard logon screen is shown:

login to teams

When logged on for a couple of seconds a license error is shown, and a minute later the user is successfully logged on to Teams, “without” a license:

Teams first time

I have written “without” in quotes, when you navigate to the license portal you will see that the Microsoft Exploratory License is added and one license is (automatically) assigned:

Teams Exploratory License

This one user is the user that was logged in to Teams in the previous step.

The Microsoft Teams Exploratory License is for users to self-assign a license the first time they logon to the service. Typically, this self-assign option is enabled in your tenant, but that might not always be the case. Check the Office 365 admin portal and select Settings | Org settings | User owned apps and services:

User owned apps and services

Open this and check if the Let users access the Office Store and Let users install trial apps and services are checked. Of course, if you do not want your users to do this, uncheck the options.

But besides the Microsoft Teams license, there’s a lot more in the Exploratory license, like an Exchange Online P1, Forms, Planner, Stream etc. available in this license:

Teams Exploratory License Apps

The Microsoft Teams Exploratory license is available at no cost until your renewal on or after January 2021. So, at the time of writing this is at least 7 months away.

Of course you can also integrate the Teams license with an on-premises Exchange 2016 environment, for this please check my previous blogpost Microsoft Teams and Exchange 2016.

More information

Windows Update could not search for new updates when using WSUS

For testing purposes, I had to install a few Windows 7 and Windows 10 machines (with Office 2007, Office 2010 and Office 365 ProPlus) at a customer environment. It was a standard environment with a regular WSUS environment. In this customer environment there were approx. 5000 clients with Windows 7 (I know…) and Windows 10 all working fine with WSUS.

Several of my test machines had problems downloading updates from the WSUS environment, Windows Update returned the Code 80072F8F Windows Update encountered an unknown error as shown in the following screenshot:

Windows could not search for new updates

Emptying the C:\Windows\SoftwareDistribution and restarting the Windows Update service did not help.

When using Google to search for this error a lot was returned (even recent issues which is the reason for my blogpost), but most of them were certificate related where the self-signed certificate on the WSUS server was expired. In my scenario this was not a problem since a valid 3rd party certificate was used on the WSUS server.

The WindowsUpdate.log in C:\Windows revealed more information. One thing I found was DownloadFileInternal failed for error 0x80072f8f.

When using a browser to navigate to this URL a got a certificate warning (which I did not expect btw) about verifying the certificate: This certificate cannot be verified up to a trusted certification authority as shown in the following screenshot:

This certificate cannot be verified up to

From this point on it was easy, install the intermediate and root certificate in the certificate store of the workstation and Windows Update ran successfully – although it takes a very long time to deploy all updates, especially on Windows 7 with Office 2010 🙂