Recent Discussions
Reporting Recent Distribution List Changes
A recent discussion about reporting changes to Microsoft 365 groups provoked the question about how to report distribution list changes. The answer is that the same structure can be taken in a PowerShell script to fetch and report data, including the audit records containing the information about the changes, but the actual code is very different. Distribution lists Exchange Online objects and not Entra ID groups… https://office365itpros.com/2026/06/02/distribution-list-changes/HVE for Microsoft 365: When to Use It, When Not To, and Who Should Be Allowed to Send at Scale
Microsoft recently announced the General Availability of High Volume Email for Microsoft 365, also known as HVE, in Exchange Online. This is an important and long-awaited capability for organizations that need to send large volumes of internal email from applications, devices, or line-of-business systems without using regular user mailboxes as bulk-sending engines. But HVE should not be misunderstood. It does not mean that every mailbox in Exchange Online should now be used for mass email. It does not mean Exchange Online has become a general-purpose marketing platform. And it does not remove the need for proper outbound email governance. Why HVE Matters For years, many organizations have used regular Exchange Online mailboxes, shared mailboxes, or service accounts to send automated messages from applications, scanners, monitoring platforms, ticketing platforms, and custom business applications. That approach creates several problems. Standard mailboxes are designed for human and business communication, not for sustained high-volume automated traffic. Exchange Online has recipient limits, message rate limits, outbound spam protections, and tenant-level controls to protect the service and reduce abuse. HVE introduces a more appropriate model for specific high-volume scenarios. Instead of using a normal mailbox for automated traffic, organizations can create dedicated HVE accounts and use specific SMTP endpoints, admin controls, reporting, and governance for approved high-volume internal messaging scenarios. What HVE Is Designed For HVE is designed for automated, operational, and transactional messaging at scale, primarily for internal recipients within the tenant. Examples include: Internal application notifications. Line-of-business system messages. Device-generated messages. Operational alerts. Security advisories. Internal workflow communications. Monitoring platform alerts. IT service notifications. Large-scale internal announcements generated by systems. This is especially relevant when the organization needs to send messages at scale but still wants to keep the workload within Microsoft 365 governance and Exchange Online mail flow. In practical terms, HVE is useful when the sender is not a human user, but a controlled business system. What HVE Is Not HVE is not a replacement for marketing platforms. HVE is not a general-purpose internet bulk email engine. HVE is not a way to bypass Exchange Online sending limits for external campaigns. HVE is not the correct platform for newsletters, promotional campaigns, large-scale customer communication, or high-volume external transactional email. For external transactional, marketing, or customer-facing bulk email, organizations should evaluate platforms designed for that purpose, such as Azure Communication Services Email, SendGrid, Amazon SES, Mailchimp, Brevo, or another specialized delivery platform. When to Use HVE Use HVE when the workload matches these characteristics: The sender is an application, device, service, or business system. The recipients are primarily internal users in the Microsoft 365 tenant. The volume is higher than what should be sent from a standard mailbox. The workload is operational, automated, or transactional. The organization needs centralized Microsoft 365 administration and reporting. The organization wants to avoid impacting user mailbox sending limits. The use case is approved, documented, monitored, and governed. Good examples: A security platform sending internal security advisories. A monitoring system sending infrastructure alerts to internal teams. A business workflow system sending high-volume approval or status notifications. An IT service platform sending internal notifications. A service management platform sending ticket updates to internal users. A device management system sending operational messages to internal teams. When Not to Use HVE Do not use HVE when the workload is external bulk email. Avoid HVE for: Marketing campaigns. Newsletters to customers. Promotional email. Mass external invitations. External transactional email at scale. Customer invoices and receipts in high volume. OTP or password reset flows for external users. External portal notifications. Any workload where deliverability, bounce handling, reputation management, unsubscribe handling, analytics, or customer consent management are required. Those workloads require a platform designed for external delivery, reputation management, suppression lists, opt-out, tracking, bounce handling, and compliance. Who Should Be Allowed to Use HVE HVE should not be enabled casually for every team or every application. It should be treated as a controlled platform capability. Recommended eligible senders: Approved line-of-business applications. Corporate systems owned by IT, Security, Operations, Facilities, or Service Management teams. Managed devices or services with a clear business purpose. Internal platforms that send operational messages to employees. Applications with documented ownership, authentication, monitoring, and expected volume. Recommended non-eligible senders: Normal users. Shared mailboxes used by humans. Marketing teams sending to external audiences. Unmanaged scripts. Legacy systems with no owner. Applications with unknown volume. Systems that send to external recipients at scale. Any application using HVE just to avoid standard mailbox limits. The core principle is simple: HVE should be enabled for workloads, not for convenience. Governance Model Before enabling HVE, organizations should define a governance model. At minimum, each HVE account should have: A named business owner. A technical owner. A documented purpose. Expected daily and monthly volume. Recipient scope. Authentication method. Monitoring process. Incident response path. Decommissioning criteria. Review frequency. HVE accounts should not become invisible service accounts that nobody owns. They should be treated as privileged communication identities. Security and Authentication HVE supports OAuth authentication, and Microsoft provides guidance for restricting OAuth authentication to specific Microsoft Entra ID applications. This is important because organizations should avoid broad, uncontrolled access. They should restrict which applications can send through each HVE account, monitor usage, and separate workloads by purpose. For example: One HVE account for security alerts. One HVE account for monitoring systems. One HVE account for IT service notifications. One HVE account for internal operational communications. This separation improves visibility, investigation, accountability, and risk containment. HVE vs Standard Exchange Online Mailboxes A standard Exchange Online mailbox should be used for normal human communication. A shared mailbox should be used for collaborative business processes. An HVE account should be used for approved high-volume internal system email. A dedicated external delivery platform should be used for marketing, bulk external communication, or high-volume transactional email. Scenario Recommended Platform Human business email Exchange Online mailbox Team or department mailbox Shared mailbox Low-volume application notifications Standard Exchange Online, if approved High-volume internal system notifications HVE Internal operational alerts at scale HVE Marketing campaigns Marketing platform External transactional email Transactional email service Customer newsletters Marketing automation platform OTP/password reset for external users Dedicated transactional platform External bulk email Dedicated bulk email provider HVE and the Mailbox External Recipient Rate Limit Cancellation Microsoft also announced that the Mailbox External Recipient Rate Limit in Exchange Online was cancelled indefinitely. However, that cancellation should not be interpreted as permission to use Exchange Online for uncontrolled bulk sending. Microsoft was clear that other limits remain unchanged, including the existing Recipient Rate Limit and the Tenant-level External Recipient Rate Limit. That distinction is important. The cancellation of one mailbox-level external recipient limit does not remove the need for proper architecture. Exchange Online still has service limits. Outbound spam controls still apply. Tenant-level protections still matter. And HVE is still not a marketing engine. Practical Architecture Decision Before enabling HVE, ask these questions: Who is sending? Is the sender a human, shared mailbox, application, or device? Who are the recipients? Are they internal or external? What is the expected volume? Is the workload operational, transactional, promotional, or human communication? Does the business need Microsoft 365 mail flow and governance? Does the use case require bounce handling, unsubscribe, tracking, or reputation management? Is the application properly authenticated and monitored? Who owns the account? Who approves the sending pattern? Who responds if the account is abused? If the workload is internal, automated, high-volume, and business-approved, HVE may be the right answer. If the workload is external, promotional, customer-facing, or marketing-driven, use a dedicated email delivery platform. Recommended Enablement Approach Organizations should enable HVE in phases. First, identify existing systems currently using user mailboxes, shared mailboxes, or SMTP AUTH for automated sending. Second, classify each workload as internal, external, operational, transactional, marketing, or human communication. Third, migrate only approved internal high-volume workloads to HVE. Fourth, move external high-volume workloads to dedicated email delivery platforms. Fifth, monitor usage and review HVE accounts regularly. This avoids turning HVE into another uncontrolled sending layer. Conclusion High Volume Email for Microsoft 365 is an important addition to Exchange Online. It gives organizations a native way to support high-volume internal system messaging without using standard mailboxes for automated high-volume traffic. But HVE is not a free pass for bulk email. It is not a marketing platform. It is not a replacement for transactional email services. And it should not be enabled for every mailbox or every application. The right approach is workload classification. Use Exchange Online for corporate communication. Use HVE for approved high-volume internal system messaging. Use dedicated platforms for external bulk, marketing, and transactional email. The question is not only: “Can this system send email through Microsoft 365?” The better architectural question is: “What type of email is this, who is the audience, and what is the correct platform for this workload?” That is where proper email architecture begins.
Offboarding mailboxes fails with “PropTagToPropertyDefinitionConversionException.”
Hybrid M365 setup, just recently upgraded the on-prem server from Exchange 2019 to Exchange SE. After doing so, migrations from Exchange Online back to Exchange On-prem fail at 10% with the error “PropTagToPropertyDefinitionConversionException.” I opened a case with M365 exchange support, and after some time, they came back to tell me that the Exchange Online portion of the process is not at fault, and that I have to engage the on-premise support team (this seems a little nuts to me, as its all connected and all supported, but I've been in this business for 30 years now, and it's not the first time I've seen buck-passing), and/or ask this community for help. Hence, this post. That error appears exactly two places on the internet, as far as I can tell: a blog (in German) from an Exchange expert doing cross-tenant migrations, and a page at https://west.jcteams.info/bhit11/docs/EX1232513.html that seems to describe my exact issue. Neither had useful suggestions - mostly, they say this: Set-MoveRequest -Identity "<UserPrincipalName>" -SkipMoving FolderRestrictions Resume-MoveRequest -Identity "<UserPrincipalName>" That didn't actually work, but when I tried the same parameters with Set-MigrationBatch, they worked as long as I ignored the message "The SkipMoving parameter is deprecated. Use the MoveOptions parameter instead. If you have any scripts that use the SkipMoving parameter, update them to use the MoveOptions parameter." So what was a simple process is now a more cumbersome workaround. Does anyone have an idea on how to troubleshoot "PropTagToPropertyDefinitionConversionException?"
Cross Tenant Migration licensing
Hello, I'm planning a native cross-tenant migration for several shared mailboxes that have archives enabled. I’m looking to confirm if it is necessary to temporarily convert these to user mailboxes in the source to ensure the archive data migrates successfully. Also, what specific licenses should I assign to the target objects specifically, do I need to provide an Exchange Online Plan 2 plus the Cross-Tenant User Data Migration add-on for each shared mailbox? If anyone has handled archived shared mailboxes recently, I’d appreciate a quick confirmation on the cleanest licensing and conversion steps. Thank you in advance ! :)Exchange Online to Deprecate Legacy TLS for POP3 and IMAP4
Microsoft will start to refuse inbound IMAP4 and POP3 client connections using legacy TLS versions (1.0 and 1.1) in July 2026. The move is consistent with other projects to remove obsolete or insecure email protocols from Exchange Online to increase the overall security of the online email service. In this article, we examine some methods to understand the POP3 and IMAP4 usage within a tenant. https://office365itpros.com/2026/04/29/legacy-tls-removal/Permission activesync on smartphone
Hi everyone, when you grant the permissions in question to manage company email from a smartphone, do these permissions, in addition to Remote Wipe, Password Enforcement and Device Encryption (I remember these as the main ones), somehow give the Exchange administrator access to my personal data? For example, photos, any documents saved on the SD card or on the smartphone itself? Thanks in advanced!High Volume Email is Generally Available and Ready to Charge
On April 1, Microsoft announced the general availability for the High-Volume Email (HVE) solution together with details of the PAYG charges incurred to send email to internal recipients, which is all that HVE can do. Microsoft will enable HVE charging on June 1, 2026, Before then, you’ll need to create a billing policy and link it to a valid Azure subscription if you want to continue to use HVE. https://office365itpros.com/2026/04/23/hve-ga-charging/Microsoft Limits App Access to Sensitive Message Properties
Microsoft has announced details of a change to app permissions to restrict updates to sensitive message properties (like recipients) without consent for a new advanced mail access permission. If tenants have apps that interact with message properties, including apps developed by third parties, they should check whether the apps are updating sensitive properties. If so, the new permission must be assigned or the apps will stop working. https://office365itpros.com/2026/03/26/sensitive-message-properties-graph/Can we hide default address lists in Outlook Address Book and show only custom ones?
There are existing Custom Address Lists. When users use the MS Outlook App (Office 2019) and open the Address Book, is it possible to hide the other address lists (including domain-sg-GAL, Global Address List, and domain-sg-Rooms), and only display the Custom Address Lists (domain-HK-AL and domain-sg-AL) — the ones shown in green in the photo?Microsoft Rushes High-Volume Email to General Availability
Almost two years after it first previewed, Microsoft is making the High-Volume Email (HVE) solution generally available in March 2026. HVE runs on a pay-as-you-go basis, but Microsoft won’t start charging tenants for sending email until May 2026. Two months should be enough for people to decide if they want to use HVE for internal communications as it has no ability to send external email. https://office365itpros.com/2026/03/09/hve-ga/Measuring KPIs like Response Times for Shared Mailboxes
Shared mailboxes are not CRM systems. However, many Microsoft 365 tenants use shared mailboxes to handle customer queries and then want to measure KPIs such as agent responsiveness to customer queries or the number of queries handled per agent in a month. As explored in this article, it’s possible to use the Microsoft Graph and PowerShell to extract some KPI-like data from shared mailboxes. https://office365itpros.com/2026/03/05/shared-mailbox-kpi/
Proper whitelisting of microsoft.com on dnswl.org
I keep having the issue that system-generated e-mails, e.g. on Trace Reports get classified as spam by the receiving e-mail provider. The sender address is email address removed for privacy reasons and the e-mails go to my M365 mailbox and are redirected to my external monitoring mailbox with that e-mail provider. The e-mail provider calculates a score that includes checking the sender's IP address 52.101.69.91 with dnswl.org . Unfortunately, that address is only whitelisted for outlook.com and some secondary domains, but not for microsoft.com. Of course, the issue also occurs with mailto:email address removed for privacy reasons and other IP addresses, so this is an example. It started to occur around two weeks ago, not sure if the provider changed policies or Microsoft changed the whitelisting; of course the provider refuses to overrun dnswl.org it, e.g. by own whitelisting. Who at Microsoft could I ask to fix that kind of issues? I don't find any appropriate category in their support menues, M365 support says the cannot help (TrackingID#2603031420001611). Thanks in advance for any hints, this is my first posting here, so please forgive me, if this is a dumb question.Exchange Online PowerShell Dumps the Credential Parameter
On February 12, Microsoft announced the deprecation of the Credential parameter for the Connect-ExchangeOnline cmdlet in the Exchange Online PowerShell module. The deprecation won’t affect interactive sessions (which should all be protected by MFA), but it might stop some background jobs running when Microsoft retires the server components that currently support the ROPC authentication flow. Time to check scripts! https://office365itpros.com/2026/02/16/exchange-online-powershell-ropc/The Final Countdown to Remove EWS from Exchange Online Begins
Microsoft announced the dates leading to the final retirement of Exchange Web Services from Exchange Online. If all goes well, the EWS retirement in the cloud will happen by May 2027. Challenges still exist. Microsoft must remove EWS from its own apps, including Outlook, and help tenants and ISVs make the leap to Graph APIs. Plans are in place and progress is being made, but will everyone be ready when Microsoft starts to remove EWS permanently from Exchange Online in April 2027? https://office365itpros.com/2026/02/06/ews-retirement-may-2027/Using the Exchange Online Message Trace API
January 22 saw the announcement of the beta version of an Exchange Online Graph-based message trace API. The API can retrieve message trace records and their details and offers equivalent functionality to the message trace cmdlets in the Exchange Online management PowerShell module. However, sometimes applications simply want to access data without going through a module, and that’s what this API delivers. The article includes a complete PowerShell script to demonstrate how to use the API. https://office365itpros.com/2026/01/27/message-trace-api/
Modern Auth EWS error 50199 when signing from Crestron Touchpanels
Good Afternoon, All I am having a difficult time nailing down this issue. I have a few Crestron TTS-770s that were, up to last week, working correctly by pulling Calendars data with EWS. They were configured with a service account signed into EWS using 'modern authentication'. This week, these panels have disconnected and report that 'Needs to be authorized' as the EWS status. I have verified that CA is not blocking sign in, the account is excluded from MFA policies, and is correctly licensed for Exchange Access. We do not use Intune for device management. When I attempt to re-register the device, I follow the prompts until I am prompted to close the browser window; The device spins, then fails to connect with the status above. I have attempted this with the service account and my own Admin account with MFA, to the same result. Entra Enterprise Apps Sign-in logs show a 'Successful' entry, then immediately after, a 'Failed' entry with an error '50199'. I had not made changes to any of the URIs before initial failure, and any additional entries or changes do not change the results of the error. Initial URI was configured to 'https://app.noop' (no idea, was configured before I got here, and I hadn't needed to change it), I have attempted combinations of our Tenant URI, ' https://login.microsoftonline.com/common/oauth2/nativeclient', and other 'fixes' I had found while GTS-ing. I additionally have set my 'legacy authentication' and 'legacy applications' CA polices to read-only for troubleshooting. I am working to disable OAuth2ClientProfile on Exchange Online temporarily for troubleshooting. Does anyone have any ideas? Please let me know if any additional information is needed, or if needed to post in another location. Thank YouMicrosoft Cancels Exchange Mailbox External Recipient Rate Limit
After considering customer feedback, Microsoft cancelled the mailbox external recipient rate limit for Exchange Online. The idea behind the new limit was simple – it makes life more difficult for spammers to use Exchange Online as a platform. Unhappily, customers didn’t like losing the ability to send relatively small amounts of external email for different reasons, and Microsoft didn't have a cost-free alternative to offer. C’est la vie. https://office365itpros.com/2026/01/08/mailbox-external-recipient-rate/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 documentation 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 book about Exchange Server SE and my talks about it at the Exchange Summit and NT Konferenca 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 Skype for Business Server 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 Fixed Lifecycle Policy, 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 Modern Lifecycle Policy, 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 committed 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 3-Year Notification 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 Exchange Team blog and provide download links, and update the tracking document 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 Exchange web page on Microsoft.com at that time, 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 the announcement at Microsoft Ignite 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 section 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 Exchange setup and migration guides (aka the Exchange Deployment Assistant) 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!
Recent Blogs
- We have released Security Updates for Exchange Server SE. Exchange Server 2019 and 2016 ESU updates only.Jun 09, 2026
- Here are some tips on how to learn more about resource mailbox use.May 21, 2026
