Category Archives: Exchange

Exchange Server Subscription Edition (SE) publicly available

Today, July 1st, 2025, Microsoft released Exchange Server Subscription Edition (SE) as the successor of Exchange Server 2019.

Exchange Server SE in itself is not that exciting, it is 100% binary compatible with Exchange 2019 CU15 with the latest May 2025 Hotfix Update, except for the license agreement (EULA) and the build and version number.

This makes it very easy to do an in-place upgrade from Exchange 2019 CU14 or CU15, or a regular migration where Exchange Server SE is installed in an existing Exchange 2016 environment. Please note that Exchange Server SE cannot be installed in an existing Exchange 2013, just like Exchange 2019 CU15.

The last couple of months I did several presentation on Exchange Server SE and did several project to prepare for Exchange Server SE. The most asked question was “what about the subscription?”.

That’s not too difficult. The subscription is in the license, not in the product. The perpetual license has been discontinued and replaced with a subscription license. As for Exchange Server SE, there’s no online license checking or revocation (for now), and there’s still no need to connect your Exchange SE servers directly to the Internet (but it has some advantages, especially for services like the EEMS or the Feature Flighting service).

Why is this an important update and important timing? On October 14, 2025 which is less than four months from now, Exchange Server 2016 and Exchange 2019 will reach end-of-life and will no longer be supported by Microsoft. These products will of course continue to run, but Microsoft will no longer release any security updates for both products.

If you are still running on an older version of Exchange Server, you are running out of time and you must start an upgrade project soon and upgrade to Exchange 2019 CU14/CU15 of Exchange Server SE when possible.

More information regarding Exchange Server SE can be found here Exchange Server Subscription Edition (SE) is now available and can be downloaded from the VLSC or the Microsoft download center.

Exchange Hybrid strange calendar behavior and mail flow

In a hybrid Exchange environment, mail flow is erratic, meetings are not always visible, and the Teams calendar does not match the calendar in Outlook. The user sends an email, and all recipients receive it. However, the sender does not always receive replies, sometimes resulting in a Non-Delivery Report (NDR). Another issue is that external users send emails to a user, but the user does not always receive the messages. Also, the calendar in Teams does not match the information shown in the Outlook calendar.

This issue occurs in a hybrid Exchange environment when this user accidentally has two mailboxes: one in the Exchange server and one in Exchange Online.

One account with two mailboxes? Yes, this is usually a result of a glitch in the provisioning. Let me explain what happens:

  • A user account is created in Active Directory and most of the time, the user is added to a security group used to assign licenses in Office 365.
  • When Entra Connect runs, the user account is synchronized with Entra ID, and a license is automatically assigned to the new account. As a result, a mailbox in Exchange Online is automatically and immediately created.
  • The last step is creating a mailbox on the Exchange server. The Exchange Server will gladly accept this since it does not know the mailbox in Exchange Online.

Outlook will then connect to the mailbox in Exchange on-premises. Depending on how the mail flow is configured, mail is sometimes delivered to the Exchange Online mailbox and sometimes to the Exchange server mailbox. Since the user’s Outlook is connected to the mailbox in the Exchange server, the user will never see items delivered to the Exchange Online mailbox.

In this situation, the Teams client shows the calendar information found in Exchange Online, while the user’s Outlook looks at the calendar information in Exchange on-premises. You can guess the results.

To fix this, the mailbox in Exchange Online must be removed and to do this, you can follow these instructions:

  • Remove the M365 license from the user, typically by removing the user account from the Security Group that’s used for licensing and wait for Entra Connect Sync to kick in and synchronize with Entra ID.
  • Open Exchange Online PowerShell and execute the following command:
    Get-User | Select name,Recipient
  • The property PreviousRecipientTypeDetails must have the value ‘MailUser’. If it contains the value ‘UserMailbox’ it means that the user has a mailbox in Exchange Online (which is not what we want in this situation)
  • Execute the following command:
    Set-User -PermanentlyClearPreviousMailboxInfo
  • This will permanently remove the mailbox in Exchange Online from the user (keep in mind that it also cannot be restored anymore!)
  • Wait for Entra Connect Sync to synchronize the latest attributes so that the account now becomes a mail-enabled account.
  • Assign the license again to the server, typically by adding the user again to the Security Group used for licensing.

The user now has a mailbox in Exchange on-premises, and this mailbox is represented as a mail-enabled user in Exchange Online.

As a side note: I’ve seen this happen also in a situation where Exchange is running on-premises and Entra Connect Sync is configured without the ‘Exchange Hybrid Deployment’ option as shown in the following screenshot:

If this is the case you can use the same procedure as outlined above.

Exchange 2019 Cumulative Update15

On February 10, 2025, Microsoft released Cumulative Update 15 for Exchange 2019, also called the 2025H1 Update, the first step towards Exchange Server SE. CU15 is an interesting and essential update since it is the last major update for Exchange 2019. The next major update that Microsoft will release is Exchange Server Subscription Edition (SE) later this year.

Exchange 2019 CU15 comes with several new features:

  • Support for Windows Server 2025, but it can also be installed on Windows Server 2022 and Windows Server 2019. Windows Server 2025 has a slightly different set of prerequisites server roles and features, mainly because of the absence of the SMTP stack in Windows Server 2025.
    When you want to install Exchange CU15 on Windows 2025 please be aware that you cannot in-place upgrade the underlying Operating System, so you need to install a new server (and a new DAG if you are currently using one).
    As a side note, running Exchange 2019 CU14 on Windows Server 2025 is now also supported, including Domain Controllers on Windows Server 2025.
  • Support for TLS 1.3. Exchange 2019 CU15 supports TLS 1.3, but unfortunately, it is only supported by HTTPS for client use. TLS 1.3 for SMTP is not supported yet, but it is expected to be released in a future update.
  • Feature Flighting. This is also used in Microsoft 365 and allows for the gradual release of new features using so-called ‘rings’.
  • Certificate Management is available again in the Exchange Admin Console.
  • AMSI body scanning for anti-malware. Remote Code Execution malware is always post-auth, and it can be prevented using AMSI body scanning.
  • ECC Certificates (Elliptic Curve Cryptography) are now supported on the Edge Transport Server and for POP3 and IMAP4.
  • And important update: Exchange 2013 coexistence is not supported with Exchange 2019 CU15! This is hardcoded in the setup application! If you are still running Exchange 2013 and planning to move to Exchange 2019 you have to move to CU14 first and decommission Exchange 2013 before moving to CU15.
  • CU15 also includes all security updates that were released in the November 2024 Security Update and it includes the fix for the timezone issue.
  • And, of course, a lot of other issues are resolved in Exchange 2019 CU15.

Windows Server 2025

Exchange 2019 CU14 and CU15 are now supported on Windows Server 2025. Windows Server 2025 has some changes compared to earlier Windows versions, for example the SMTP stack and the legacy Web Management Console are no longer available.

As a result, the prerequisites have changed a little, unfortunately, the VC++ updates and the UC Managed API must still be installed, and the MSMQ must still be installed. The complete list of prerequisites can be found on Exchange Server Prerequisites.

Active Directory & Schema changes

There are no Active Directory Schema changes, so this remains at version 17003.

There are changes to the Configuration container, which is now at version 16763. To update the Configuration container, execute the following command from the Exchange 2019 CU15 installation media:

Setup.exe /PrepareOrganization /IAcceptExchangeServerLicenseTerms_DiagnosticDataOn

If you don’t want to send diagnostic data to Microsoft, you must replace the ‘On’ in the previous command with ‘Off’.

There are also no changes in the Domain partition, this version remains at 13243.

All information about Schema Changes can be found on Active Directory schema changes in Exchange Server.

TLS 1.3

TLS 1.3 is supported and enabled on Windows 2022 and Windows 2025. If you are still running Exchange 2019 on Windows 2019, you must install a newer version of Windows Server first.

Exchange 2019 CU15 will enable TLS 1.3 for new installations and for in-place upgrades. If you do not want this you can block this using the following registry, prior to installing Exchange 2019 CU15:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\V15\Setup" -Name "SkipTLS13ActivationDuringSetup" -Value 1 -Type String

Assuming you already have Exchange 2019 running and therefore have TLS 1.2 make sure all your servers, clients, applications, load balancers and device support TLS 1.3.

Enabling TLS 1.3 on your server consists of several steps:

  • Preparing .NET Framework to inherit defaults from Schannel
  • Enabling Strong Cryptography

To do this, run the following PowerShell commands:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord

Microsoft recommends to set the same registry keys for .NET Framework 3.5. Although this is not used in Exchange 2013 or later, it is recommended for an identical configuration. To do this for .NET Framework 3.5 inheritance, execute the following PowerShell commands:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -Type DWord

To enable TLS 1.3 for both Server and Client connections, execute the following PowerShell commands:

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" -Name "TLS 1.3" -ErrorAction SilentlyContinue
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3" -Name "Client" -ErrorAction SilentlyContinue
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3" -Name "Server" -ErrorAction SilentlyContinue
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client" -Name "DisabledByDefault" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client" -Name "Enabled" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server" -Name "DisabledByDefault" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server" -Name "Enabled" -Value 1 -Type DWord

Finally, to configure the cipher suites for TLS 1.3, execute the following PowerShell commands:

Enable-TlsCipherSuite -Name TLS_AES_256_GCM_SHA384 -Position 0
Enable-TlsCipherSuite -Name TLS_AES_128_GCM_SHA256 -Position 1

So, how do you know this works? The easiest way to find out is to use OWA and after logging on to a mailbox, start developer mode (using the F12 button) in your browser. Select ‘Security’ (when not available, click the + icon to select the security button) and check the connection as shown in the following screenshot:

As stated in the beginning of this blog, right now TLS 1.3 is only supported for HTTPS connections. Support for TLS 1.3 for SMTP will be available in a future update for CU15.

Feature Flighting

Feature Flighting is a new cloud-based solution for gradually deploying new features in Exchange Server . On the Exchange server, Feature Flighting uses a new service (MSExchangeFlighting) that checks the Office Config Service (OCS, the same endpoint that’s used for EEMS) every hour for new Feature Flight Definitions (FFD). Based on so-called ‘rings’, new features are deployed and activated. Feature Flighting is introduced in CU15, but there are no plans to release any features that can be ‘flighted’ into CU15. This will be available in Exchange Server SE.

Deployment and activation is based on ‘rings’ which define the action that must be taken when new features become available. The following rings are available:

RingName
0Early AdopterThis is the earliest ring and used for testing new updates. Updates are immediately activated after an update is installed.
1 (default)Worldwide RingDefault ring when an Exchange 2019 CU15 server is installed. Updates are received when Microsoft confirmed features are available for general availability.
2Admin ActionNew updates are not automatically enabled and it allows admins to roll-back newly enabled features. Features are shipped in a disabled state in this ring.

To view the ring level of your Exchange servers, execute the following command in Exchange Management Shell:

Get-ExchangeServer | select Name,RingLevel

And to change the ring level, execute a PowerShell command similar to this:

Set-ExchangeServer -Identity EXCH01 -RingLevel 2

To request features and their state, you can use the following PowerShell command:

Get-ExchangeServer -Identity CU15-1 | Select Name,RingLevel,Feature*
Name                          : CU15-1
RingLevel                     : 1
FeaturesApproved              : {}
FeaturesAwaitingAdminApproval : {}
FeaturesEnabled               : {PING.1.0}
FeaturesBlocked               : {}
FeaturesDisabled              : {}

More information regarding features can be retrieved using the Get-ExchangeFeature command:

Get-ExchangeFeature -Identity EXCH01

Server    FeatureID   RingLevel  Status    Description
------    ---------   ---------  ------    -----------
EXCH01    PING.1.0    1          Enabled   HeartBeat Probe. Validates the Telemetry Channel

When new features become available, they are listed in the FeaturesAwaitingAdminApproval property. To approve a new feature with a new like Feature.1.0, use a PowerShell command similar to the following:

Set-ExchangeFeature -Identity EXCH01 -FeatureID "Feature.1.0" -Approve

Likewise, to block this new feature, a command similar to the following can be used:

Set-ExchangeFeature -Identity EXCH01 -FeatureID "Feature.1.0" -Approve

Note. Feature Flighting is only available for Mailbox servers, not for Edge Transport servers or Management servers. The Mailbox server needs an internet connection since Feature Flighting updates are released online.

Exchange 2013

This is an important note if you are still running Exchange 2013. As of April 11, 2023, this version of Exchange is no longer supported. It is considered persistently vulnerable and, therefore, not supported in coexistence with Exchange 2019 CU15. This is hardcoded in the setup application! If you are still running Exchange 2013, you must first upgrade to Exchange 2019 CU14 and fully decommission Exchange 2013 before you can upgrade to Exchange 2019 CU15.

More information can found in Microsoft knowledgebase article KB5042461 and the download can be found at https://www.microsoft.com/en-us/download/details.aspx?id=106402.

As always, test all aspects of CU15 in a safe test environment to determine how it will impact your own environment. Better safe than sorry!

Exchange 2019 CU14 on Windows 2025

Last Friday, Microsoft released a blog post announcing a delay in the upcoming Exchange 2019 CU15, also known as Exchange 2019 H1 2025 CU.

This blog post also mentions support for Exchange 2019 CU14 running on Windows 2025, including Windows 2025 Domain Controllers. This can be very interesting if you are planning to move to Exchange 2019 CU15 and later this year to Exchange Server SE.

Installing CU14 on Windows 2025 works fine. The only difference is the prerequisite roles and features. Since Windows 2025 no longer supports the native SMTP stack and the legacy MMC snap-in, these need to be removed from the installation commands.

Use the following command to install the prerequisite roles and features:

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Core, NET-Framework-45-ASPNET, NET-WCF-HTTP-Activation45, NET-WCF-Pipe-Activation45, NET-WCF-TCP-Activation45, NET-WCF-TCP-PortSharing45, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS, Telnet-Client

The Telnet client is optional but can be very useful for troubleshooting purposes.

All other prerequisite software needed for CU14 is identical to Windows 2019 or Windows 2022 and so is installing the Exchange 2019 CU14 software itself.

Important note. Yesterday I had some issues installing the Security Update For Exchange Server 2019 CU14 SU3 V2 (KB5049233) and reported this to Microsoft. This morning I installed a new Windows 2025 server, installed all the prerequisites and Exchange 2019 CU14, and this time the SU installation succeeded without issues.

But as with every software update, test in your own lab before rolling out into production!

The Kerberos client received a KRB_AP_ERR_MODIFIED error

After starting an Exchange 2019 test environment, I noticed that several Exchange services would not start correctly. This happened on multiple Exchange 2019 servers. Sometimes, a reboot resolved it; sometimes, it went from all services running to several services not willing to start.

This particular test environment had four Exchange 2019 servers and three Windows 2022/2025 Domain Controllers in one Active Directory site.

On one Domain Controller I found several EventID 4 (Security-Kerberos) in the System Eventlog:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc01$. The target name used was P365\DC01$. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (P365LABS.NL) is different from the client domain (P365LABS.NL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Obviously, there’s a mismatch in system passwords. To resolve this, I used the following command:

netdom resetpwd /s:dc01 /ud:domain\administrator /pd:<domain admin password>

Reboot the Domain Controller, reboot the erratic Exchange server and everything is working fine again.