Tag Archives: Exchange 2019

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.

Remove the last Exchange server

Removing the last Exchange server in a hybrid environment was announce more than 2 years ago with Exchange 2019 CU12 and Exchange 2016 CU23 (Released: 2022 H1 Cumulative Updates for Exchange Server) but finally I’m working with a customer that wants to do this, remove that last Exchange server in a hybrid environment.

This customer not in the process of decommissioning their datacenters yet, but they do want to decommission their last Exchange 2019 server (all their mailboxes are in Exchange Online). The Domain Controllers are still running on-premises, so the Exchange 2019 server is only used for management purposes (SMTP Relay is already moved elsewhere).

The first thing is to remove the Hybrid Configuration. I wrote about that in 2020, but the article is still valid: https://jaapwesselius.com/2020/12/15/remove-exchange-hybrid-configuration/.

The second step is to install the Exchange 2019 management tools. This can be on a Domain Controller or on a Management Server. To install the Exchange 2019 management tools, the Active Directory management tools, the Visual C++ Redistributable Package for Visual Studio 2012 and the IIS6 management tools must be installed first. Execute the following commands in an elevated PowerShell window:

PS C:\> Install-WindowsFeature rsat-adds,telnet-client
PS C:\> Enable-WindowsOptionalFeature -Online -FeatureName IIS-IIS6ManagementCompatibility, IIS-Metabase -All

The Exchange Management Shell is installed, when starting this it connects to an Exchange 2019 server. But when this server is not available the Exchange Management Shell fails. To work with Exchange PowerShell, open a regular Windows PowerShell and execute the following command:

PS C:\> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

This uses the Exchange PowerShell module that’s installed on the management server, but it does not connect anywhere, and it does not use any RBAC configuration.
When using this, the following Exchange PowerShell commands are available:

  • *-MailUser
  • *-MailContact
  • *-RemoteMailbox
  • *-DistibutionGroup
  • *-DistributionGroupMember
  • *-EmailAddressPolicy
  • Set-User and Get-User

When enabling an existing user account with a mailbox in Exchange Online, you can use the Get-User command and pipe it to the Enable-RemoteMailbox command, like this:

PS C:\ > Get-User JaapICT | Enable-RemoteMailbox -RemoteRoutingAddress JaapICT@contoso.mail.onmicrosoft.com

The Remote Mailbox will be created and all properties will be set correctly, including the email address conforming to the existing Email Address Policy. This is clearly visible when requesting the properties of the mailbox:

PS C:\> Get-RemoteMailbox -Identity JaapICT | select name -ExpandProperty EmailAddresses

Name               : JaapICT
AddressString      : C=NL;A= ;P=Corporation;O=Contoso;S=JaapICT;
ProxyAddressString : X400:C=NL;A= ;P=Corporation;O=Contoso;S=JaapICT;
Prefix             : X400
IsPrimaryAddress   : True
PrefixString       : X400

Name               : JaapICT
SmtpAddress        : JaapICT@Contoso.com
AddressString      : JaapICT@Contoso.com
ProxyAddressString : SMTP:JaapICT@Contoso.com
Prefix             : SMTP
IsPrimaryAddress   : True
PrefixString       : SMTP

Name               : JaapICT
SmtpAddress        : jaapict@Contoso.mail.onmicrosoft.com
AddressString      : jaapict@Contoso.mail.onmicrosoft.com
ProxyAddressString : smtp:jaapict@Contoso.mail.onmicrosoft.com
Prefix             : SMTP
IsPrimaryAddress   : False
PrefixString       : smtp

Now everything is working the last Exchange 2019 server can be removed. What I normally recommend is to disable all Exchange services on the server and leave it running for one or two weeks. If any issues arise it is easy to start the Exchange services again and fix the problem.

When nothing bad happens, you can remove the last Exchange server. After disabling the last mailboxes and removing the Mailbox Databases and Send Connectors, turn off the Exchange 2019 server. DO NOT UNINSTALL Exchange 2019, but shutdown the Exchange 2019 and remove the server. That is, delete the VM or reconfigure the bare metal server with something else, but DO NOT UNINSTALL the Exchange 2019 server. The management tools that are installed still use configuration settings in Active Directory.

From this moment on you must manage your recipient in Exchange Online using the on-premises management server where the Exchange Management Tools are installed (I say on-premises server, but this can also be a VM in Azure of course, as long as it is a domain joined server you are good).

Exchange vNext will be Exchange Server Subscription Edition

Today Microsoft silently released an update to their Exchange roadmap, which includes information regarding Exchange 2019 CU15 and Exchange vNext. You can read all the Microsoft marketing stuff on the Exchange Server Roadmap Update article.

What’s new is that vNext is rebranded to Exchange Server Subscription Edition, just like we have Sharepoint Subscription Edition.

The most important part about Exchange Server Subscription Edition is that it is ‘code equivalent’ to Exchange 2019 CU15. So, if you have Exchange 2019 CU15 running later this year, then updating to vNext is just a matter of an in-place upgrade. There’s one thing we need to look out for, the underlying Operating System. If you install CU15 on Windows Server 2022 (or worse, on Windows Server 2019) and SE only supports Windows Server 2025 we will be very unhappy 🙂

What are new features in Exchange 2019 CU15 and thus Exchange Server SE?

  • Support for TLS 1.3 (which was planned for CU14).
  • Certificate management in the Admin Center.
  • Removal of the UCMA (makes sense, since there won’t be any support for Unified Messaging.
  • Removal of the MSMQ components in the setup application (MSMQ components are not needed in earlier versions of Exchange 2019, please check the Exchange 2019 requirements article).
  • Re-introducing certificate management in the Admin Center.

So, when can we expect Exchange Server Subscription Edition? As Exchange Server SE is identical to Exchange 2019 CU15 (in will include the necessary security updates of course) the only difference is the licensing of Exchange Server SE. You need a subscription license for the server, and old Client Access Licenses are no longer supported and you can use the regular Office 365 licenses for clients.

Microsoft states it will be available early Q3 2025, which means early July 2025. Since support for Exchange 2016 and Exchange 2019 will end in October 2025 Microsoft cannot afford to slip this date since you need sufficient time to upgrade from earlier versions of Exchange server.

What’s also interesting is that Microsoft is already releasing information about Exchange Server SE CU1, which should be released by the end of 2025 (can slip though).

The most interesting features in Exchange Server SE are Kerberos authentication for server-to-server authentication, the removal of Outlook Anywhere and the deprecation of Remote PowerShell. This brings Exchange server SE nicely inline with Exchange Online.

There’s one very important announcement Microsoft makes: Exchange server SE CU1 will stop supporting co-existence with ALL PREVIOUS VERSIONS of Exchange server. So, this means that in that timeframe, only Exchange Server SE CU1 (and later) will be supported and all previous versions of Exchange server must be removed from your environment.

Exchange Server SE is still approx 18 months away from now, but it is time to start thinking about your Exchange environment. Do you want to fully move to Exchange Online, or do you want to keep mailboxes on-premises in Exchange Server? If so, it’s time to start working on moving to Exchange 2019 CU14 and upgrade to CU15 later this year (or skip CU14 and move directly to CU15).

It is not a strange idea, I’m currently working with three large Exchange 2016 on-premises deployments to move them to Exchange 2019 and prepare for Exchange server SE.

So, lots of work to do the upcoming 18 months 🙂