Top 3 Myths about Exchange Server Subscription Edition
Over the last few months, several myths about Exchange Server Subscription Edition (SE) have been circulating online. From what I have seen, the top 3 myths are: Exchange Server SE RTM includes new features. Exchange Server SE will be updated like the Cloud. Exchange Server 2016 customers must move to Exchange Server 2019 to upgrade to Exchange Server SE. None of these things are true, but unfortunately, they keep being repeated. Let's dive into each of them. Myth #1: Exchange Server SE RTM includes new features The first myth is that Exchange Server SE includes new features. This is not true, and Microsoft's https://learn.microsoft.com/exchange/new-features/new-features makes this clear. In fact, it was always our plan to intentionally not include any features in the RTM release of Exchange Server SE. In my https://www.amazon.com/dp/B0FR5GGL75/ and my talks about it at the https://www.exchange-summit.de/ and https://www.ntk.si/en/schedule/237 last year, I provided insight into the RTM release of Exchange Server SE, so I won't go into that here. But I will explain why Exchange Server SE RTM doesn't include new features (or any other substantive code changes). When we decided to move the release of Exchange Server SE RTM to the second half of 2025, we knew we were significantly reducing the overlap between supported versions to about 106 days. We also knew that even with in-place upgrade capabilities, customers still needed time to validate the release. To help make that validation as quick and easy as possible, our plan was to make the RTM release code equivalent to the last released update for Exchange Server 2019, with only necessary branding and licensing changes. Last released update meant the last Cumulative Update (CU) for Exchange Server 2019 plus any Security Updates (SUs) or Hotfix Updates (HUs) released after the last CU but before the SE RTM release. Internally, we described the SE RTM release as a "soft CU for Exchange Server 2019" to help business, engineering, support, and community stakeholders better understand what we were doing. Eventually, senior leadership approved our plan, which the engineering team then executed flawlessly. As a side note, because Exchange Server and https://aka.ms/sfbb are developed and released by the same engineering team, Skype for Business Server SE took the same approach with their RTM plans and release. In the end, we committed to the SE RTM release being the same exact code as Exchange Server 2019 CU15, plus the two post-CU15 updates released before SE RTM (namely, the April 2025 and May 2025 HUs). This meant that customers running Exchange Server 2019 with the May 2025 HU experienced only: A name change from Exchange Server 2019 to Exchange Server Subscription Edition; A new License Agreement file (License.RTF), which is shown only during the GUI version of Setup; and A new build number that was incremented using the Exchange Server 2019 numbering scheme. Aside from that, when compared to Exchange Server 2019 CU15 plus the May 2025 HU, there are no changes in Exchange Server SE. Despite making this clear in numerous blog posts and documentation, some authors have posted articles that list "new" features in Exchange Server SE, citing support for Windows Server 2025, TLS 1.3, and OAuth 2.0 (aka Modern Auth), and new certificate management capabilities. These "new" features were all available in Exchange Server 2019, and other cited features were available in Exchange Server 2016 and earlier versions. That said, there are only two other changes that apply to Exchange Server SE: Lifecycle Policy and Support Policy. Both are outside the product and they are related. Lifecycle Policy changes Previous versions of Exchange Server were covered under Microsoft's https://learn.microsoft.com/lifecycle/policies/fixed, which has phases such as Mainstream Support and Extended Support as well as published (and fixed) dates for end of support (the Beyond End of Support phase aka End of Life). Exchange Server SE is covered under Microsoft's https://learn.microsoft.com/lifecycle/policies/modern, which does not have any support phases or published end of support dates. Exchange Server SE will have at least a 10½-year lifecycle because Microsoft has https://learn.microsoft.com/lifecycle/additional-support-server-modern-lifecycle-policy to supporting Exchange Server SE (as well as SharePoint Server SE and Skype for Business Server SE) until at least December 31, 2035, a few months shy of the 40th anniversary of Exchange Server! Under the Modern Lifecycle Policy, Microsoft also commits to provide a minimum of 12 months' notice before ending support for Exchange Server SE (and it would not surprise me to see the Office Servers eventually added to list of products on the https://learn.microsoft.com/lifecycle/policies/3-year-subset). Support Policy changes Historically, Microsoft's support stance has been based on where a product is in its lifecycle. For example, when Exchange Server 2013 was in Mainstream Support, Microsoft supported N-1, where N is the latest CU and -1 is the immediately previous CU. When Exchange Server 2013 moved into Extended Support, only the latest CU was supported. Exchange Hybrid environments have always been an exception to this, as Microsoft supports only the current CU in Hybrid environments. The change from the Fixed Lifecycle Policy to the Modern Lifecycle Policy means that Microsoft's support stance is more fluid. The Modern Lifecycle Policy says: "Customers must stay current as per the servicing and system requirements published for the product or service." This means that Microsoft can change the support requirements for Exchange Server SE as needed, but you should not expect them to pull the rug out from under you. Rather, you should expect their changes to be to your benefit, as previously demonstrated by their support for both CU15 and CU14 while Exchange Server 2019 was in Extended Support. So, if Microsoft releases a CU that contains a large payload or other significant changes, they may opt to take an N-1 support stance to give customers plenty of time to test and deploy it. Conversely, it's also possible that Microsoft could require customers to deploy an update immediately to fix a critical security issue or a significant bug (for example, a bug known to cause data loss). Regardless of the changes to Microsoft's support stance, my general advice is to evaluate and deploy all updates (especially SUs) as quickly as possible. Don't skip testing or validation, but do make installing updates, keeping Windows and Exchange current, and monitoring your Exchange servers a top priority. Myth #2: Exchange Server will be updated like the Cloud The second myth has to do with how Exchange Server will be serviced by the engineering team (and updated by customers). The move to the Modern Lifecycle Policy includes some language that may be helping to perpetuate this myth: "The Modern Lifecycle Policy covers products and services that are serviced and supported continuously." Servicing generally means updating the code and providing release packages for customers to install. Serviced and supported continuously refers to the evergreen type of model now used by Exchange Server (and other Microsoft products) which simply means instead of major releases and version upgrades, Microsoft will simply service the product via periodic updates. In the past, Microsoft released a new major version of Exchange Server roughly every 2-4 years. With the release of Exchange Server SE, there are no more major version releases. Instead, Exchange Server will be maintained in an evergreen fashion. Code updates for Exchange Server include the following package types: CU - a full-product package containing a specific build (e.g., RTM, CU1, CU2, etc.). SU - a recommended security-related hotfix package HU - an optional non-security hotfix package IU - a customer-specific fix packaged as an Interim Update CUs, SUs, and HUs, are cumulative, so you need only install the latest package. HUs are optional updates, but I recommend always reviewing HU release articles to see if they might introduce features or fixes that might benefit your organization. When Microsoft releases one of these packages, they will announce it on the https://aka.ms/EHLO and provide download links, and update the https://learn.microsoft.com/exchange/new-features/build-numbers-and-release-dates of build numbers and release dates for Exchange Server. I think the use of the word continuously in Modern Lifecycle Policy is causing confusion. The reality is that Exchange Server SE uses the same servicing model that Exchange Server 2019, Exchange Server 2016, and Exchange Server 2013 have used since April 2022, and no changes to this model have been made (or are expected). Microsoft has already announced the general plan for the first two CUs for Exchange Server SE that will both release in 2026 (in H1 and H2, respectively). Security work always takes precedence over non-security work, and there have been many times when Microsoft has released only one Exchange Server CU per year (including in 2024, 2023, and 2022). So, no, Exchange Server SE won't be updated by Microsoft like the cloud (nor will it get most cloud features). Myth #3: Exchange Server 2016 customers must move to Exchange Server 2019 to upgrade to Exchange Server SE The third myth is about upgrading to Exchange Server SE from Exchange Server 2016. This myth is concerning but understandable. Concerning, because it might cause (and might have caused) some customers to waste time and money. Understandable, because in the past it was guidance from Microsoft; but that guidance is now out-of-date and no longer applies. Some background and detail will help explain why. Exchange Server 2019 reached general availability on October 22, 2018. Despite the many improvements and benefits, Exchange Server 2019 was not well-adopted, likely because at the time Microsoft was leaning heavily into a cloud-first world. In fact, you could make an argument that when Exchange Server 2019 was released, Microsoft did everything it could to make sure no one used it. If you look at the https://web.archive.org/web/20181120140237/https:/products.office.com/en-us/exchange/email?rtc=1, it didn't even mention Exchange Server 2019. This led a lot of customers to think that our goal was to kill Exchange Server, or at the very least, ignore it to death. In the aftermath of the Hafnium attacks against Exchange servers, we learned that there were hundreds of thousands of servers around the world running unsupported builds, or supported but old and vulnerable builds, and that a very small percentage (~5%) were running Exchange Server 2019. Of the supported versions, patching levels were all over the place, with literally every build we had released still in use somewhere, including RTM builds of each major version. After Hafnium, we spent more than a year figuring out what to do with the next version of Exchange Server, and it was during that time that an entirely new plan for Exchange Server SE was developed (along with a new codename: Quantum Lobster). During planning, we intentionally went radio silent on the next version of Exchange Server (aka Quantum Lobster), making https://youtu.be/Q5iwvrrqQpA in September 2020, the last that anyone outside of Microsoft heard about the next version of Exchange Server for almost 2 years. During those 2 years, we continued telling customers that wanted to run Exchange Server to move to Exchange Server 2019. Not because it was the latest version, but because that's where we were still investing in security and features (such as custom configuration backup and support for Windows Server 2025 and TLS 1.3). Eventually, on June 2, 2022, we broke radio silence on the next version of Exchange Server, and among other things, we repeated our multi-year call-to-action to move to Exchange Server 2019, telling customers that once on Exchange Server 2019 they would be able to do a quick and easy in-place upgrade to Exchange Server SE RTM. In other words, Microsoft had been telling customers for years to move to Exchange Server 2019 to enable a quick and low-risk in-place upgrade to Exchange Server SE RTM when it releases. This message was further refined to focus on Exchange Server 2016 customers for two reasons: Exchange Server 2013 reached end of support, and as an Awareness Action, we changed Setup in CU15 to prevent installation if Exchange Server 2013 was present in the organization; and Exchange Server 2016 had a notable (and for a brief time, the largest) percentage of the visible install base. Circling back to the What's New article I mentioned earlier, this https://learn.microsoft.com/exchange/new-features/new-features#whats-new-when-upgrading-from-exchange-2016-to-exchange-se has an Important note about upgrading that says: "In-place upgrades from versions of Exchange Server earlier than Exchange Server 2019 are not supported. You must first perform a legacy upgrade to Exchange Server 2019 CU14 or CU15 before upgrading to Exchange Server Subscription Edition (SE). Alternatively, a legacy upgrade to Exchange Server SE is also supported." It seems that some may have read the first two sentences in the note and ignored the rest, as there are a lot of articles and posts that state that to move from Exchange Server 2016 to Exchange Server SE, you must first do a legacy upgrade from Exchange Server 2016 to Exchange Server 2019, and then do an in-place upgrade to Exchange Server SE. But that guidance was rendered obsolete with the SE RTM release and should no longer be followed. There is absolutely no reason to do two upgrades (legacy + in-place) when a single upgrade (legacy) from Exchange Server 2016 to Exchange Server SE can be done. In fact, the legacy upgrade process from Exchange Server 2016 to Exchange Server 2019 or Exchange Server SE is exactly the same! The https://m365accelerator.microsoft.com/exchange (aka the https://aka.ms/ExDeploy) are helpful when performing a legacy upgrade from Exchange Server 2016 to Exchange Server SE. If you're still running Exchange Server 2019 or earlier, I encourage you to remediate that as quickly as possible (even if you are in the Extended Security Update program) by upgrading to Exchange Server SE or by moving to Exchange Online. Conclusion Hopefully, you now understand the truth behind the top three Exchange Server SE myths discussed in this article and why they are myths. But as I said in the beginning, these aren't the only myths being perpetuated. What else have you seen/read? What other myths would you like busted? Drop a comment and let me know!
Exchange SE HTTP 500 error
Hi Everyone, Been having this weird thing with 2 new Exchange SE installs. Both of them when trying to sign into ECP get a HTTP500 error once I've entered credentials Not really sure where to go, looked in IIS, checked the bindings, checked event viewer, services I expect to be behind this look to be running. Anyone else come across or have any solves? Thank youRequest on Exchange Server SE CU1 Codebase and Trial Version Behavior
Dear Microsoft Exchange Team and Community, I have questions about Exchange Server Subscription Edition (SE): Codebase of Exchange SE CU1 vs. Exchange 2019 CU15 The roadmap says Exchange SE RTM matches Exchange 2019 CU15 codebase, with new features starting in SE CU1. Is SE CU1 a standalone codebase or a direct continuation of Exchange 2019 CU15 with added features? Behavior after Exchange SE trial expiration What happens when the SE trial expires? Are all functions fully retained? Are any services or features restricted or disabled? Will the server remain usable? Thanks for your clarification!
Automatic redirection of Exchange ActiveSync On-Pre
I am migrating mailboxes between on-premises Exchange forests using ADMT automated calls in SC Orchestrator 2019. Prepare-MoveRequest Migrate-ADMTUser MoveMailbox Set-Resources Has anyone already done the automatic redirection of Exchange ActiveSync in the following scenario: Moving mailboxes between on-premises Exchange organizations. I know the link below says it is not possible, but I would like to know if anyone has overcome this limitation? https://learn.microsoft.com/pt-br/exchange/activesync-settings
