Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online
Published May 08 2023 08:16 AM 126K Views

Please see Update on Transport Enforcement System in Exchange Online for an updated timeline.

As we continue to enhance the security of our cloud, we are going to address the problem of email sent to Exchange Online from unsupported and unpatched Exchange servers. There are many risks associated with running unsupported or unpatched software, but by far the biggest risk is security. Once a version of Exchange Server is no longer supported, it no longer receives security updates; thus, any vulnerabilities discovered after support has ended don’t get fixed. There are similar risks associated with running software that is not patched for known vulnerabilities. Once a security update is released, malicious actors will reverse-engineer the update to get a better understanding of how to exploit the vulnerability on unpatched servers.

Microsoft uses the Zero Trust security model for its cloud services, which requires connecting devices and servers to be provably healthy and managed. Servers that are unsupported or remain unpatched are persistently vulnerable and cannot be trusted, and therefore email messages sent from them cannot be trusted. Persistently vulnerable servers significantly increase the risk of security breaches, malware, hacking, data exfiltration, and other attacks.

We’ve said many times that it is critical for customers to protect their Exchange servers by staying current with updates and by taking other actions to further strengthen the security of their environment. Many customers have taken action to protect their environment, but there are still many Exchange servers that are out of support or significantly behind on updates.

Transport-based Enforcement System

To address this problem, we are enabling a transport-based enforcement system in Exchange Online that has three primary functions: reporting, throttling, and blocking. The system is designed to alert an admin about unsupported or unpatched Exchange servers in their on-premises environment that need remediation (upgrading or patching). The system also has throttling and blocking capabilities, so if a server is not remediated, mail flow from that server will be throttled (delayed) and eventually blocked.

We don’t want to delay or block legitimate email, but we do want to reduce the risk of malicious email entering Exchange Online by putting in place safeguards and standards for email entering our cloud service. We also want to get the attention of customers who have unsupported or unpatched Exchange servers and encourage them to secure their on-premises environments.


For years, Exchange Server admins have had the Exchange Server Health Checker, which detects common configuration and performance issues, and collects useful information, including which servers are unsupported or unpatched. Health Checker can even create color-coded HTML reports to help you prioritize server remediation.

We are adding a new mail flow report to the Exchange admin center (EAC) in Exchange Online that is separate from and complementary to Health Checker. It provides details to a tenant admin about any unsupported or out-of-date Exchange servers in their environment that connect to Exchange Online to send email.

Figure 1 below shows a mockup of what the new report may look like when released:


The new mail flow report provides details on any throttling or blocking of messages, along with information about what happens next if no action is taken to remediate the server. Admins can use this report to prioritize updates (for servers that can be updated) and upgrades or migrations (for servers that can’t be updated).


If a server is not remediated after a period of time (see below), Exchange Online will begin to throttle messages from it. In this case, Exchange Online will issue a retriable SMTP 450 error to the sending server which will cause the sending server to queue and retry the message later, resulting in delayed delivery of messages. In this case, the sending server will automatically try to re-send the message. An example of the SMTP 450 error is below:

450 4.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online throttled for 5 mins/hr. For more information see

The throttling duration will increase progressively over time. Progressive throttling over multiple days is designed to drive admin awareness and give them time to remediate the server. However, if the admin does not remediate the server within 30 days after throttling begins, enforcement will progress to the point where email will be blocked.


If throttling does not cause an admin to remediate the server, then after a period of time (see below), email from that server will be blocked. Exchange Online will issue a permanent SMTP 550 error to the sender, which triggers a non-delivery report (NDR) to the sender. In this case, the sender will need to re-send the message. An example of the SMTP 550 error is below:

550 5.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online blocked for 10 mins/hr. For more information see

Enforcement Stages

We’re intentionally taking a progressive enforcement approach which gradually increases throttling over time, and then introduces blocking in gradually increasing stages culminating in blocking 100% of all non-compliant traffic.

Enforcement actions will escalate over time (e.g., increase throttling, add blocking, increase blocking, full blocking) until the server is remediated: either removed from service (for versions beyond end of life), or updated (for supported versions with available updates).


Stage 1 is report-only mode, and it begins when a non-compliant server is first detected. Once detected, the server will appear in the out-of-date report mentioned earlier and an admin will have 30 days to remediate the server.

If the server is not remediated within 30 days, throttling will begin, and will increase every 10 days over the next 30 days in Stages 2-4.

If the server is not remediated within 60 days from detection, then throttling and blocking will begin, and blocking will increase every 10 days over the next 30 days in Stages 5-7.

If, after 90 days from detection, the server has not been remediated, it reaches Stage 8, and Exchange Online will no longer accept any messages from the server. If the server is patched after it is permanently blocked, then Exchange Online will again accept messages from the server, as long as the server remains in compliance. If a server cannot be patched, it must be permanently removed from service.

Enforcement Pause

Each tenant can pause throttling and blocking for up to 90 days per year. The new mail flow report in the EAC allows an admin to request a temporary enforcement pause. This pauses all throttling and blocking and puts servers in report-only mode for the duration specified by the admin (up to 90 days per year, per tenant).

Pausing enforcement works like a pre-paid debit card, where you can use up to 90 days per year when and how you want. Maybe you need 5 days in Q1 to remediate a server, or maybe you need 15 days.  And then maybe another 15 days in Q2, and so forth, up to 90 days per calendar year.

More details can be found in How to pause throttling and blocking of out-of-date on-premises Exchange Servers.

Initial Scope

The enforcement system will eventually apply to all versions of Exchange Server and all email coming into Exchange Online, but we are starting with a very small subset of outdated servers: Exchange 2007 servers that connect to Exchange Online over an inbound connector type of OnPremises.

We have specifically chosen to start with Exchange 2007 because it is the oldest version of Exchange from which you can migrate in a hybrid configuration to Exchange Online, and because these servers are managed by customers we can identify and with whom we have an existing relationship.

Following this initial deployment, we will incrementally bring other Exchange Server versions into the scope of the enforcement system. Eventually, we will expand our scope to include all versions of Exchange Server, regardless of how they send mail to Exchange Online.

We will also send Message Center posts to notify customers. Today, we are sending a Message Center post to all Exchange Server customers directing them to this blog post. We will also send targeted Message Center posts to customers 30 days before their version of Exchange Server is included in the enforcement system. In addition, 30 days before we expand beyond mail coming in over OnPremises connectors, we’ll notify customers via the Message Center.

Feedback and Upcoming AMA

As always, we want and welcome your feedback. Leave a comment on this post if you have any questions or feedback you’d like to share.

On May 10, 2023 at 9am PST, we are hosting an “Ask Microsoft Anything” (AMA) about these changes on the Microsoft Tech Community.  We invite you to join us and ask questions and share feedback. This AMA will be a live text-based online event with no audio or video. This AMA gives you the opportunity to connect with us, ask questions, and provide feedback. You can register for this AMA here.


Which cloud instances of Exchange Online have the transport-based enforcement system?
All cloud instances, including our WW deployment, our government clouds (e.g., GCC, GCCH, and DoD), and all sovereign clouds.

Which versions of Exchange Server are affected by the enforcement system?
Initially, only servers running Exchange Server 2007 that send mail to Exchange Online over an inbound connector type of OnPremises will be affected. Eventually, all versions of Exchange Server will be affected by the enforcement system, regardless of how they connect to Exchange Online.

How can I tell if my organization uses an inbound connector type of OnPremises?
You can use Get-InboundConnector to determine the type of inbound connector in use. For example, Get-InboundConnector | ft Name,ConnectorType will display the type of inbound connector(s) in use.

What is a persistently vulnerable Exchange server?
Any Exchange server that has reached end of life (e.g., Exchange 2007, Exchange 2010, and soon, Exchange 2013), or remains unpatched for known vulnerabilities. For example, Exchange 2016 and Exchange 2019 servers that are significantly behind on security updates are considered persistently vulnerable.

Is Microsoft blocking email from on-premises Exchange servers to get customers to move to the cloud?
No. Our goal is to help customers secure their environment, wherever they choose to run Exchange. The enforcement system is designed to alert admins about security risks in their environment, and to protect Exchange Online recipients from potentially malicious messages sent from persistently vulnerable Exchange servers.

Why is Microsoft only taking this action against its own customers; customers who have paid for Exchange Server and Windows Server licenses?
We are always looking for ways to improve the security of our cloud and to help our on-premises customers stay protected. This effort helps protect our on-premises customers by alerting them to potentially significant security risks in their environment. We are initially focusing on email servers we can readily identify as being persistently vulnerable, but we will block all potentially malicious mail flow that we can.

Will Microsoft enable the transport-based enforcement system for other servers and applications that send email to Exchange Online?
We are always looking for ways to improve the security of our cloud and to help our on-premises customers stay protected. We are initially focusing on email servers we can readily identify as being persistently vulnerable, but we will block all potentially malicious mail flow that we can.

If my Exchange Server build is current, but the underlying Windows operating system is out of date, will my server be affected by the enforcement system?
No. The enforcement system looks only at Exchange Server version information.  But it is just as important to keep Windows and all other applications up-to-date, and we recommend customers do that.

Delaying and possibly blocking emails sent to Exchange Online seems harsh and could negatively affect my business. Can’t Microsoft take a different approach to this?
Microsoft is taking this action because of the urgent and increasing security risks to customers that choose to run unsupported or unpatched software. Over the last few years, we have seen a significant increase in the frequency of attacks against Exchange servers. We have done (and will continue to do) everything we can to protect Exchange servers but unfortunately, there are a significant number of organizations that don’t install updates or are far behind on updates, and are therefore putting themselves, their data, as well as the organizations that receive email from them, at risk. We can’t reach out directly to admins that run vulnerable Exchange servers, so we are using activity from their servers to try to get their attention. Our goal is to raise the security profile of the Exchange ecosystem.

Why are you starting only with Exchange 2007 servers, when Exchange 2010 is also beyond end of life and Exchange 2013 will be beyond end of life when the enforcement system is enabled?
Starting with this narrow scope of Exchange servers lets us safely exercise, test, and tune the enforcement system before we expand its use to a broader set of servers. Additionally, as Exchange 2007 is the most out-of-date hybrid version, it doesn’t include many of the core security features and enhancements in later versions. Restricting the most potentially vulnerable and unsafe server version first makes sense.

Does this mean that my Exchange Online organization might not receive email sent by a 3rd party company that runs an old or unpatched version of Exchange Server?
Possibly. The transport-based enforcement system initially applies only to email sent from Exchange 2007 servers to Exchange Online over an inbound connector type of OnPremises. The system does not yet apply to email sent to your organization by companies that do not use an OnPremises type of connector. Our goals are to reduce the risk of malicious email entering Exchange Online by putting in place safeguards and standards for email entering the service and to notify on-premises admins that the Exchange server their organization uses needs remediating.

How does Microsoft know what version of Exchange I am running?  Does Microsoft have access to my servers?
No, Microsoft does not have any access to your on-premises servers. The enforcement system is based on email activity (e.g., when the on-premises Exchange Server connects to Exchange Online to deliver email).

Our on-premises servers are subject to this throttling and blocking. How can we pause this?
See How to pause throttling and blocking of out-of-date on-premises Exchange Servers. Please note that this is just a temporary, limited-time pause and you should migrate away from out of date versions of Exchange Server as soon as possible.

We upgraded our servers to an up-to-date version; why doesn’t the reporting reflect that?
The reporting currently doesn’t show servers that comply with the current update version recommendations. In the EAC, once a persistently vulnerable server is brought up to date, the server will no longer appear in the report. In PowerShell, the Get-OnPremServerReportInfo output only includes all of the past detected persistently vulnerable versions for the server(s). It will not include records for the server versions that are currently not considered persistently vulnerable.

The Exchange Team

Brass Contributor

Looking forward to seeing this new report, when will it be released?


All of the comments on the original blog post were lost when it was deleted, apologies, everyone! This was my mistake.


@Peter_Holdridge, the first wave of customers in scope are expected to get the report by the end of this month.


UPDATE TO ABOVE STATEMENT: We are delaying the release of the report to the first wave of customers in scope by 1 month.  So the first wave will now see the report by the end of June 2023.

Copper Contributor

Scott, you had offered to look into stopping the phishing and spam from reaching my mailbox. I cannot locate the email address you asked me to send the request to. I thought the situation might improve since we last chatted about Exchange changing its Licensing Agreement terms, but it has actually gotten worse. Please let me know how to get my email address better protected. Thank You!


@David1930, please send the details to  Thanks!

While the report in the EAC (Out-of-date connecting on-premises Exchange servers) will display the out-of-date servers and an Enforcement Pause link where you can pause enforcement for up to 90-days per calendar year, for you PowerShell mavens you can also run Exchange Online Powershell cmdlets as well:

  • Get-OnPremServerReportInfo 
    Show the detected out-of-date servers and details like when throttling starts.
  • New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -NumberOfDays <n>
    Create or extend an enforcement pause.
  • Get-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer 
  • See enforcement pause details including when it ends.
Copper Contributor

Hi @Scott Schnoll @KevinShaughnessy  @Nino Bilic 

I'm just after some clarification.....we have E2k10 on-premise still (don't get me started) to support 3 x mailboxes which are used some Line Of Business applications.

All our other mailboxes are in Exchange Online.

The mail from these mailboxes on E2k10 eventually makes it's way to O365 across an Exchange Online inbound connector type of OnPremises.

Is Exchange Online going to look back in the message headers and somehow determine that the originating server of the email is E2k10 and start to block those emails?

Or is Exchange Online only ever going to look at the last hop (the machine actually making the connection) to O365 and block based on it's version?


@BTechComm2023, today the enforcement system evaluates only the connecting server, but eventually (some far off time in the future) we'll look at all servers in the routing path.  For now, though, your focus should be on removing persistently vulnerable servers from your network. 

Iron Contributor

Hi Team @The_Exchange_Team,

What is the meaning of 'per year' in "Each tenant can pause throttling and blocking for up to 90 days per year."?
Does it mean that If I enabled the Throttling and Blocking for my Exchange 2013 Hybrid environment today i.e.11/29/2023
, then I can again expand this period for another 90 days starting from 1/1/2024 and the final blocking will be effective for my environment from 4/1/2024?


@janakkhadka You get 90-days of enforcement pause granted per calendar year that you can use whenever and however you wish. So yes, you could create a pause for between now and end of 2023, and another pause using your 90-days for 2024 that'd take effect from Jan 1 to March 31st. 

Just to clarify though:

  1. We haven't enabled this yet for Exchange 2013. We'll do that starting January 2nd, 2024. So you won't see your servers in the report until then, and they won't be throttled at all between now and the end of 2023. Nor will you be able to create an enforcement pause until we enable it for 2013 around Jan 2nd.
  2. When we do enable it for Exchange 2013 you'll first get 30 days of reporting only mode - you'll see the servers in the Out-of-date Connecting On-premises Exchange Servers report in the EAC, but no throttling or blocking will take place for 30 days; so the earliest throttling for Exchange 2013 servers won't start until 30 days later, around Feb 1st.
  3. To create a pause you'll use the Enforcement Pause link that will show up in the report when your connecting Exchange 2013 servers are detected (on/after Jan 2). When you create an enforcement pause it will take effect immediately, even if you're in "reporting only" mode during the first 30-day grace period. So I suggest you wait until around January 31st or Feb 1st, right before throttling starts, before creating an enforcement pause. That way you get 30-days reporting only plus the 90-days enforcement pause thereafter. Doing it this way you can get no throttling or blocking for nearly 4 months, until around April 30th. 

Hope that makes sense. Let me know if you need further clarification. 


Iron Contributor

@KevinShaughnessy Thank you so much for your quick response. Your explanation was clear, very informative, and it indeed makes sense. I appreciate your assistance.

Copper Contributor

Hi @Scott Schnoll @KevinShaughnessy  @Nino Bilic 

When I run the "New-TenantExemptionInfo" command, I get the following error message:
WARNING: New-TenantExemptionInfo cmdlet failed




Can you help me with this message?

PS : Exchange 2010 Server

Iron Contributor

Hi Team, @The_Exchange_Team @KevinShaughnessy @Scott Schnoll 


I hope this message finds you well. I am reaching out to seek clarification on the potential impacts related to throttling and blocking in the context of an upcoming upgrade in our Exchange Server environment.

Our Current Environment comprises the following components:

  1. Exchange 2010 Edge Server
  2. Exchange 2013 CAS Server
  3. Exchange 2013 MBX Server

The proposed upgrade involves only the Exchange 2010 Edge Server, which will be upgraded to Exchange 2019. The Exchange 2013 CAS and MBX servers will remain unchanged in this process.

I am particularly interested in understanding the potential implications on throttling and blocking when relaying emails internally from the 2013 MBX server to the upgraded Edge Server and subsequently to Microsoft 365. Considering that the direct connection to Microsoft 365 will be facilitated by the upgraded Edge Server:

  1. Will this upgrade effectively address throttling and blocking concerns for direct connections to Microsoft 365 through the Edge Server?

  2. Should we anticipate any throttling or blocking impacts for internally relayed emails, specifically starting from the 2013 schedule, and passing through the 2013 MBX server to the upgraded Edge Server before reaching Microsoft 365?

I would greatly appreciate your insights on this matter and any recommendations you may have for ensuring a smooth transition with minimal disruptions.

Thank you for your time and assistance.


Best regards,

Janak Khadka

Not applicable

Hi @Scott Schnoll & @The_Exchange_Team, enforcement pause has been enabled on exchange server 2010 but still not applying. Any possible clarifications on this scenario?

@LEGOFFanthony can you try running it again? I've seen at least one report of this as a transient error (in Powershell Management API not the cmdlet itself), rerunning again later it worked. You should also be able to create an enforcement pause via the EAC report (Reports > Mail flow > Out-of-date connecting on-premises Exchange servers). 

@janakkhadka the current enforcement scope only applies to the connecting server used to connect to EXO over an inbound connector of type OnPremises. So upgrading your Edge server to 2019 will obviate the risk of getting throttled/blocked by this specific initiative. However, as you can imagine we strongly encourage folks to upgrade all their out-of-date Exchange servers regardless where they are in your environment.

@Deleted check your PMs for a message from me. 

Iron Contributor

@KevinShaughnessy Hi Kevin, Thanks for the info! I'll focus on upgrading the Edge server to 2019 to address the current initiative's concerns. I appreciate the encouragement to update all Exchange servers, and I'll keep that in mind for future planning.

Copper Contributor


Your command is incomplete.  It should be:

New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -NumberOfDays 30


New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -30



@jwoodman1325 Exactly right! :) Thanks for catching that! My apologies @LEGOFFanthony for missing that in my reply to you. I've also updated my comment further above to make the cmdlet syntax more clear:

New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -NumberOfDays <n>

Copper Contributor

We have an edge server 2013 and mailbox server 2013.
We would like to upgrade only edge to 2019, is the scenario supported?


Copper Contributor

Our org has recently upgrade from Exchange 2010 to Exchange 2016 and now we are on Exchange 2019 with the latest build.  However, the Out-of-date connecting on-premises Exchange servers report still shows us on Exchange 2010 although we have been on Exchange 2016+ since 1/24/24.  How often does the report refresh? Is there a way to manually refresh it?





Copper Contributor

@Cris21875  Just upgraded a customers setup aswell nd have the same issue. Raised a ticket with MS, but I suspect the cause to be that "Enforcement Pause" is active. But lets see when it runs out

@B_Helt1273 @Cris21875 I actually addressed this in a reply over on this blog post: How to pause throttling and blocking of out-of-date on-premises Exchange Servers - Microsoft Communi.... I've pasted my response here for convenience. 

"We've received a few customer reports that after replacing their non-compliant server (2007, 2010, 2013) with a compliant server (2016 or 2019) the old server is still showing up in the report even though it's no longer sending mail and not connecting to EXO. This happens when the old and new servers have different names. If the servers have the same names then the record disappears when you bring it into compliance, and you won't see that server's record until the next time it goes out of compliance (out-of-date).  We do this for historical tracking, so you'll always have a record of what happened for a server and when. But if the replacement server has a different name than the old server, we can't associate the old server with the new server, so the old server still shows up as "Update required" even when it's no longer sending mail into EXO and no longer relevant. Understandably, that's confusing. While there's currently no way to hide the old server's record or show it as resolved, you can track the number of throttled and/or blocked messages for the server in the report - if those don't change over time any more then you know it's been resolved.

We're investigating different options to address this issue, and we expect to have an update out in the near future. If you have any feedback on what you'd like to see, please leave a comment or DM me. 

Apologies for the inconvenience and confusion, and thanks in advance for your patience while we work on an update. "

Best wishes,


Kevin Shaughnessy
Principal Product Manager | Exchange Online

@robilipa >We would like to upgrade only edge to 2019, is the scenario supported?

We strongly recommend you upgrade all unsupported servers as soon as possible, but yes this would stop any throttling or blocking because currently we're only checking, and enforcing based on, the connecting server version, not any of the other servers behind it. 

Copper Contributor

have you tried Microsoft Copilot?

Copper Contributor

Thanks for the information. It is much appreciated.  

Copper Contributor

It isn't working, not from Exchange Online ECP or Powershell, I'm global administrator and Exchange admin so that shouldn't be the issue here...
Is the documentation correct? Because it doesn't seem to take -NumberOfDays, if I use the help in powershell it suggests EndTime but that isn't working either.
This is kinda annoying.



@Puckis1240 - Looks right, should work. Works in my test tenant. Please DM me, preferably with your TenantID or domain name. 

Kevin Shaughnessy
Principal Product Manager | Exchange Online

Copper Contributor

Please, is some step-by-step guide, how to remove Exchange 2013 from hybrid deployment ( all maplboxes are migrated to Office 365)? Is possible to uninstall exchange and keep cloudsync in service? Thank you. 

Copper Contributor

Can I remove the Exchange Servers from Mailflow and still use them to manage remote mailboxes ?

@dklement Here are a few docs RE decommissioning Exchange on-prem you might find helpful:

@Gianlucas94 Yes. I think the last article listed above might be most relevant for what you want to do. 

Copper Contributor

Is there a good way to automate these reports so that it doesn't require manual checking in either console or via PS? 

@Stephahayes I hear ya! We do have it on our backlog, hopefully get to it by June. We're considering EAC mail flow system alerts (email notifications + posting to the Mail flow > Alerts page in the EAC) and/or posting to either M365 Message Center and/or the Service Health Dashboard "Issues for your organization to act on" section (for which you can also set up email notification). Do you have a preference for which, or suggestion for an alternative that would work best for you/others?

Kevin Shaughnessy
Principal Product Manager | Exchange Online

Copper Contributor

On exchange 2016 and installed March SU 2024 last night. Ran get-onpremserverreportinfo from exchange online powershell and it still shows the build version for November SU 2023. Server also appears in admin center health, software updates.  It doesn't show in the outdated exchange online mail flow report though.




We are experiencing mail flow delays inbound, logs indicate it's throttling regardless of the throttleenableDate above.


How do we force sync to reflect correct version?



Copper Contributor

@KevinShaughnessy I would say both MC and SH announcements are in order. I personally would emphasize the dire need for documentation for these cmdlets:




Currently there's no way of telling what values does parameter 'BlockingScenario' accept for example. Or what impact does each attribute outputted by Get-OnPremServerReportInfo have. For example: if 'Build' attribute says '15.1.2507.35' and 'RecommendedBuildVersions' includes it then why do I have a 'NextStageStartDate' populated? You (the cmdlet output) are telling me my build is among the recommended builds so I get the impression there should be no action from my side...


Not to mentioned cmdlets 'Get-TenantExemptionQuota' and 'Get-TenantExemptionQuotaEligibility' which you cannot find online at all:

PS C:\> Get-TenantExemptionQuota -BlockingScenario UnpatchedOnPremServer

TenantId : //redacted//
BlockingScenario : UnpatchedOnPremServer
SequenceNumber : 0
AllotedQuota : 90
QuotaYear : 2024
EffectiveFrom : 1/1/2024 12:00:00 AM
IsApproved : True




Copper Contributor

For people with a dependency on legacy systems, we get backed into a corner with these constraints, only to realize that the only server architecture or product that is NOT covered by inclusive support is Exchange Server. Typical.

The 2016 server I had to install in my environment won't relay outbound for inexplicable reasons, and we're all out of time since you only get 90 days per calendar year. 

I've got no choice but to deploy postfix at this point since Exchange support has to be purchased in blocks of 10 hours. 

Copper Contributor


I have updated two of our exchange server to the latest SU, both are with latest CU but EXO is still showing update required or else throttling will be enabled. I have raise a support ticket but still isn't resolved yet. Any help would be much appreciated.
Copper Contributor

Has anyone had any further updates on this issue?
We have the same problem and are struggling to find a fix for this.

Have raised a support call with MS.

Copper Contributor

Would like to check on the pause per calendar year, will it means I have 90 days on year 2024, when reach 2025, I will get another 90 days of grace period? This is to check if we would like to migrate to M365 completely but afraid of not enough time to migrate all mailbox. Then we can plan to start this activity at end of the year which may give us total of 180 days for migration 




If you are in a Hybrid configuration then Microsoft will give you one Exchange License for either EX2016 or EX2019. That might be a route you could take. If that is not an option then figuring out why the Exchange server won't route to the internet should be easy to solve. One of the two places to look would be the send connectors to make sure you have them configured properly, the firewall to make sure the ports are open and the Exchange server can route out to the internet (doing a quick SMTP/Telnet should tell you if it's working) and checking the logs to see what they are saying for SMTP Outbound.


@SK_Yau  yes, that's right. 90 pause days to use in 2024 then near the end of December you'll be granted another 90 days that you can use in 2025. So yes, if you saved this year's 90 days for the end of the year you could use both grants consecutively to pause enforcement from October 3rd 2024 through March 31th 2025. 

Also, don't forget that when we initially detect an out-of-date server the first stage is 30 days reporting only, no throttling/blocking. So if we first detect that your server is out-of-date starting on September 3rd consider waiting for 30 days until October 3rd before creating a 90 day pause. That way you'd get 210 consecutive days throttle/block-free. Hope that makes sense. :) 

@RuffDay currently the cmdlet only shows historically out-of-date builds, not current builds. We updated the FAQ above to communicate that. 

@Victor Onofrei agreed on documentation, we'll get on it. 

Copper Contributor


In terms of:

  • the extended support of Exchange Online 2019 that ends next year in October 2025
  • using Hybrid Exchange for SMTP Relay from multifunctional devices (even sending with TLS 1.0, 1.1)

Will sending email from Exchange Server 2019 to Exchange Online in a hybrid environment by SMTP Relay be blocked from October 2025? Or does Microsoft have other plans for allowing Exchange Server 2019 send email to Exchange Online in a hybrid environment next year?


The answers for these questions will be helpful for planning what actions we should have for Exchange Server 2019 next year, and also the needs of migrating any SMTP Relay dependencies from the Hybrid Environment, to the cloud.


@Mahlas The road map has been updated about the next version of Exchange and that you will be able to upgrade in place from EX2019 to Exchange SE. I would suspect like the current model we have going there will be a 90 day window once EX2019 has fallen out of support but no official guidance has been published. Getting to the next version should be rather painless.

Copper Contributor



Like Mahlas am I curious about some concrete official guidance regarding when a server will be falling out of support.
Especially for the EX2016, we have a load of customers we are still working on that version.
I would expect some of them willing to wait out Server 2025 and then perhaps even migrate to straight to Exchange SE.
If we have a better view of that, then we can know it is realistic to offer this option and wait for Server 2025, which should be released later this year? We also have to think of our own time to see how well Server 2025 works in our environment (e.g. backup product support etc), which can take a few months. Thus we might not have much leeway with our hybrid customers depending on how quickly EX2016 will be blocked by ExO.

Any official information on it, or when to expect it would be much appreciated.




The next version of Exchange will be Exchange SE. This will be it according to the information from the Exchange Team about the road map. There is no Exchange 2025, that is Exchange SE. The only upgrade in place from Exchange to Exchange SE is from Exchange 2019. Customer are being urged to deploy Exchange 2019 and move off of Exchange 2016. 

Here is a link to the Roadmap:


Exchange Server Roadmap Update - Microsoft Community Hub

As the date closes in I would suspect there will be more information about Throttling and Blocking of SMTP on older versions will be updated. Hope that helps clear things up.

Copper Contributor



Sorry, seems my post was confusing regarding Server 2025, I meant Windows Server 2025, as in the operating system. I should have been more clear.

Nevertheless, thank you for replying and trying to provide some additional info.

Copper Contributor

I wanted to piggy back off of RuffDay's comment about running the report after performing an upgrade/update to the exchange build. Is there a way to test or confirm that an exchange server will not be throttled in the future, other than just looking at the server build number? I got up to build 15.01.2507.039, which is confirmed in the health check report and is one of the recommended builds. I just wanted to see if there was any other way to confirm it is truly good to go, before turning off the enforcement pause. I had to enable it after getting to Stage 5, so before I remove the pause and potentially go back to 30 minute delays, I need to be positive that there is nothing else to be done at this point.


Thanks in advance.

Copper Contributor

How can we force an update to the detected Exchange version? We installed the March 2024 SU to our existing Exchange 2016 and the report still shows an older version.  We are going to be throttled then blocked due to the inaccurate information.


To be clear I'm referring to the web report, not Powershell.  And the SU was installed more than a month ago.


Ping @KevinShaughnessy 

Copper Contributor

We need migrate 3 servers Exchange 2013 to Exchange 2019 but we don't have enough time and the servers stop 20 min everyday. The enviroment is too complex and we need more time to do this migration, we get the license but is not possible, a lot of users still on these servers.



Thanks for your comments.

When you say the "servers stop 20 min everyday" what does that mean? Can you explain?

What Servers are stopping? Why are they stopping?

When you say you need more time to do the migration, the problem with that is the EOL for EX2013 was known when it was released and we let that server hit it's EOL naturally which was 10 years. It went out of support in April of 2023 and we would have hoped you would have been off of it before then. But it's been a year since so we need to speed up that process. EX2013 has not had a security patch due to it being out of support for well over a year. You can request an extension in your tenant if you want but that work needs to be completed when the second 90 days is granted. 

Do you have all the right documents to make sure you have EX2019 configured correctly?

If you need more help you can always work with your CSAM and get someone from Microsoft to help guide you and make that process quicker.

Version history
Last update:
‎May 30 2024 08:47 AM
Updated by: