Servicing Exchange Server 2019

[The_Exchange_Team]

Last year, we announced changes to our servicing model for Exchange Server that moved to a servicing cadence of two Cumulative Updates (CUs) per year, releasing in H1 and H2 of each calendar year, with general target release dates of March and September. Our release dates are driven by the payload and quality, and other work that might take priority, such as releasing an SU.

Today we are announcing that because there are less than 2 weeks remaining in November, and because we don’t release CUs in December, there won’t be an H2 2023 CU. We took a similar approach last year.

There are only two more CUs to release, and both are only for Exchange Server 2019: CU14 and CU15, aka H1 2024 and H2 2024.

The CU14 release date slipped from this year to early next year. It will now likely be released in January 2024.  When CU14 is released, it will have lots of goodness in it, including support for TLS 1.3, an S/MIME control fix, Extended Protection on by default, and more. 

When CU14 is released in January, it will be after January 9, which means we are now delivering two CUs after the end of mainstream support for Exchange 2019.  This can be confusing, and you may wonder why we are releasing CUs for a product in extended support when we always say that products in extended support don’t get CUs.

There’s a nuance here. Using Exchange 2019 as an example, the end of mainstream support is on January 9, 2024.  That’s not the deadline for the release of CUs.  January 9, 2024, is the last date you can request a bug fix or a Design Change Request (DCR) and have the Exchange team consider it. We will accept requests for bug fixes and DCRs until Jan 9.  After that date, we will only consider security fixes. Anything filed on or before Jan 9 is fair game. And we might need some time to fix it.

So, we might have to release an update months after mainstream support has ended. In this case we will release not one, but two, CUs after the end of mainstream support. This is simply us making good on our customer promises.

The Exchange Team

[petersonal]

This announcement gives me questions like where is a supported on-premise product? Also in the cloud are "on-premise" products... and where is Exchange 2021 or 2024?? :(  Could you give us come comforting answers? Thank you

[kenmich350]

Any updates about vNext? Or could we expect for mainstream support to be extended?

[jvanbeusekom]

I think it is an strange course to release two new CU outside of mainstream support where at least, in the first has new features. While the then possible new introduced bugs could never be fixed if Microsoft does not think it is that important. 
My opinion is that if the mainstream support ends you cannot introduce new features. 

[Joseph1205]

Exchange Server 2019 is serviced twice a year through cumulative updates (CUs) containing security fixes, bug fixes, and new features. CUs are cumulative and can be installed manually or automatically. CUs typically address security fixes, bug fixes, and new features. In addition to CUs, Exchange Server 2019 is also serviced through monthly security updates (SUs) and time zone updates.

[Nino Bilic]

@petersonal - to be perfectly clear - both Exchange Server 2016 and 2019 will still be supported after January 9 2024. "Extended support" does not mean "no support". It means "no new features are considered after X date" and "security updates are still supported".

@kenmich350 - it won't be too long now that we will have more to say about what comes next, but the time is not here just yet.

@jvanbeusekom - In your hypothetical scenario, if we do release the "last" CU for Exchange Server 2019 and let's say that we did introduce a impactful regression, we would absolutely consider releasing a fix for it, of course. Remember, we have 3 types of release vehicles: SU (security updates) CU (cumulative updates which roll up all feature and security updates) and HU (hotfix updates, which can be feature fixes for a specific CU, not security related). So - we have enough levers to pull if we ran into this scenario.

[petersonal]

@Nino Bilic thank you, I do understand this, but 2025 is also not that far, when extended support ends. Then what? Nobody knows, or it is an inside information? If I would like to play/work with Exchange should I join the MS team in the near future? :)

[Nino Bilic]

@petersonal I get it; we will have more about what comes next soon (early next year).

[Skreabengt]

Why not take on board DKIM signing for Exchange Server on prem as new feature. I suppose quite a lot is using GitHub - Pro/dkim-exchange: DKIM Signing Agent for Microsoft Exchange Server today, since no native function exist.

Sometimes there is exceptions thrown "Event ID 1057: Agent 'Exchange DkimSigner' went async but did not call Resume on the new thread, while handling event 'OnCategorizedMessage'"

It does not seem to affect mail flow and Pro/dkim-exchange is doing its job pretty well, but is hardly updated anymore beyond v3.4.0 to fix the bug. I have no idea how to submit a Design Change Request (DCR) though.

[bbzome]

On MEC 2022, it was announced HMA for OWA Access. It still be a feature to be launched?

Video above, slide on minute 11m.

https://www.youtube.com/watch?v=Xo7Slig97wg&list=PLxdTT6-7g--2POisC5XcDQxUXHhWsoZc9&index=61

[arconicajanes]

This is good information, but it leaves alot to be desired. For example, if Exchange Server 2019 is ending mainstream support, then where is the replacement server version that is in mainstream support? It doesn't make any sense to leave us hanging like this, unless the plan is to force us off of on-premise products (the worst kept secret at Microsoft).

[admhb]

I understand that once the mainstream support ends, only the latest CU is supported. In this situation, when a new CU is released in 2024, the existing on-prem environment become unsupported instantly even if the environment has been "latest" before that moment, and the unsupported situation continues untill the new CU is fully installed. 

How should we consider supportability during this period? Any support request cannot be accepted?

[Skreabengt]

Having HealtChecker more intgrated into Exchange Server was a good improvement. Many IT-professionals probably already used that script long before the integration too, but now is update way more simple.

Signing your domain (DNSSEC) and adding TLSA Dane records is becoming more common as well as using SPF, DKIM, DMARC, HSTS and adding a MTA-STS policy. This will raise you security rating upon testing at Qualys SSL Labs, Check TLS, internet.nl, etc. Most of this except DKIM is configured at the registrar and the MTA-STS policy can be lodged anywhere e.g. on another internet facing server in your domain or at a third party. If signing the top-domain used for DNSSEC is not supported by your registrar, you can delegate configuration and use the name servers at a third party, e.g, Cloudflare. Having TLS 1.3 can either be met by the loadbalancer and/or by using Windows Server 2022.

All these features is working well for outbound mail in interactions with servers such as Google, Mimecast or Enterprise Outlook that support rejection of mail, if your MTA-STS policy is not met. Using a mail security monitoring service such as Mailhardener.com, MxToolBox.com, etc. will also ease the report checking for secure mail flow and warn if mail were rejected, possibly this can be mail sent by hostile and illegitimate servers trying to use your domain.

Constant monitoring on daily basis and ever ongoing security hardening is key these days!

The not yet supported features for inbound mail on Exchange Server on prem, and thus rejecting any mail not meeting the sending server's MTA-STS policy, is really expected. All this is normal software craftmanship that really is hard to understand why Microsoft has not implented yet. Please add these on the list for he future! Having fluffy cloud services or weird features noone ever heard of seem less important unless the basic things are in place first.

[Nino Bilic]

@arconicajanes As I already answered in comments, there will be more information soon. We have already committed to continue Exchange Server on-premises so unclear what is this worst kept secret you speak of. :)

@admhb Indeed. Exchange 2019 is a supported product. When a new CU is released, one of the CUs drops off from list of supported software immediately. You can of course still open support tickets on this particular server (because the version of Exchange is supported) but you cannot request a bug fix for an out of support version of CU and - depending on the issue at hand, you might get told to install a supported CU as a part of the support ticket to address the issue the ticket is about. In short - if you need help, our support team is there, but there are limited options compared to a product that is running a supported CU.

[Rickp784]

So, Exchange will support TLS v1.3 in H1 2024 (CU14).  Does that also presuppose you're running it on Windows Server 2022 to use it?  I don't think WinSvr2019 does.

[broland]

@The_Exchange_Team @Nino Bilic This is all good news, thanks for the update!  

Will Exchange 2019 (or the next version) ever support ECC security certificates?  

[Nino Bilic]

@broland We know folks are looking for ECC support and it is something we want to deliver. No commitments on versions / dates (this one does take a bit of coordination with other teams so it is not only up to us). When we have something specific to say, we will. =)

[Joseph1205]

Exchange Server 2019 is in extended support with limited updates (security fixes only). Two yearly CUs are planned, with the next one expected in March 2024. Use the Health Checker and Update Wizard to manage updates. Consider migrating to Exchange Online for continued support and new features. Remember to back up before updates and review release notes for known issues.

[StevenProvoC79]

@Nino Bilic Regarding your statement about a "Exchange vNext", when is "early next year" over for Microsoft? 

[Nino Bilic]

@StevenProvoC79 It is a very fair question. This is taking longer than expected because "reasons" but we are almost there.

[arconicajanes]

@Nino Bilic It would be nice if the Exchange team could keep us up to date on any updated timelines. Obviously, there are "reasons" you can't dive into. But, I don't feel like that means Microsoft can't give us a new best guess for a timeline.