MVP - Most Valuable Professional

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft technologies like Exchange Server, Microsoft 365, Microsoft Teams, and Cloud Security.

Exchange Server 2019 LogoThe Problem

You might face a situation during an Exchange Server migration where your Exchange Server 2019 mailbox users are not able to open their public folder favorites when using Outlook on the Web (OWA).

When your users try to access a public folder, they receive an error message.

Screenshot Public No Folders available


This error occurs when the public folder mailboxes are still hosted on a previous version of Exchange Server. This includes Exchange Server 2016 and 2013.

The online documentation explains, why this is happening:

  • Access public folders located on servers running previous versions of Exchange


The Solution

The solution to this problem is easy. Move the public folder mailboxes to Exchange Server 2019 before you migrate any user mailboxes. 

This approach ensures that mailboxes hosted on Exchange Server 2019 and previous versions of Exchange Server are able to access public folders using Outlook on the Web.




Enjoy Exchange Server.



Read More »

The Exchange Product Group announced Exchange Server vNEXT for fall 2021. angekündigt. We are all very excited to see what the new version has to offer.

But what is the current situation in on-premises Exchange organizations? I have put a short questionnaire online for gathering information from you. 

The questionnaire deals with the currently used product versions of Exchange Server, the size of your Exchange organization in terms of the number of servers and mailboxes, and the use of planning for a hybrid configuration with Exchange Online.

Screenshot Exchange Server Questionnaire

Take the questionnaire following this link:

Thank you for your participation.


Viel Spaß mit Exchange Server.


Read More »

Exchange ServerWhen you create or update an Exchange hybrid configuration using the Hybrid Configuration Wizard magic things happen. That's why it is called a Wizard.

One essential step of the Hybrid Configuration Wizard (HCW) is the configuration of the hybrid mail-flow. The hybrid mail-flow is required for both, classic and modern Exchange hybrid. 

The wizard asks you to select one or more Exchange servers that you will utilize for handling inbound mail traffic from Exchange Online to your on-premises organization. You either configure direct mail flow to your Exchange Mailbox Servers in your internal company network, or to your Edge Transport Servers located in the perimeter network.

The following screenshot example shows the selection dialogue.

Screenshot - Hybrid Configuration Wizard Receive Connector Server Selection


You can only select a server object, but not a receive connector on that selected server. The HCW chooses the "right" receive connector on the selected servers for you. If you are using the default set of receive connectors, you will not encounter any issues. HCW will use the default frontend connector on a mailbox server. When you use an Edge Transport Server you will run into any trouble as well. There is only one receive connector which you must extend by setting some additional parameters.

But what about an Exchange Organization where each mailbox server hosts multiple receive connectors bound to TCP port 25? 


The Problem

When you use multiple receive connectors bound to TCP 25 you will see that HCW will choose a receive connector that you won't expect. You might think that HCW will select always the default frontend connector. That is not the case. 

When you select multiple servers for hybrid mail-flow, and each server has a different receive connector configuration, you might get the impression that HCW selects the receive connector randomly. That is not the case either.

While doing some testing in a large enterprise infrastructure with five different Exchange forests (development, testing, staging, pre-production, production) we saw an interesting behavior.

From all available receive connectors having a TCP 25 binding, HCW selects the receive connector with matching RemoteIPRanges values of:

  • IPv6 all (::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) and IPv4 all (
    This is normally the default frontend receive connector when you do not adjust the RemoteIPRanges parameter
  • Just IPv4 all (
  • Just IPv6 all (::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
  • IPv6 any address and IPv4 any address
  • Just an IPv4 address

Adjusting the default receive connector does have a direct impact on how HCW selects a receive connector in your Exchange environment. When you use multiple receive connectors for internal relay purposes, your receive connectors might end up in a messing situation. As mentioned, HCW selects receive connectors with a TCP 25 binding, regardless of the transport location of the connectors, frontend, or hub transport. The enterprise environment mentioned had some deviations between the different environments and we saw TCP 25 receive connectors in frontend transport and hub transport. 


The Solution (sort of)

Run the HCW and select only one server for hybrid mail-flow and identify the receive connector configured by HCW. Configure an appropriate receive connector on all other mailbox servers used for hybrid mail flow. Update the hybrid configuration object of your on-premises Exchange Organization accordingly. 

Verify the following two Tls* parameters of the receive connector:

Get-ReceiveConnector 'EXSRV01\Default Frontend EXSRV01' | fl tls*
TlsCertificateName    : <I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater
                        Manchester, C=GB<S>, OU=PositiveSSL, OU=Domain Control
TlsDomainCapabilities : {}


You must ensure that the hybrid receive connector uses the correct TLS certificate, enabled for SMTP. Additionally, you must set the TlsDomainCapabilitiers to allow cloud mail for connections incoming connections with a TLS certificate for

Keep your receive connectors at frontend transport.   




Enjoy Exchange Server.


Read More »

Exchange Server 2016 LogoRecently I had to support the uninstall of Exchange Server 2016 CU10 on a Windows Server 2019 system. That this setup is not supported is a different topic. In this case, a new Exchange Server 2016 system was placed in service, and the old system needed to be removed from the on-premises Exchange organization.

We mounted the Exchange 2016 CU10 ISO, and ran the following command from an administrative command line:

Setup.exe /mode:uninstall


Prerequisites Checks

The prerequisites check failed with an odd error:

Querying for any incompleted public folder migration requests returned no results. But the prerequisites check insisted that there was an existing public folder migration request. In such a case you already know that you have to use ADSIEdit to find the object in question. 

It turned out that the prerequisites check was right, as we found a single public folder migration request in the Active Directory configuration partition. The request was an artifact of an unsuccessful migration attempt in 2019. After we have checked that the current modern public folder hierarchy worked as expected, we deleted the artifact from Active Directory.

Now the uninstall procedure passed the prerequisites check successfully and the uninstaller moved on removed Exchange Server 2016 step by step.



Uninstall Error

The uninstall step Language Files an Access Denied exception while executing MSIEXEC uninstall actions for each Language Pack.

Language Files                                                                                    FAILED

The following error was generated when "$error.Clear();
$PackageGUIDRegEx = "{DEDFFB[0-9a-fA-F]{2}-42EC-4E26-[0-9a-fA-F]{4}-430E86DF378C}";
$InstallPath = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\setup').MsiInstallPath;

if(test-path ($regPath))
Write-ExchangeSetupLog -info ("Removing " +  $RoleLanguagePackType + " Language Packs.");
Get-ChildItem ($regPath) | foreach{
if($_ -match "(?<ProductCode>$PackageGUIDRegEx)") {
$langPackPackageCode = $matches['ProductCode'];
if($langPackPackageCode -ne $null -and $langPackPackageCode.Length -ne 0) {
Write-ExchangeSetupLog -info ("Removing package $langPackPackageCode");
$language = $langPackPackageCode.Substring(20,4);
$logFilePath = [IO.Path]::Combine($RoleLogFilePath,"Uninstall") + '.' + $language +
'.' + "Client" + "." + $RoleLogDateTime + ".msilog";
uninstall-MsiPackage -ProductCode ($langPackPackageCode) -LogFile ($logFilePath);
Get-Childitem -Path $InstallPath -include ".Localized.js",".Localized.min.js" -recurse | foreach ($) {remove-item $.fullname};
Write-ExchangeSetupLog -info "Remove Language Packs completed.";
" was run: "**System.UnauthorizedAccessException: Access is denied** ---> System.ComponentModel.Win32Exception: Access is denied
--- End of inner exception stack trace ---
at System.Management.Automation.Utils.NativeDirectoryExists(String path)
at System.Management.Automation.SessionStateInternal.IsItemContainer(CmdletProvider providerInstance, String path, CmdletProviderContext context)".


Interestingly, the ExchangeSetup log file showed that the uninstaller wrote the informational text Remove Language Packs completed successfully. 



After following an idea to remove the language pack-related registry keys and other fancy approaches, we did something trivial. We restarted the server, mounted the ISO file, and ran Setup.exe /mode:uninstall again. 

The uninstaller process now passed the step Language Files without any issues.

I sometimes like simple solutions.


Enjoy Exchange Server. 



Read More »

Exchange Server 2019 LogoServices of third-party software solutions often interfere with installing a new Exchange Server cumulative update, because these services have a file lock active. 

To avoid any issues when installing a CU, or having the prerequisites check fail due to open files, you simply stop the Windows services and ensure that those services do not restart automatically. Especially monitoring solutions that use some kind of watchdog service are a candidate that you must disable for installing an Exchange Server CU.

The following two PowerShell examples help you to prepare the Windows services for installing an Exchange Server CU.


Prepare for CU installation

In preparation for the installation of an Exchange Server cumulative update, you can use the following PowerShell commands.

# Disable and stop services or just stop services
# Add other services as needed

# Set SMEX service to manual and stop services
Get-Service -Name 'ScanMail*' | Set-Service -StartupType Manual
Get-Service -Name 'ScanMail*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force

# Stop SMEX SQL Express instance
Get-Service -Name 'MSSQL*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force

# Disable and stop ENow monitoring services
Get-Service 'ENow*' | Set-Service -StartupType Disabled
Get-Service 'ENow*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force

# Stop NetBackup service
Get-Service -Name 'NetBackup*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force


Post CU installation

After installing the Exchange Server cumulative update you should restart your computer. I recommend initiating a check for additional Windows Updates for the CU. This helps to ensure that you do not only have the latest CU installed, but required security updates as well.

# Enabling and starting services
# Adjust the list of services as needed

# Enable and start SMEX services
Get-Service -Name 'ScanMail*' | Set-Service -StartupType Automatic
Get-Service -Name 'ScanMail*' | Start-Service

# Enable and start ENow Monitoring services
Get-Service -Name 'ENow*' | Set-Service -StartupType Automatic
Get-Service -Name 'ENow*' | Start-Service


Enjoy Exchange Server.



Read More »