Last September, we announced the deprecation of Client Access Rules (CARs) in Exchange Online. CARs allow admins to control which devices can access their organization's mailboxes. It was introduced in 2017 as a way to provide granular access control based on client properties such as IP addresses, protocol, or application.

In October 2022, we disabled CARs cmdlets for tenants that were not using CARs. This was done to reduce the complexity and confusion around CARs and to encourage the adoption of newer and more secure features like Azure Active Directory (AAD) Conditional Access and Continuous access evaluation (CAE).

We have been working with customers to learn how they use CARs and how they can migrate to these newer features, but we have encountered a few scenarios where it's not possible to migrate current rules. For these scenarios, we will allow the use of CARs beyond the previously announced September 2023 deadline until we can support them.

We understand that migrating from CARs to Conditional Access and CAE requires some planning and testing, and we are here to help you with this process. If there is a technical reason preventing you from migrating your CARs, please open a support ticket so we can investigate and understand your needs.

Our updated CARs deprecation timeline is as follows:

Resources

• Client Access Rules in Exchange Online
• What is Conditional Access in Azure Active Directory?
• Plan an Azure Active Directory Conditional Access deployment
• Continuous access evaluation in Azure AD

The Exchange Team

PowerShell (PS) cmdlets in Exchange Online use Remote PowerShell (RPS) for client to server communication. Unfortunately, RPS is legacy technology that is outdated and can pose security risks. As such, we recommend all customers move to the new more secure REST-based v3 PowerShell module, which will help us improve security – together.

• In December 2022, we announced the deprecation of RPS in Exchange Online, and that RPS will be disabled for all customers starting in June 2023.
• In March 2023, we announced that on April 1, 2023, we will start blocking RPS connections for all tenants created on or after April 1, 2023.

Although we want all customers to switch from RPS to the v3 PowerShell module, we understand that some customers may need extra time to make that switch.

Today we are announcing that customers who need more time to make the switch can re-enable RPS (if we have disabled it for you) and use it for a little longer.

At this time, this blog post applies only to tenants in our WW cloud. We will update the information for tenants in other clouds within several weeks.

We have released a self-service tool in the Microsoft 365 admin center and the Exchange admin center that admins can use to request an extension or re-enablement of RPS. We are adding this tool to help you minimize disruptions as you transition away from using RPS. We want you to use the tool only if you really need to use RPS, and not just because you think you might need to.

As mentioned earlier, we recommend using our REST-based v3 module which is more secure and performant. By continuing to use RPS, you may be putting yourself at risk, and the best way to mitigate that risk is to move to the v3 module, which you can install from here.

Using the Self-Service Tool

You can go to the RPS self-service tool by clicking on the button below, which will take you directly to the tool in the Microsoft 365 admin center if you’re a Global Admin.

You can also go to the Microsoft 365 admin center or the Exchange admin center and click on the green Help & Support button in the lower right-hand corner of the screen which looks like this:

When you click the button, you enter our self-service help system. Here you can enter the magic phrase “Diag: Enable RPS in EXO”.

Click Run Tests to check your tenant settings to see if we have disabled RPS, and then review the results. If we have not disabled RPS for your tenant, and you are running the diagnostic, we will offer you the option to temporarily opt out of RPS disablement or re-enable RPS, as per the timeline in the table below.

Click the checkbox and then click Update.

That’s it. Once you submit the opt out request, we will not disable RPS for your tenant, based on the timeline in the table below. Tenants that qualify can request an opt out until September 2023. On September 1, 2023, we will retire the self-service tool, and on October 1, 2023, we will begin turning off RPS in all tenants, regardless of opt-out status or usage.

Note: Self-service re-enablement of RPS works only for WW tenants.

To reiterate, requesting an opt-out for RPS could put your tenant data at security risk. If you are not sure if you need RPS, let us turn it off and wait to see what happens. You can always re-enable it through September 2023 using the tool, and while this might cause some disruption, the upside is it will help define the work you need to do prior to October 2023.

Timeline of RPS deprecation

Timeframe	State of RPS protocol
March 2023	All current tenants can opt-out of RPS deprecation using the diagnostic, until September 2023
April 2023	Tenants created on April 1st and newer will have RPS disabled by default, and can re-enable it (using diagnostic) until June 2023. After July 2023 onwards, new tenants thus created will not be able to re-enable RPS.
May 2023	We disable RPS for tenants (created before April) who never used RPS and have not asked for an extension. Re-enablement of RPS is possible using the diagnostic until September 2023.
June 15, 2023	We will start disabling RPS for tenants who have not opted-out or re-enabled RPS yet and have used it in the past. Re-enablement of RPS using the diagnostic is possible until September 2023 (unless tenant was created after April 2023).
July 2023	Tenants created after July 1st will have RPS disabled permanently. Diagnostics cannot re-enable RPS for those tenants. Tenants created from July 1st onwards must use Exchange Online PowerShell v3 module using Connect-ExchangeOnline without the UseRPSSession parameter.
September 2023	RPS opt-out / re-enablement diagnostic is retired.
October 2023	We start blocking RPS for all tenants, no matter the tenant creation date, size, or opt-out status. All tenants must use Exchange Online PowerShell v3 module using Connect-ExchangeOnline without the UseRPSSession parameter.

Frequently Asked Questions

How do I know if my tenant is using RPS?
If you use the following, then you are using RPS:

• Exchange Online PowerShell connection using New-PSSession
• Exchange Online PowerShell v1 and v2 modules
• Any newer version of Exchange Online PowerShell module with the -UseRPSSession parameter

How can I get a longer exception? I still want to use RPS after September 2023.
We are not providing the ability to use RPS after September 2023. You should ensure your dependency on RPS in Exchange Online has been removed by that time. RPS will be turned off for everyone during October 2023, including tenants who have previously opted out using our self-service tool.

Summary

We are sure many of you will be happy that we are shutting down RPS in Exchange Online as it is an really good thing from a security perspective. We also know that many of our customers are not quite ready yet to move to the v3 module and still depend on RPS.

We hope that giving you an extension will give you sufficient time to move to the v3 module.

Exchange Online Manageability Team

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.

Reporting

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).

Throttling

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 https://aka.ms/BlockUnsafeExchange.

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.

Blocking

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 https://aka.ms/BlockUnsafeExchange.

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).

Table 1 below details the stages of progressive enforcement over time:

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 the server in report-only mode for the duration specified by the admin (up to 90 days per year).

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.

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.

FAQs

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 3^rd 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).

The Exchange Team

Time is up for Exchange Server 2013, and you should be finalizing your migrations. If your migration is still ahead of you or nearing completion, then this post is for you.

We wanted to provide Microsoft’s best practices for preparing and planning your migration from Exchange 2013 to Exchange Server 2019. It’s important to note that because of the many different possible topologies and configurations for Exchange 2013, we can’t cover all migration scenarios, but the common steps are included here. That said, please plan your migration carefully and include all aspects of the environment, bearing in mind that some of the steps below may or may not apply to your situation (we will err on the side of over-communicating details).

Prepare

Here are a few references that will be useful to you throughout your migration:

• Exchange Server 2019 Architecture
• Exchange 2019 System Requirements
• Exchange Server Supportability Matrix
• Load Balancing in Exchange 2019
• Exchange 2019 Preferred Architecture
• Namespace Planning in Exchange 2019

Also, be sure to download the Exchange 2019 Sizing Calculator to correctly determine your Exchange 2019 hardware requirements.

Plan

In previous posts, we discussed the benefits of using the Exchange Deployment Assistant to plan and perform your migration. This post covers the manual steps required to perform a migration.

One of the first decisions to be made is how much availability do you need. Using the guidance in our High Availability and Site Resilience documentation will help you decide how available is available enough. When making that decision, consider all your failure domains, such as disk, network, server, virtualization loss (if applicable), datacenter failure, etc.

• Which of these failures will your design cover?
• Does your Exchange 2013 environment have any pain points that can be addressed by a new design with Exchange 2019?

Your plan should additionally include all associated costs, such as licensing, rack space, hardware, disk, network, bandwidth, backups, and if applicable, 3rd party apps.

Use an Active Directory deployment site

We recommend installing Exchange 2019 into an Active Directory deployment site. This prevents any internal domain-joined clients from looking up the SCP on Exchange 2019 servers.

Disable legacy TLS

We strongly recommend disabling TLS 1.0 and 1.1 in your organization as part of your migration. Be sure to read the guidance for this carefully since mistakes can cause big problems.

• Exchange Server TLS configuration best practices
• How to enable Transport Layer Security (TLS) 1.2 on clients
• Enable TLS 1.2 on servers

Use Office Online Server

We recommend using Office Online Server to enhance the attachment experience for Outlook and Outlook on the web users. Follow the steps in Install Office Online Server in an Exchange organization to utilize this in your environment.

Exchange 2019 client namespace planning

Our namespace guidance hasn’t changed much since Exchange 2013, so understanding your existing configuration will help you migrate to Exchange 2019. If your organization has Exchange namespaces, but they aren’t documented, you can fetch your organization’s namespaces using the following script:

The results show each unique namespace per protocol. If multiple results are returned in a single protocol, validate whether this configuration is required for a bound namespace model. We recommend that the internal URL and external URL be the same, and that split DNS is used for clients.

 

#Retrieve Result
$ClientAccess = Get-ClientAccessServer -ErrorAction:SilentlyContinue -WarningAction:SilentlyContinue
$MapiVdir = Get-MapiVirtualDirectory -ADPropertiesOnly
$EWSVdir = Get-WebservicesVirtualDirectory -ADPropertiesOnly
$EASVdir = Get-ActiveSyncVirtualDirectory -ADPropertiesOnly
$OWAVdir = Get-OwaVirtualDirectory -ADPropertiesOnly
$ECPVdir = Get-EcpVirtualDirectory -ADPropertiesOnly
$OABVdir = Get-OabVirtualDirectory -ADPropertiesOnly
$RPCVdir = Get-OutlookAnywhere -ADPropertiesOnly
#Find unique namespaces
[string[]]$AutodiscoverNS = $ClientAccess.AutoDiscoverServiceInternalUri.DNSSafeHost | Select-Object -Unique
[string[]]$MapiNS = $MapiVdir.InternalURL.DNSSafeHost | Select-Object -Unique
[string[]]$EWSNS = $EWSVdir.InternalURL.DNSSafeHost | Select-Object -Unique
[string[]]$EASNS = $EASVdir.InternalURL.DNSSafeHost | Select-Object -Unique
[string[]]$OWANS = $OWAVdir.InternalURL.DNSSafeHost | Select-Object -Unique
[string[]]$ECPNS = $ECPVdir.InternalURL.DNSSafeHost | Select-Object -Unique
[string[]]$OABNS = $OABVdir.InternalURL.DNSSafeHost | Select-Object -Unique
[string[]]$RPCNS = $RPCVdir.Internalhostname.Hostnamestring | Select-Object -Unique
[string[]]$RPCNS += $RPCVdir.Externalhostname.Hostnamestring | Select-Object -Unique
[string[]]$RPCNS = $RPCNS | Select-Object -Unique
[string[]]$OWADownloadNS = $OWAvdir.ExternalDownloadHostname | Select-Object -Unique
[string[]]$OWADownloadNS += $OWAvdir.InternalDownloadHostname | Select-Object -Unique
[string[]]$OWADownloadNS = $OWADownloadNS | Select-Object -Unique
#List individual protocols
Write-Host “AutoDiscover: $AutodiscoverNS“; Write-Host “Mapi: $MapiNS” ; Write-Host “EWS:” $EWSNS ; Write-Host “EAS: $EASNS” ; Write-Host “OWA: $OWANS” ; Write-Host “ECP: $ECPNS” ; Write-Host “OAB: $OABNS” ; Write-Host “RPC: $RPCNS” ;  Write-Host “OWA Downloads: $OWADownloadNS”

 

Public folders

Supported Outlook clients for Exchange Server can access public folders. We recommend you migrate Exchange 2013 public folder mailboxes to Exchange 2019.

• FAQ: Public folders
• Announcing Support for Controlled Connections to Public Folders in Outlook

Kerberos with internal Outlook clients

Our guidance for this is based on whether your namespaces are shared between your Exchange 2013 and Exchanger 2019 servers. If they are, then you can use a single Alternative Service Account (ASA), which should ALWAYS be a computer account and not a user account.

Before making any changes, verify your existing configuration and then plan for your Exchange 2019 namespaces. You can also choose to create a new ASA with an updated naming convention, but that isn’t necessary for Kerberos to function.

In Exchange 2016 and later, use the Get-ClientAccessService cmdlet. You’ll see a warning if you use Get-ClientAccessServer, but it’s still functional.

 

Get-ClientAccessServer E15 -IncludeAlternateServiceAccountCredentialStatus | FL AlternateServiceAccountConfiguration
Identity: E15
AlternateServiceAccountConfiguration: Latest: <Not Set> Previous:  <Not Set>

 

The Latest/Previous values will show <Not set> if this isn’t configured. It will show values for date/time when properly configured:

 

Get-ClientAccessServer E15 -IncludeAlternateServiceAccountCredentialStatus | FL AlternateServiceAccountConfiguration
Identity: E15
AlternateServiceAccountConfiguration: Latest: 3/9/2023 6:15:57 PM, contoso\EX2013-ASA$
			     Previous: <Not Set>

 

After installing Exchange 2019, you can run the RollAlternateServiceAccountPassword and target your Exchange 2019 server:

 

CD $ExScripts
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer E19.contoso.com -CopyFrom E15.contoso.com

 

Now to verify this has been updated properly you can query the Exchange 2019 server:

 

Get-ClientAccessService E19 -IncludeAlternateServiceAccountCredentialStatus | FL AlternateServiceAccountConfiguration
Identity: E19
AlternateServiceAccountConfiguration: Latest: 3/9/2023 6:15:57 PM, contoso\EX2013-ASA$
			     Previous: <Not Set>

 

In our documentation for setting up Kerberos you’ll see that:

• The ASA must be a computer account to remain within support boundaries
• You can use one ASA for both Exchange 2013 and Exchange 2019

We don’t walk through the steps in this post, but we wanted to call attention to the above points. It should also be noted that there is a current limitation with this cross-version where you’ll want to make sure you’re looking up the ASA details from the local machine. Otherwise, you’ll get this error:

POP3 and IMAP clients

POP3 and IMAP4 services are set to Manual startup by default in Exchange 2019. If you have any clients that use these protocols, you’ll want to set these services to Automatic startup and keep them running. If you set these services to Automatic, you should disable POP and IMAP access at the mailbox level.

If you don’t need these services, we recommend leaving them set to Manual. Don’t set them to Disabled, or Managed Availability will believe the server has health issues.

Be sure to compare the values for ProtocolLogEnabled, InternalConnectionSettings, ExternalConnectionSettings, and x509CertificateName between servers for consistency in configuration.

Unified Messaging

This post does not cover Unified Messaging, because that feature has been removed from Exchange 2019. For detailed steps on migrating Unified Messaging to another solution, see Plan for Skype for Business Server and Exchange Server migration - Skype for Business Hybrid. Note, though, if your Exchange 2013 users have UM-enabled mailboxes, do not move them to Exchange 2019 before you move them to Skype for Business Server 2019, or they will have a voice messaging outage.

Deploy

When you are ready to deploy, create your own document or spreadsheet and add additional items that fit within your organization’s configuration needs.

Prepare Active Directory

Be sure to review Preparing AD and domains. The account you use must be a member of the Schema Admins and Enterprise Admins security groups to run /PrepareSchema, and a member of the Enterprise Admins security group to run /PrepareAD.

Examples:

Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareSchema
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAD

If you prepare Active Directory from a machine that is not an Exchange server, that machine must have the appropriate tools, including RSAT ADDS and .NET Framework 4.8.

If Active Directory preparation is not done before you install your first Exchange 2019 server, then Setup will try to perform these tasks during your first server installation. In that case, be sure to use an account that has the proper permissions.

If your forest consists of multiple domains, you will need to prepare each one. If you have only one domain, /PrepareAD will prepare it.

Examples:
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareDomain
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAllDomains

Install Windows Server

This post does not cover installing Windows Server. Please follow the guidance in Exchange Server prerequisites, Exchange 2019 system requirements, Exchange 2019 requirements to plan your OS installation.  After Windows Server is installed, and before you install Exchange Server, be sure to install the latest updates for Windows Server.

Pre-requisite script (Setup Assist)

Review the optional Setup Assist script and consider using it to prepare for installing Exchange 2019. This script is provided “as is” and is not supported, so be sure to test this script in your environment before using it in production.

.NET Framework

The pre-requisite script should ask you to install the appropriate version of the .NET Framework, but it’s worth calling out that the version installed should be a supported version and listed in the Exchange Server supportability matrix.

Install mailbox role

To demonstrate how to install the Mailbox role, we’re running Setup in unattended mode via an elevated command prompt, as documented in Use unattended mode in Exchange Setup. Always install the latest build of Exchange 2019, which you can determine here. Also see the section below about configuring anti-virus exclusions.

Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /mode:Install /r:MB

There may be other Setup switches that are needed, so refer to the unattended mode document above for details.

Configure Exchange 2019 URL based on namespace

Based on the values identified during Exchange 2019 client namespace planning, you will want to update the values below based on your organization’s desired configuration. The sample below configures the URLs to be unique per protocol, using the root domain Contoso.com, and also configures the downloads domain for Outlook on the web to address this CVE.

 

#Stage variables for namespace modifiers
$InternetDomain = “contoso.com”
$EWSModifier = "EWS"
$ASModifier = "EAS"
$OWAModifier = "OWA"
$OWADownloadModifier = “Downloads”
$ECPModifier = "ECP"
$OABModifer = "OAB"
$MapiModifier = "MAPI"
$RPCModifier = "RPC"

#Stage variables containing the protocol’s full URL

$EwsUrl = "https://"+$EWSModifier+"."+$InternetDomain + "/EWS/Exchange.asmx"
$AsUrl = "https://"+$ASModifier+"."+$InternetDomain + "/Microsoft-Server-ActiveSync"
$OwaUrl = "https://"+$OWAModifier+"."+$InternetDomain + "/owa"
$OWADownloadsHostName = $OWADownloadModifier + "." + $InternetDomain
$EcpUrl = "https://"+$ECPModifier+"."+$InternetDomain + "/ecp"
$OabUrl = "https://"+$OABModifer+"."+$InternetDomain + "/OAB"
$MapiURL = "https://"+$MapiModifier+"."+$InternetDomain + "/mapi"
$RPCHostName = $RPCModifier + "." + $InternetDomain

#Update the Exchange Virtual Directories

Get-WebServicesVirtualDirectory -Server $Env:computername  | Set-WebServicesVirtualDirectory -InternalURL $EwsUrl -MRSProxyEnabled $true -ExternalURL $EwsUrl -WarningAction:SilentlyContinue -Confirm:$false 

Get-ActiveSyncVirtualDirectory -Server $Env:computername | Set-ActiveSyncVirtualDirectory -InternalURL $AsUrl -ExternalURL $AsUrl -WarningAction:SilentlyContinue -Confirm:$false

Get-OWAVirtualDirectory -Server $Env:computername | Set-OwaVirtualDirectory -InternalURL $OwaUrl -ExternalURL $OwaUrl -InternalDownloadHostName $OWADownloadsHostName -ExternalDownloadHostName $OWADownloadsHostName
-WarningAction:SilentlyContinue -Confirm:$false

Get-ECPVirtualDirectory -Server $Env:computername| Set-EcpVirtualDirectory -InternalURL $EcpUrl -ExternalURL $EcpUrl -WarningAction:SilentlyContinue -Confirm:$false

Get-OABVirtualDirectory -Server $Env:computername | Set-OabVirtualDirectory -InternalURL $OabUrl -ExternalURL $OabUrl -WarningAction:SilentlyContinue -Confirm:$false

Get-MapiVirtualDirectory -Server $Env:computername | Set-MapiVirtualDirectory -InternalURL $MapiURL -ExternalURL $MapiURL -WarningAction:SilentlyContinue -Confirm:$false 

Get-OutlookAnywhere -Server $env:computername | Set-OutlookAnywhere -ExternalHostname $RPCHostName -SSLOffloading:$false -ExternalClientsRequireSsl:$True -InternalHostname $RPCHostName -InternalClientAuthenticationMethod:NTLM -InternalClientsRequireSsl:$true
-ExternalClientAuthenticationMethod:Basic -WarningAction:SilentlyContinue -Confirm:$false

 

Configure Autodiscover SCP for internal clients

If you don’t install Exchange in an Active Directory deployment site as we recommend, follow these steps instead.

The Get-ClientAccessService cmdlet is not available on Exchange 2013 and is used only for Exchange 2016 and later. In Exchange 2013 you need to run Get-ClientAccessServer.

When you install Exchange 2019, the server is ready to respond to incoming requests for internal clients. To prevent clients from accessing the newly installed server, we recommend that you point the SCP either to the Exchange 2013 Client Access server or set it to a NULL value by running the following command:

 

Set-ClientAccessService <ServerName> -AutodiscoverServiceInternalUri $NULL

 

It is easier to point the SCP to Exchange 2013, so you do not have to change it again. If the SCP is pointed to a server FQDN, we recommend you set the value to NULL temporarily; you can point this to Exchange 2019 later.

First, determine where the SCP is currently pointed:

 

Get-ClientAccessServer -Identity <Ex2013 CASName> | fl *auto*

 

Capture the AutoDiscoverServiceInternalUri value you get from the above command and point the Exchange 2019 SCP to NULL:

 

Set-ClientAccessService -Identity <Ex2019 ServerName> -AutoDiscoverServiceInternalURI $NULL

 

Configure the 2019 databases for default OAB

In Exchange 2013 and later, Offline Address Book (OAB) generation is managed by a mailbox assistant named OABGeneratorAssistant which runs under the Microsoft Exchange Mailbox Assistants service. OAB generation occurs in an arbitration mailbox.

These arbitration mailboxes need to be migrated to Exchange 2019, which moves OAB generation to Exchange 2019. If you customize your OAB distribution and you have multiple OAB generation mailboxes; you don’t to recreate the OAB. But be careful when assigning a new OAB to everyone as this action triggers a full download of the OAB for all clients, which could lead to network and performance issues. To check your configuration, run this command:

 

Get-OfflineAddressBook | FL Identity, GeneratingMailbox
Get-Mailbox –Arbitration | ?{$_.PersistedCapabilities -like “OrganizationCapabilityOABGen”} | FL Identity, Database, AdminDisplayVersion

 

• Offline address books in Exchange Server
• Procedures for offline address books in Exchange Server

Configure Exchange 2019 certificates

Depending on your plan, you may be using existing certificates or planning on creating new ones.

The Exchange Control Panel (ECP)-based certificate request was deprecated in Exchange 2019 CU12.

If you plan to use an existing 3^rd party certificate for Exchange 2019, you must do the following:

1. Export the 3^rd party certificate from Exchange 2013, using the instructions in Export a certificate from an Exchange server.

2. Import the 3^rd party certificate into Exchange 2019, using the instructions at Import or install a certificate on an Exchange server. An example is shown below:

 

Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes('<FilePathOrUNCPath>')) [-Password (ConvertTo-SecureString -String '<Password> ' -AsPlainText -Force)] [-PrivateKeyExportable <$true | $false>] [-Server <ServerIdentity>]

 

We recommend setting PrivateKeyExportable to $true when importing a certificate into Exchange Server. By enabling Private Key exportable, you can export the certificate with its private key.

Soon after importing the certificate, you must assign a service to it (especially SMTP). If you leave the certificate without assigning the SMTP service to it, Exchange may choose the unassigned certificate for SMTP communication and TLS communication will fail.

3. Assign services to the 3^rd party certificate, using the instructions in Assign certificates to Exchange Server services.

• When you assign the SMTP service, Exchange Server prompts you to overwrite the existing default self-signed certificate set in the transport configuration (which you can check by running Get-TransportService <ServerName> | ft name, InternalTransportCertificateThumbprint). The Transport service uses a built-in self-signed certificate for internal communication, so it is not necessary to overwrite the self-signed certificate with the 3^rd party certificate.
• Make sure the new certificate is bound to the IIS Default Web Site.

4. Follow step 2-3 to deploy the certificate on all other Exchange 2019 servers you add.

If you plan to create a new 3^rd party certificate, you must do the following:

1. Use the Exchange Management Shell (EMS) and follow the instructions in Create an Exchange Server certificate request for a certification authority. If you plan to use a certificate with multiple Subject Alternative Names (SANs) in place of a wildcard certificate, make you’re your certificate domains include all URLs set on your Exchange Server virtual directories and transport connectors.
2. Complete pending request, using the instructions in Complete a pending Exchange Server certificate request.
3. Follow steps 1-4 in the previous section to import the new certificate on your Exchange 2019 servers.

Create Database Availability Group(s)

Once you have familiarized yourself with the Exchange 2019 preferred architecture and the Exchange Server storage configuration options, you can create your DAGs following the guidance in Create a database availability group in Exchange Server.

When creating a DAG, you have the option of creating one with or without a cluster administrative access point. If you create a DAG with this access point, the cluster will not have a cluster name object (CNO) in Active Directory, and the cluster core resource group will not contain a network name resource or an IP address resource. We recommend this configuration because it means fewer resources are needed, making the DAG less complex. But note that in this configuration, you cannot use Failover Cluster Manager to manage the cluster. But since you should only manage DAGs using Exchange tools, you don’t need to use Failover Cluster Manager to manage a DAG.

Log truncation in Exchange 2019

Be aware of changes in behavior for log truncation in Exchange 2019. One of the reasons for these changes is due to how Workload Management (WLM) prioritizes threads on a server and balances this prioritization across our Exchange services (as it’s intended). This results in a higher threshold for required logs before truncation will occur, and this threshold will be different as active users are moved to these databases.

Configure anti-virus exclusions

For years we have been saying how running antivirus (AV) software on your Exchange Servers can enhance the security and health of your Exchange organization. We’ve also said that if you are deploying file-level scanners on Exchange servers, make sure that the appropriate exclusions, such as directory exclusions, process exclusions, and file name extension exclusions, are in place for both scheduled and real-time scanning.

When configuring antivirus software for Exchange Server, be sure to exclude all the items described here and here. If you use Windows Defender, you can use a script we built to make this easier.

Configure connectors

The next step is to configure Connectors.

Receive connectors

Exchange 2019 has the same number of default receive connectors as Exchange 2013. No modifications are needed if your default receive connectors were not customized in Exchange 2013.

SMTP relay receive connector

Be sure to review any SMTP relay receive connector(s) on Exchange 2013 and configure an SMTP relay receive connector on Exchange 2019 with the same configuration. This is required for any on-premises applications that need to relay emails through Exchange 2019. For more information, see Allow anonymous relay on Exchange servers.

Send connectors

Replace any Exchange 2013 servers with Exchange 2019 server in the ‘SourceTransportServers’ for all Send connectors.

If you have an Exchange hybrid environment, make sure that TLSCertificateName is configured correctly on your Connectors in both Exchange Server and Exchange Online. The Hybrid Configuration Wizard (HCW) is responsible for making the required changes on hybrid connectors.

Edge transport server

You can use the following resources to deploy Exchange 2019 Edge Transport in your environment:

• Install Exchange Edge Transport servers using the Setup wizard
• Import 3^rd party certificate and assign SMTP service. See Import or install a certificate on an Exchange server.
• Edge subscriptions are mandatory for hybrid mail flow. See Edge Subscriptions. In a hybrid environment, you also need to run the HCW (Hybrid Configuration Wizard).
• If you add a new Mailbox server to a subscribed Active Directory site, and you it to participate in EdgeSync synchronization, you need to resubscribe your Edge Transport servers. See Procedures for Edge Subscriptions.

Run the Exchange Server Health Checker

Health Checker identifies potential critical issues. We strongly recommend running it and thoroughly review its findings. You should implement all recommendations to avoid potential outages or performance issues. Health Checker isn’t just for migration. It’s for ongoing management of Exchange Server. Keep it handy, as it is one of your most value admin tools.

Migrate

Now that we have completed the deployment of Exchange 2019, the next step is to migrate.

Create a test mailbox on 2019

We recommend that you create a test mailbox (non-admin) and verify connectivity using the protocols your organization uses. Consider any workflows you have, such as connecting to an archive mailbox, using public folders, and delegation scenarios. Test Outlook, Free/Busy, Outlook on the web, ActiveSync, out of office, and any custom or third-party applications.

Test connection for Exchange 2013 mailbox

Test and verify that Exchange 2013 mailboxes can connect through Exchange 2019 by creating a HOSTS file entry on a client machine with the IP address of an Exchange 2019 server using the load balanced namespace. Check the Connection Status window to verify that the proxy server column is populated, and the connection is HTTP or HTTPS.

The Hosts file is in C:\Windows\System32\Drivers\etc directory. It is protected and can only be edited through an elevated text editor, such as Notepad. An example host entry that redirects your workstation traffic from your Load Balancer (mail.contoso.com) to a single server endpoint (192.168.1.5) would look like this:

 

192.168.1.5    mail.contoso.com

 

Point the SCP to Exchange 2019

If Exchange 2019 was installed into an existing site and the SCP was temporarily moved to Exchange 2013 or set to NULL, it needs to be updated. Depending on your configuration, you should point the SCP to either the internal FQDN of the Exchange 2019 server or to your load balanced namespace.

Move arbitration mailboxes

Next, move the system and arbitration mailboxes from Exchange 2013 to Exchange 2019 prior to other mailboxes. This is required for many things to work properly, including the Exchange Admin Center (EAC). To see which system mailboxes are on Exchange 2013, run the following commands:

 

Set-ADServerSettings -ViewEntireForest $True
Get-Mailbox -Arbitration | FT Name, Database -AutoSize

 

To migrate arbitration mailboxes from Exchange 2013 to Exchange 2019, run the following commands:

 

Set-ADServerSettings -ViewEntireForest $True
Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase <Ex2019DatabaseName>

 

Namespace changes

Once you have verified client connectivity, change your DNS records from Exchange 2013 to Exchange 2019, modify any load balanced pools, update firewall rules, NAT assignments, etc.

Hybrid configuration

After all dependencies (virtual directory URLs, Autodiscover, DNS, exchange certificates, etc.) are in place, you are ready to run the HCW.

There are two options for configuring a hybrid organization:

The HCW is best for complex hybrid deployments, especially those that require multi-forest, sharing policies, etc.

The Modern Hybrid Agent (MHA) is best for simpler deployments that only require Free/Busy and mailbox migration to Exchange Online.  MHA does not support things like Hybrid Modern Authentication for on-premises, multi-forest exchange environment, cross-premises teams calendaring, and cross-premises message tracking. MHA is designed for organizations that do not already have a hybrid configuration in place.

Run the HCW and input the servers that will be handling hybrid functions.

Move administrator mailboxes

Use either EAC or the PowerShell to move administrator mailboxes to Exchange 2019.

PowerShell Example:

 

New-MoveRequest-Identity user@domain.com -TargetDatabase <Ex2019DatabaseName>

 

Move mailboxes

See Managing mailbox moves for more information about migrating mailboxes. When moving mailboxes, note that increased log generation will occur on both the source and target databases. Plan your moves to coincide with your backups to help manage free space for your databases. Otherwise, you risk databases dismounting during or after mailbox move operations.

Migrate public folders

Our guidance for migrating public folders is in Migrate public folders from Exchange 2013 to Exchange 2016 or Exchange 2019.

Remove legacy Exchange versions

After you have finished deploying and configuring Exchange 2019, and moving all mailboxes and public folders, you can remove Exchange 2013. For more information, see Decommissioning Exchange Server 2013.

We want to thank the following people for helping with this post: Nino Bilic, Rob Whaley, Bhalchandra Atre, Paul Newell, Mike Brown, and Scott Schnoll.

Jason Lockridge, Shashank Agarwal, Jason Burnside, David Loegering and Josh Hagen (Exchange)

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

• Exchange Server 2013
• Exchange Server 2016
• Exchange Server 2019

SUs are available in a self-extracting auto-elevating .exe package, as well as the original update packages (.msp files), which can be downloaded from the Microsoft Update Catalog.

SUs are available for the following specific versions of Exchange Server:

• Exchange Server 2013 CU23 (note that support and availability of SUs end on April 11, 2023)
• Exchange Server 2016 CU23
• Exchange Server 2019 CU11 and CU12 

The March 2023 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes. Although we are not aware of any active exploits in the wild, our recommendation is to install these updates immediately to protect your environment.

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed in these SUs and do not need to take any action other than updating Exchange servers in their environment, and if applicable, installing the security update for Outlook on Windows described below.

More details about specific CVEs can be found in the Security Update Guide (filter on Exchange Server under Product Family).

Awareness: Outlook client update for CVE-2023-23397 released

There is a critical security update for Microsoft Outlook for Windows that is required to address CVE-2023-23397. To address this CVE, you must install the Outlook security update, regardless of where your mail is hosted (e.g., Exchange Online, Exchange Server, some other platform). Please see the MSRC blog post about this vulnerability for more details.

But if your mailboxes are in Exchange Online or on Exchange Server, after installing the Outlook update, you can use a script we created to see if any of your users have been targeted using the Outlook vulnerability. The script will tell you if any users have been targeted by potentially malicious messages and allow you to modify or delete those messages if any are found. Please also check script FAQ.

The script will take some time to run, so we recommend prioritizing user mailboxes that are of higher value to attackers (e.g., executives, senior leadership, admins, etc.).

Please note that Exchange Server March 2023 SUs contain a "defense in depth" change that removes the value of the property that can be exploited on unpatched Outlook for Windows clients for messages that are newly delivered to user mailboxes. No admin action is necessary other than installing March 2023 (or later) SU.

Defenders can also read Guidance for investigating attacks using CVE-2023-23397 from Microsoft Incident Response (IR) team.

Update installation

The following update paths are available:

• Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
• Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker. Running this will tell you if any of your Exchange Servers are behind on updates (CUs, SUs) and if manual actions are needed.
• Always re-run Health Checker after you install an SU to see if any further actions are needed.
• If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates.

Known issues with this release

• There are no known issues with this release

Issues resolved in this release

• EWS web application pool stops after the February 2023 Security Update is installed – if you have implemented the workaround in the KB article, you must remove the workaround once the March SU is installed (see the KB article for instructions). Running Health Checker will remind you of the need to remove the workaround.
• Exchange Toolbox and Queue Viewer fails after Certificate Signing of PowerShell Serialization Payload is enabled - this issue has been resolved for servers running the Mailbox role, but this still occurs on servers and workstations that have only the Management Tools role installed.
• This release unblocks customers who can't enable Extended Protection (EP) because they are using a Retention Policy with Retention Tags that perform Move-to-Archive actions. Note: if you worked around this problem using the updated Exchange Server Extended Protection script, you should roll back the applied IP restrictions after installing this SU by following the script documentation.
• Get-App and GetAppManifests fail and return an exception
• For customers using Exchange Server 2016 or 2019 (with no Exchange 2013) who have non-default applications installed through ECP add-ins, the ECP add-ins page might be broken after February SU is installed

FAQs

What is the relationship of Exchange Server March 2023 SU and Outlook fix for CVE-2023-23397?
Those two updates are independent from each other. Exchange SUs address Exchange vulnerabilities and security improvements (including a defense in depth update related to CVE-2023-23397). We mentioned the Outlook CVE-2023-23397 update in the Exchange March SU release post to raise the awareness to our customers, as we know most use Outlook for Windows. Exchange March SU does not address CVE-2023-23397 (as it is a client vulnerability), you must install Outlook update to address this vulnerability in Outlook.

Our organization is in Hybrid mode with Exchange Online. Do we need to do anything?
Exchange Online is already protected, but Exchange SU needs to be installed on your Exchange servers, even if they are used only for management purposes. If you change the auth certificate after installing the March 2023 SU, you should re-run the Hybrid Configuration Wizard. Please note that we recommend all our customers (on-premises, hybrid or online) install Outlook updates.

The last SU we installed is a few months old. Do we need to install all SUs in order, to install the latest one?
SUs are cumulative. If you are running a CU supported by the SU, you do not need to install all SUs in sequential order; simply install the latest SU. Please see this blog post for more information.

Do we need to install SUs on all Exchange Servers within our organization? What about ‘Management Tools only’ machines?
Our recommendation is to install SUs on all Exchange Servers and all servers and workstations running the Exchange Management Tools to ensure compatibility between management tools clients and servers.

Updates to this post:

• 3/24/2023: Added a link to Guidance for investigating attacks using CVE-2023-23397.
• 3/24/2023: Corrected the statement about defense in depth Exchange fix; it does not apply only to messages sent from outside of the organization.
• 3/24/2023: Clarified the FAQ about relationship of Exchange and Outlook fixes
• 3/23/2023: Added a note mentioning the CVE-2023-23397 defense in depth fix included in Exchange Server March 2023 SUs (or later)
• 3/17/2023: Clarified the wording related to the need to remove the workaround for EWS crash, if customers applied it after installing February SU
• 3/16/2023: Added a link to CVE-2023-23397 script FAQ page
• 3/16/2023: Added "For customers using Exchange Server 2016 or 2019 (with no Exchange 2013) who have non-default applications installed through ECP add-ins, the ECP add-ins page might be broken after February SU is installed" under Issues Resolved. We expect that if there is no Exchange Server 2013 in the mix, add-ins will work with March SU installed.
• 3/15/2023: Added a clarification for installation of Outlook updates in the FAQ for Hybrid mode
• 3/15/2023: Added the "What is the relationship of Exchange Server March 2023 SU and Outlook fix for CVE-2023-23397?" FAQ pair.
  
• 3/15/2023: Added a link to Get-App and GetAppManifests fail and return an exception under issues resolved.
• 3/15/2023: Added a link to MSRC blog post with details about Outlook vulnerability.
• 3/14/2023: Clarified the wording about how and when to run Outlook vulnerability script.
• 3/14/2023: Removed the section "For some customers, who have non-default applications installed through ECP add-ins, the ECP add-ins page might be broken after February SU is installed" from Issues Resolved while investigating a report the issue is still not resolved.

The Exchange Server Team

On April 11, 2023 (31 days from today), Exchange Server 2013 reaches End of Support! But you know that because we've already announced that here and here and here and here, and here (just kidding, that last one was actually for Exchange Server 2003! but all the other ones are real).

So, we thought we would instead look back and take time to thank Exchange Server 2013 for its decade of service.

Released to Manufacturing on January 9, 2013, Exchange Server 2013 took the messaging world by storm, as you can tell from our web site at the time.

Microsoft Exchange web site, circa 2013

 

Ok maybe not by storm, but it did usher in some pretty cool things, like the first version of the Exchange admin center, the web-based portal that replaced the Exchange Management Console and the Exchange Control Panel (except for the URL, which was weird, but we digress).

Exchange admin center in Exchange Server 2013

It also introduced an entirely new servicing model that moved from Service Packs and Update Rollups to Cumulative Updates. 

And it was the first version to significantly adopt concepts and features from Exchange Online. For example, Exchange 2013 introduced the managed store, which were the newly rewritten Information Store processes, Microsoft.Exchange.Store.Service.exe and Microsoft.Exchange.Store.Worker.exe, and managed availability, which is a set of tightly integrated internal monitoring and recovery-oriented features that help prevent failures, proactively restore services, initiate server failovers automatically, or alert administrators to take action.

Exchange 2013 also introduced data loss prevention to help customers protect their sensitive data and inform their users of internal compliance policies, and it introduced In-Place Hold that allowed customers to meet legal hold requirements in a variety of new scenarios.

Of course, it wasn't just new features that defined Exchange 2013.  Exchange 2013 modernized the platform by moving from three kinds of data replication and two types of Exchange clusters to database availability groups, which are still in use today by both Exchange Server and Exchange Online.

But by far, the biggest change was to Outlook Web App, which was totally refreshed, as you can see from the screenshot below:

Outlook Web App in Exchange Server 2013

 

Wow, what an interface! Seriously, though, it was a more streamlined user interface that now also supported the use of touch, which greatly enhanced the mobile device experience with Exchange 2013 at the time.

It's great to look back 10 years and feel nostalgic about all the wonderful things ushered in by Exchange 2013. Of course, for some of you this is not nostalgia, because you're still using it.  If you are still using Exchange Server 2013, then be aware that:

After April 11, 2023, Microsoft will no longer provide:

• Technical support for problems that may occur
• Bug fixes for issues that are discovered and that may impact the stability and usability of the server
• Security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
• Time zone updates

Exchange Server 2013 will continue to run after this date, of course; however, due to the risks listed above, we strongly recommend that you migrate from Exchange Server 2013 as soon as possible. If you haven't started your migration from Exchange Server 2013 to Exchange Online or Exchange Server 2019, get going now!

In order to stay supported you can:

• Upgrade to Exchange Server 2019 and/or
• Migrate to Exchange Online

If you are upgrading to Exchange Server 2019, learn about what you need in your environment and how to safely decommission Exchange Server 2013 when you are done.

If you're migrating to Exchange Online, you might be eligible to use our Microsoft FastTrack service. FastTrack provides best practices, tools, and resources to make your migration to Exchange Online as seamless as possible. Best of all, you'll have a support engineer walk you through from planning and design to migrating your last mailbox. For more information about FastTrack, see Microsoft FastTrack.

For more information on what this means and what your options are, see Exchange 2013 end of support roadmap.

Ok, now we told you here, too.  So, please say goodbye to your Exchange 2013 servers (and any older servers you might have).

 

--The Exchange Team

Update 3/27/2023: For more information on this subject please see our newer blog post.

We previously announced the general availability of REST-based Exchange Online PowerShell v3 module (September 2022) and the deprecation of Remote PowerShell (RPS) Protocol (December 2022).

Today, we are announcing that starting April 1, 2023, we will start blocking RPS connections for all tenants created on or after April 1, 2023. After April 1, 2023, new tenants will not be able to use RPS when connecting to Exchange Online and will have to use the v3 module with REST cmdlets instead.

The overall RPS deprecation plan we announced in December applies to all Exchange Online customers connecting with RPS. We recommend that all customers move to the v3 module, which is more secure and more reliable than the older PowerShell modules.

Connect-IPPSSession (for Security & Compliance cmdlets) will remain RPS-based and is not affected by this deprecation.

What are the next steps?

If you are using New-PSSession to establish an RPS connection: 

• Install the latest Exchange Online Management v3 module from here.
• Use Connect-ExchangeOnline instead of New-PSSession to establish connection.

If you have installed any module earlier than v3:

• Uninstall previous versions of ExchangeOnlineManagement module by running "Uninstall-Module ExchangeOnlineManagement" from an elevated (admin) command prompt.
• Install the latest Exchange Online Management v3 module from here.
• Discontinue all use of the UseRPSSession parameter.

There are some new features and minor breaking changes in the v3 module. Please keep them in mind while testing any scripts with v3 module. You can read more about these changes here.

We heard your concerns related to deprecation timelines. We will soon release a tool to allow tenant admins to request an extension to use RPS for a little longer. We will keep you posted.

We are excited to provide you with a more secure and performant environment, and we remain committed to our journey to empower you with the most modern features and tools. If you have questions/feedback, please leave comments here or email us at RPSdeprecation@service.microsoft.com.

Exchange Online Manageability Team

In Part 1, I provided steps to troubleshoot the Legacy Exchange Retention policies, and in this part, Part 2, I delve into Compliance Retention policies. I look at two different scenarios that may impact a mailbox, providing step-by-step guidance on how to navigate and resolve issues you may encounter.

Scenario 1: Clearing the Recoverable Items Folder

Picture this: a user is trying to schedule a meeting, but they get an error message:

'554 5.2.0 STOREDRV.Deliver.Exception:QuotaExceededException.MapiExceptionShutoffQuotaExceeded; Failed to process message due to a permanent exception with message.” 

After some investigation, we discover that the root of the problem is a full recoverable items folder.

Identify the Compliance Retention Policy

The first step to resolve this issue is to identify the compliance retention policy that is applied to the mailbox. This can be done by using the Policy lookup tab under Data lifecycle management > Microsoft 365, and you'll have access to all the policies associated with your mailbox.

Or you use PowerShell:

 

Get-Mailbox <Identity> | fl InPlaceHolds

 

Examine the Compliance retention policy which will be found under InPlaceHolds parameter. For more info, see Learn about retention policies & labels to automatically retain or delete content.

Verify compliance retention rule applied to your mailbox, and what it does

This only applies if a compliance retention policy has been assigned under the InPlaceHolds parameter.

To identify the compliance retention rule, run the following command to obtain the rule, the retention actions, and the duration for this rule. Using the policy GUID acquired from the previous command (Get-Mailbox | fl InPlaceHold), you can retrieve the compliance rule and action on this policy:

 

Get-Mailbox | fl InPlaceHolds
Get-RetentionComplianceRule |? {$_.Policy -match “18aec5b1-04d8-40e4-8290-7b35f9834f24”}| fl Name, Retention*

 

In the above example, the items will be kept for five years (1825 days) before being deleted. You can also review the policy using Microsoft Purview under Data lifecycle management - Microsoft 365.

At this point, you have two options:

1. Archive the items in the recoverable items folder using a legacy retention policy, or
2. Permanently delete the data after consulting with your compliance team.

In this case, my customer decided to permanently delete the recoverable items, knowing that the data would be forever erased and unrecoverable. To do this, we exclude the mailbox from the compliance retention policy.

If you find that a compliance policy is the primary cause of the high quota due to retaining items and preventing MFA from purging them, you can follow the steps below to exclude that mailbox from the policy:

To exclude your mailbox from the compliance policy, go to the Purview Admin center and find the retention policy tab under Data lifecycle management. Locate the compliance policy from the previous step and click on it to edit. Follow the prompts by clicking "Next" until you reach the location tab. On the location tab, you will find an exclusion button which you can use to exclude your mailbox from the policy.

Alternatively, you can use Set-RetentionCompliancePolicy -Identity <policy name> - AddExchangeLocationException "Jane Doe". It can take up to a day for an exclusion to be applied. For more information, see How long it takes for retention policies to take effect.

To confirm that the policy was distributed correctly after the exclusion, use the following command:

 

Get-RetentionCompliancePolicy <Policy Name> -DistributionDetail | fl *distribution*, *exchangelocation*

 

If there is an error in the distribution status, use the following command to redistribute the policy:

 

Set-RetentionCompliancePolicy -Identity <policy name> -RetryDistribution 

 

The RetryDistribution switch specifies whether to redistribute the policy to all Exchange Online and SharePoint Online locations. You do not need to specify a value with this switch.

Check the delayed hold. After any type of hold is removed from a mailbox, a delay hold is applied. This means that the actual removal of the hold is delayed by 30 days. This gives admins an opportunity to search for or recover mailbox items that will be purged (purged) from the mailbox.

DelayHoldApplied will be True after the hold is removed; therefore, you need verify this parameter and disable it, if necessary, to clean the recoverable items folder.

 

Set-Mailbox <username> -RemoveDelayHoldApplied

 

This scenario might apply to any folder, such as the Inbox or any other folder that you wish to clear using the legacy retention policy, but the compliance retention policy prevents MFA from doing so.

Scenario 2: Restoring bulk deleted items that were deleted by mistake

Accidentally applying a compliance retention policy to the wrong mailbox or multiple mailboxes can result in bulk deletion of items. For example, one of my customers applied a policy that deletes content after six months to the entire company instead of a single user, resulting in the bulk deletion of items older than six months. However, there is a way to recover these deleted items.

To avoid any interference with the mailbox during the restore process, it is important to first disable email lifecycle (ELC) processing for the entire organization or for the specific affected mailbox, depending on the scope of the problem. This can be done by running the following command:

Set-OrganizationConfig –ELcProcessingDisabled $True

Next, you can use PowerShell to recover deleted emails from the recoverable items folder and restore them to their original location. You can restore the mail items based on the deletion date, for example:

Get-RecoverableItems -identity <User> -ResultSize unlimited -FilterItemType IPM.Note - FilterStartTime “dd/mm/yyyy” | Restore-RecoverableItems

This command will restore all email items that were deleted on the date specified by FilterStartTime.

It's important to note that, once the items are restored, you should check if there is any retention policy applied that could cause bulk deletion again and make sure to exclude the affected mailbox or mailboxes to prevent this scenario from happening again.

For more information on this process, please refer to the following:

• Recover deleted messages in a user's mailbox in Exchange Online
• Get-RecoverableItems
• Restore-RecoverableItems

Conclusion

In conclusion, troubleshooting retention policies in Exchange Online can be a complex task that requires a deep understanding of the different types of policies and their effects on a mailbox. By following the steps outlined in these articles, you will be able to identify and fix any issues related to legacy retention policies, tags, and compliance retention policies.

It's important to start by identifying the retention policy assigned to the mailbox, checking the retention tags actions included in the policy, and forcing the MFA to process the mailbox. Remember to always double-check that the correct policies and tags are applied and to give the process enough time to complete. By following these steps, you will be able to effectively manage your mailbox and ensure that your messages are being properly retained and processed.

Mustafa Nassar
Exchange Support Engineer

For years we have been saying how running antivirus (AV) software on your Exchange Servers can enhance the security and health of your Exchange organization. We’ve also said that if you are deploying file-level scanners on Exchange servers, make sure that the appropriate exclusions, such as directory exclusions, process exclusions, and file name extension exclusions, are in place for both scheduled and real-time scanning.

But times have changed, and so has the cybersecurity landscape. We’ve found that some existing exclusions, namely the Temporary ASP.NET Files and Inetsrv folders, and the PowerShell and w3wp processes - are no longer needed, and that it would be much better to scan these files and folders. Keeping these exclusions may prevent detections of IIS webshells and backdoor modules, which represent the most common security issues. So, we now recommend that you remove these exclusions from your file-level AV scanner:

Folders:

 

%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
%SystemRoot%\System32\Inetsrv

 

Processes:

 

%SystemRoot%\System32\WindowsPowerShell\v1.0\PowerShell.exe
%SystemRoot%\System32\inetsrv\w3wp.exe

 

We’ve validated that removing these processes and folders doesn’t affect performance or stability when using Microsoft Defender on Exchange Server 2019 running the latest Exchange Server updates.

We also believe that these exclusions can also be safely removed from servers running Exchange Server 2016 and Exchange Server 2013 (decommissioning before April, right?).  So, feel free to remove the exclusions from those versions, as well. If any issues arise, simply put the exclusions back in place, and report the issue to us.

The Exchange Server Team

There are two types of retention policies: Exchange Online Retention policies and the Compliance Retention policies. In this two-part article series, I provide suggestions and tactics to help you troubleshoot both. In this post (Part 1), I delve into Exchange Online Retention Policies and identify issues that you may encounter. In Part 2, I discuss Compliance Retention policies and how to troubleshoot them.

You may not need them all, but in this article, I cover several useful troubleshooting steps.

Always start by using Start-ManagedFolderAssistant to begin processing mailboxes. While this can take up to 7 days in Exchange Online, it's important to start at the beginning and work to identify and fix the root cause. Also, if a problem does exist, it may be resolved after the Managed Folder Assistant (MFA) processes the mailbox.

A mailbox will not be processed if it is less than 10 MB in size or if no retention policy is assigned to it.

Identify the Exchange retention policy assigned to the mailbox

First determine which policy is assigned to the mailbox by running the following command:

 

Get-Mailbox <Identity> | fl InPlaceHolds, Retention*, ELC*

 

The Retention Policy applied to this mailbox, "Default MRM Policy," should be reviewed. Ensure that ELcProcessingDisabled is set to its default value of False, as this property prevents the MFA from processing the retention policy and other functions. Also, confirm that Retention hold is not enabled (False), as this will only prevent expiring items in folders from being visible to the user, but not in the Recoverable Items folder. For more information on Retention tags, policies and holds, see Retention tags and retention policies in Exchange Online.

Check the retention tags actions included in the policy

After reviewing the retention policy, determine which Retention tags have been assigned to the mailbox and what their actions are by running the following commands:

 

Get-RetentionPolicy -Identity “Default MRM Policy” | select -ExpandProperty retentionpolicytaglinks
$tags = Get-RetentionPolicy -Identity “Default MRM Policy” | select -ExpandProperty retentionpolicytaglinks
$tags | foreach {Get-RetentionPolicyTag $_ | ft Name, Type, Age*, Retention*}

 

The output above provides details about the retention policy applied to the mailbox, such as the types of included tags, the actions taken on items at a certain age, and the age limit for retention. It is important to evaluate the relevance of these tags to your mailbox and identify the default retention tag (DRT) applied to it.

Use MFA to process the mailbox again

To ensure the MFA processes the mailbox, run the following command after verifying that policies and tags have been correctly applied to the mailbox:

 

Start-ManagedFolderAssistant -Identity <User>

 

Again, the processing time in Exchange Online can be up to 7 days.

If you recently made changes to a mailbox's retention policy, use the -FullCrawl parameter to recalculate the entire mailbox:

 

Start-ManagedFolderAssistant -Identity <User> -FullCrawl

 

This parameter, which is available only in Exchange Online, will recalculate the application of tags throughout the entire mailbox.

Verify MFA processing

Check the value of ELCLastSuccessTimestamp to verify that the MFA correctly processed the mailbox by running the following command:

 

$MRMLogs = [xml] ((Export-MailboxDiagnosticLogs <user> -ExtendedProperties).mailboxlog)
$MRMLogs.Properties.MailboxTable.Property | ? {$_.Name -like “*ELC*”}

 

­The output will show the number of deleted or archived items that MRM processed last time as well as the time stamp of the last successful run.

Check MRM mailbox diagnostics

To further check for any MRM exceptions, run the following command:

 

Export-MailboxDiagnosticLogs <identity> -ComponentName MRM

 

If any errors are returned, such as "Resource 'DiskLatency (GUID:... Name:??? Volume:...) is unhealthy and should not be accessed" or "Resource 'Processor' is unhealthy and should not be accessed," determine the frequency of the error. If it has not occurred for more than two days, re-run the MFA. If the issue persists or has occurred for more than two days, contact Microsoft support. Additionally, you may want to review the compliance retention policy section of the relevant documentation.

Examine mailbox folder statistics

If the previous steps do not resolve the issue of the mailbox quota not being reduced, it may be necessary to check the mailbox folder statistics to identify the root cause of the problem. You can use the following command to gather information on the number of items, oldest item, and top item in the inbox folder:

 

Get-MailboxFolderStatistics <User> -FolderScope inbox -IncludeOldestAndNewestItems -IncludeAnalysis | select name, items*, oldes*, top*

 

If any item is larger than 150 MB, there will be a problem moving it to the archive, and you will have to move it manually or delete it. Also note that the maximum number of objects per folder is one million. If any folder reaches the 1 million item limit, nothing will be transferred to that folder. This is common for the Inbox, and when this happens, the ELC Assistant produces an error.

For example, a big item, like in the previous example, may cause the mailbox to stop processing, in which case you must manually move the item to the archive or delete it. Similarly, with the 1 million item restriction, you must manually reduce the number of items in the folder to allow MRM to handle the mailbox again.

That’s it for Part 1. In Part 2, I discuss troubleshooting Compliance Retention policies.

Mustafa Nassar
Exchange Support Engineer

At Microsoft Ignite several years ago we announced that we were working on a new cloud-based message recall feature for Exchange Online. Today we’re thrilled to announce that the new Exchange Online Message Recall feature has finally arrived! It’s starting to roll out now and should be available to all Exchange Online tenants worldwide by mid-March.

You may be familiar with the classic Outlook for Windows message recall feature that gives senders an opportunity to recall messages. The classic message recall feature enables senders to at least partially recall an email, but because it is client-based, it has a number of restrictions, and its average success rate is only about 50%. So, for most message recall requests, it’s been a best-effort or better-than-nothing action, rather than a full sigh-of-relief experience.

We took the opportunity to improve on many of the classic feature's shortcomings, and drastically increase its recall success rates. The new message recall feature is more than twice as effective (based on its use by Microsoft employees over the last several months -- and oh boy, do we use it a lot!). In addition to improved performance, we’ve also improved usability by creating an aggregate recall status report to replace the potentially hundreds or thousands of individual recall status email notifications (one for each message recipient).

What's new with Message Recall

• On average, it’s more than twice as effective at successfully recalling messages than the classic feature.
• Recipients no longer must have Outlook for Windows open for recalls taken from their mailboxes to be processed – the recall happens within the cloud mailbox, not on the client.  This way recipients can use any email client that syncs with an Exchange Online mailbox, and the client doesn’t have to be open for the recall to process.
• It can now recall 'read' messages (tenant admins can disable this ability if they prefer).
• It can also recall messages from any folder or sub-folder within the mailbox and not just the Inbox.
• It offers a simple web-based status report, one per recalled message, to quickly see your overall recall results and determine the status for each recipient. No more multiple status notifications – just a single recall status email message that includes a single link to the recall status report.

How to recall a message using the Message Recall feature

While recipients are no longer required to use Outlook, at this time senders still need to use Outlook for Windows to trigger a message recall, using the same “Recall This Message” capability in the Outlook UI that the classic message recall feature uses. You can request to recall a message in Outlook for Windows via one of several entry points – below is just one of them (see Recall or replace an email message that you sent for more information).

Recall using File > Info > Resend or Recall

1. From the Sent folder in Outlook for Windows open a message that you want to recall.
2. In the open message go to the File menu and choose Info > Resend or Recall > Recall This Message.
3. In the dialog box that pops up select either the option to Delete the copies of this message or Delete and replace them with a new message, and then click OK.

And that’s it! Outlook will generate a “Recall” message (message class IPM.Outlook.Recall) that it sends to all the recipients. If the recipient has a mailbox hosted in Exchange Online, the Message Recall feature agent in the cloud will intercept the “Recall” message, attempt to recall (hard delete) the original message from the recipient’s mailbox in the cloud, and then it drops the recall message since it’s no longer needed. When the recipient’s email client (any email client) syncs with their cloud mailbox, the message should be gone.

The flow looks like this:

Track recall results with a single recall status report

After submitting a recall request, usually less than 30 seconds later, the sender will get an email notification from the service with the subject "Message Recall Report for message [original message subject]", like this one:  

Just click on the View Message Recall Report link to view the report in your browser. If you’re prompted, log in with your mailbox credentials to view the report:

Recall actions are usually quick, regardless how many recipients are involved. But if the recall request can’t be executed right away for some reason (e.g., the recipient’s mailbox is temporarily unavailable) we'll continue to retry for up to 24 hours before marking the recall as failed.

Status updates are usually pretty quick as well, but can sometimes take up to 5 minutes for a message with up to a few hundred recipients. For a large number of recipients (tens of thousands) the recall itself is still fast, but it can take up to 30+ minutes to retrieve the recall status for all recipients.

Feature comparison

Many long-time users of the classic Message Recall have commiserated over the feature’s inability to recall messages that have been flagged as read in the recipient’s mailbox, as well as the fact it recalled messages only from the Inbox and not from sub-folders. You will be pleased to know that the new Message Recall addresses both these scenarios: It can recall both read messages and messages in sub-folders! Support for these two new capabilities, plus the removal of the restriction for recipients having to use Outlook for Windows, contributes significantly to the increased recall success rate that the new Message Recall feature provides.

The table below compares some of the key characteristics of the new Message Recall compared to the classic Outlook for Windows feature:

Capability	Classic Message Recall	New Message Recall
Average recall success rate	40%	> 90%
Recalls are performed in the cloud	No	Yes
Recipients can use any email client to be eligible for recalls	No	Yes
Can recall read messages	No	Yes
Can recall messages from sub-folders (except Draft and Sent Items by design)	No	Yes
Single recall status report for all recipients	No	Yes

Frequently Asked Questions

Will the new Message Recall allow me to trigger recalls using email clients other than Outlook for Windows?
Not yet, but we’re working on an API that other email clients can adopt to submit recall requests for Exchange Online recipients.

Can I recall messages sent outside my organization?
No. For privacy and legal reasons the new Message Recall won’t recall messages sent to recipients outside your organization.

Can I recall messages from recipients inside my organization but who have mailboxes hosted on-premises?
No. The new Message Recall can only recall from mailboxes that are hosted in Exchange Online.

Can I disable the recalling of read messages for my tenant?
Yes. While having the ability to recall read messages has been an enormously popular request for years, a tenant admin can also disable this capability under Settings > Mail flow in the Exchange admin center, or via Remote PowerShell with Set-OrganizationConfig -RecallReadMessagesEnabled $false.

Can a tenant admin completely disable the new cloud-based Message Recall feature?

Yes, a tenant admin can use the following Remote PowerShell cmdlet to disable the new Message Recall feature for their entire tenant. Using this setting to disable the new cloud-based Message Recall will re-enable the legacy Message Recall for users of Outlook for Windows in your tenant.

Set-OrganizationConfig -MessageRecallEnabled $false

Will the recipient be informed that a message was recalled, especially for read messages?
No, not at this time. It’s under consideration for a future update.

Will recalls show up for eDiscovery?
For users/mailboxes that have a Litigation or Mailbox Hold, the recalled message will show up in eDiscovery.

Will recalls show up in the mailbox audit logs?
No, not at this time. We plan to address this in a future update.

Will forward messages get recalled?
Messages automatically forwarded via the SMTP forwarding by a recipient to another mailbox within the same organization will get recalled. However, messages forwarded manually by the recipient, or forwarded via Inbox rules (forward or redirect), will not.

Is there a time limit past which you can’t recall a message?
No, there is no time limit, just like the classic message recall feature. Providing tenant admins the ability to customize a time limit for their organization is under consideration for a future update.

Are the recall results stored in the sender’s mailbox?
No, the recall results are not stored in the sender’s mailbox, so it has no effect on the user’s mailbox quota or space.

Is there a limit on the number of recipients I can recall from with a single recall request?
Theoretically no – for a message you successfully sent, the recall action will be attempted and usually succeed for all eligible recipients regardless how many there are. However, the recall status report itself is currently limited to ~50k recipients. We plan to increase that significantly later this year.

The message recall dialog box in Outlook still has a checkbox to receive a recall notification for each recipient. Does that do anything with the new Message Recall?
No, it doesn’t. The Outlook dialog box hasn’t yet been updated to detect when the new Message Recall feature will be used instead of the classic Outlook message recall. We expect this to happen later this year.

The message recall dialog box says it’s only for unread messages. Is that still true with the new Message Recall?
Not necessarily. The tenant admin can control whether to allow recalling read messaging (enabled by default) or not. The Outlook dialog box hasn’t yet been updated to reflect the capabilities of the new Message Recall feature. We expect this to happen later this year.

Can I share my recall status report with others?
Yes, you can export the status report to a CSV file and share that with others. But sharing the link to the report itself won’t work. Logging in to the report requires the sender’s login credentials.

Does the recall work when the sender is a shared mailbox?
Yes, the new Message Recall supports triggering a recall from a shared mailbox and you can expect it will get recalled from most recipients. However, you won’t be able to login to view the status report at this time We expect to address this issue later this year.

Does the new recall work when sending as a delegate?
Similar to the shared mailbox scenario, the recall will work, but you won’t be able to login to view the report. We expect to provide that capability later this year.

Conclusion

The new Message Recall won’t stop you from accidentally sending “Oops” email messages, but with its high success rate and ease of tracking with the new recall status report, it should help bring you a lot more peace of mind for when you do. We hope you find it useful and look forward to hearing your feedback or suggestions for future improvements.

Kevin Shaughnessy

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

• Exchange Server 2013
• Exchange Server 2016
• Exchange Server 2019

SUs are available in a self-extracting auto-elevating .exe package, as well as the original update packages (.msp files), which can be downloaded from the Microsoft Update Catalog.

SUs are available for the following specific versions of Exchange Server:

• Exchange Server 2013 CU23 (note that support and availability of SUs end on April 11, 2023)
• Exchange Server 2016 CU23
• Exchange Server 2019 CU11 and CU12 

Note: Build availability issues have been resolved. If your server downloaded the February SU via Windows/ Microsoft update before February 15 8 AM Pacific time, you might see the February update be offered again. Installing the updated package will bring your server forward to current February builds (verify using Health Checker after installation). The Download Center .exe update packages were (and still are) correct.

The February 2023 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes. Although we are not aware of any active exploits in the wild, our recommendation is to immediately install these updates to protect your environment.

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed in these SUs and do not need to take any action other than updating Exchange servers in their environment.

More details about specific CVEs can be found in the Security Update Guide (filter on Exchange Server under Product Family).

Update installation

The following update paths are available:

• Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
• Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
• Re-run the Health Checker after you install an SU to see if any further actions are needed.
• If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates.

Known issues with this release

• EWS web application pool stops after the February 2023 Security Update is installed - please note that to simplify the override application, we have now included instructions to apply a global override in case you see the EWS service crash.
• For some customers, who have non-default applications installed through ECP add-ins, the ECP add-ins page might be broken after February SU is installed. We will address this issue in a future update.
• Exchange Toolbox and Queue Viewer fails after Certificate Signing of PowerShell Serialization Payload is enabled (Note: this is an issue with the Certificate Signing of PowerShell Serialization Payload feature, not an issue with the security update.

Issues resolved in this release

• Version error when you install Exchange Server in RecoverServer mode – going forward, February 2023 and newer SUs will not cause this issue (but modifications made by the January 2023 SU might still require manual action during a server recovery operation, so the steps outlined in the article might still apply with later SUs installed)
• After the January 2023 SU is installed on Exchange 2016 or Exchange 2019, web page previews for URLs shared in OWA do not render properly
• Some Exchange services do not start automatically after installing January 2023 Security Update
• PowerShell Serialization Payload Signing can now be enabled if Exchange Server 2013 is in the organization
• This release unblocks customers who are not able to enable Extended Protection (EP) because they are using a Retention Policy with Retention Tags that perform Move-to-Archive actions. Note: if you worked around this problem using the updated Exchange Server Extended Protection script, you should roll back the applied IP restrictions after installing this SU by following the script documentation.

FAQs

Our organization is in Hybrid mode with Exchange Online. Do we need to do anything?
Exchange Online is already protected, but this SU needs to be installed on your Exchange servers, even if they are used only for management purposes. If you change the auth certificate after installing the February 2023 SU, you should re-run the Hybrid Configuration Wizard.

The last SU we installed is a few months old. Do we need to install all SUs in order, to install the latest one?
SUs are cumulative. If you are running a CU supported by the SU, you do not need to install all SUs in sequential order; simply install the latest SU. Please see this update FAQ blog post for more information.

Do we need to install SUs on all Exchange Servers within our organization? What about ‘Management Tools only’ machines?
Our recommendation is to install Security Updates on all Exchange Servers as well as servers or workstations running Exchange Management Tools only, which will ensure that there is no incompatibility between management tools clients and servers.

Updates to this post:

• 3/3/2023: Added the resolved issue for customers who were blocked from enabling Extended Protection and using archiving
• 3/2/2023: Added a known issue related to ECP add-ins page and non-default applications
• 2/17/2023: Linked to the new KB article talking about the EWS crash
• 2/16/2023: Clarification that we recommend that customers impacted by the EWS crash keep the February SU installed and implement the posted workaround
• 2/16/2023: Clarified the EWS crash workaround
• 2/16/2023: Added a known issue related to EWS crash and the workaround
• 2/15/2023: Updated the note about download availability; all update packages should now be correct.
• 2/15/2023: Added a note that there is a build availability problem; please use Download Center until this is resolved.

The Exchange Server Team

On April 11, 2023, less than 60 days from today, Exchange Server 2013 reaches End of Support!

After that date, Microsoft will no longer provide:

• Technical support for problems that may occur
• Bug fixes for issues that are discovered and that may impact the stability and usability of the server
• Security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
• Time zone updates

Exchange Server 2013 will continue to run after this date, of course; however, due to the risks listed above, we strongly recommend that you migrate from Exchange Server 2013 as soon as possible. If you haven't started your migration from Exchange Server 2013 to Exchange Online or Exchange Server 2019, get going now!

In order to stay supported you can:

• Upgrade to Exchange Server 2019 and/or
• Migrate to Exchange Online

If you are upgrading to Exchange Server 2019, learn about what you need in your environment and how to safely decomission Exchange Server 2013 when you are done.

If you're migrating to Exchange Online, you might be eligible to use our Microsoft FastTrack service. FastTrack provides best practices, tools, and resources to make your migration to Exchange Online as seamless as possible. Best of all, you'll have a support engineer walk you through from planning and design to migrating your last mailbox. For more information about FastTrack, see Microsoft FastTrack.

For more information on what this means and what your options are, see Exchange 2013 end of support roadmap.

We’ve said it before, we’re saying it now, and we’ll keeping saying it: it is critical to keep your Exchange servers updated. This means installing the latest available Cumulative Update (CU) and Security Update (SU) on all your Exchange servers (and in some cases, your Exchange Management Tools workstations), and occasionally performing manual tasks to harden the environment, such as enabling Extended Protection and enabling certificate signing of PowerShell serialization payloads.

Attackers looking to exploit unpatched Exchange servers are not going to go away. There are too many aspects of unpatched on-premises Exchange environments that are valuable to bad actors looking to exfiltrate data or commit other malicious acts. First, user mailboxes often contain critical and sensitive data. Second, every Exchange server contains a copy of the company address book, which provides a lot of information that is useful for social engineering attacks, including organizational structure, titles, contact info, and more. And third, Exchange has deep hooks into and permissions within Active Directory, and in a hybrid environment, access to the connected cloud environment.

To defend your Exchange servers against attacks that exploit known vulnerabilities, you must install the latest supported CU (as of this writing, CU12 for Exchange Server 2019, CU23 for Exchange Server 2016, and CU23 for Exchange Server 2013) and the latest SU (as of this writing, the January 2023 SU). Exchange Server CUs and SUs are cumulative, so you only need to install the latest available one. You install the latest CU, then see if any SUs were released after the CU was released. If so, install the most recent (latest) SU.

After installing an update, there may be manual tasks that an admin needs to perform, so always run Health Checker after installing an update to check for such tasks. Health Checker provides you with links to articles that provide step-by-step guidance.

Prior to releasing an SU, we may release a mitigation for a known vulnerability that can be applied to servers automatically by the Exchange Emergency Mitigation Service or manually using the Exchange On-Premises Mitigation Tool. As previously stated, mitigations are designed to provide temporary protection until an SU is available and can be installed. In some cases, mitigations can become insufficient to protect against all variations of an attack. Thus, installation of an applicable SU is the only way to protect your servers.

Updating your Exchange servers is straightforward:

• Be sure to always read our blog post announcements, noting known issues and recommended or required manual actions. For CUs, always follow our guidance and best practices, and for SUs, use the Security Update Guide to find relevant information.
• Be sure to review our update FAQ in the article Why Exchange Server Updates Matter.
• Use the Exchange Server Health Checker to inventory your servers and see which Exchange servers need updates (CUs or SUs), and if any manual action needs to be taken.
• Once you know what updates are needed, use the Exchange updates step-by-step guide (aka the Exchange Update Wizard) to choose your currently running CU and your target CU and get directions for updating your environment.
• If you encounter errors during update installation, the SetupAssist script can help troubleshoot them. And if something does not work properly after updates, have a look at the Update Troubleshooting Guide, which covers the most common issues and how to resolve them.
• Be sure to install any necessary updates for Windows Server and other software that might be running on your Exchange server(s).
• Be sure to install any necessary updates on dependency servers, including Active Directory, DNS, and other servers used by Exchange.

We know that keeping your Exchange environment protected is critical, and we know it’s never ending. We’re here to support our customers any way we can. We are constantly looking for ways to improve the Exchange Server update process, and we’ve posted a survey about that topic which we invite you to take at https://forms.office.com/r/kfLyqAe3Q8.
In the meantime, please update your Exchange servers!

The Exchange Team

We recently enabled a new feature in Office 365, which allows tenant admins to assign more than one Exchange Online license per AAD user.

SharePoint Online and Teams, for example, have been supporting concurrent license assignments for their own services for some time now. Our new feature hence helps bring the same level of support to Exchange Online.

How does it work?

To better understand what this feature changes, let's compare the old behavior of Exchange Online license management, with the new behavior.

Previous experience

When tenant admins tried to assign more than one license pack (which contains Exchange Online) to the same AAD user, either through AAD PowerShell or the Microsoft 365 admin center or through group-based licensing in AAD, an exception message would have been shown and license changes would not have gone through.

For example, if the user already had a Microsoft 365 Business Standard license, and the admin tried to assign a second Exchange Online (Plan 2) license (either the standalone license, or as part of E3 or E5 suites), the following type of exception would have been raised in the Microsoft 365 admin center:

Another example, where a user already has Exchange Online (Plan 1) assigned, and a tenant admin is trying to assign them an additional Microsoft 365 E5 license package:

The same experience would have been seen for any combinations of the following licenses:

• Microsoft 365 Business packages: Basic, Standard, Premium
• Microsoft / Office 365 F1, F2, F3, E1, E3, E5, A1, A3, A5
• Exchange Online Essentials
• Exchange Online Kiosk
• Exchange Online Plan 1
• Exchange Online Plan 2
• Some Teams and Project license packs (see the following section for more information)

Current (new) experience

Any combination of the above-mentioned plans is now allowed. For example, users can be concurrently assigned Microsoft 365 E3 and Office 365 E5 licenses, or Exchange Online Kiosk and Office 365 E3 license etc. The scope also includes the various Education (A) plans.

The legacy plans Office 365 Small Business (BPOS_L), Office 365 Midsize Business (BPOS_S_MidSize), which cannot be bought anymore, but might still exist in production - are not supported by this new feature. The same applies for the license packs we bundle together with British Telecom (BPOS_B).

The following table summarizes which plans support stacking:

 

Commercial Offering	Contained Exchange License	Mapped Exchange Capability
Exchange Online Essentials	Exchange Online Essentials	BPOS_S_Essentials
Microsoft 365 Business Starter
Exchange Online Kiosk	Exchange Online Kiosk	BPOS_S_Deskless
Microsoft 365 F1
Microsoft 365 F3
Microsoft Teams Essentials
Office 365 F2
Office 365 F3
Exchange Online (Plan 1)	Exchange Online (Plan 1)	BPOS_S_Standard
Exchange Online (Plan 1) for Alumni
Exchange Online (Plan 1) for Faculty
Exchange Online (Plan 1) for Students
Microsoft 365 A1
Office 365 A1
Microsoft 365 Business Basic
Microsoft 365 Business Standard
Microsoft 365 Business Premium
Microsoft Teams Exploratory
Microsoft 365 E1
Office 365 E1
Office 365 E2
Office 365 Education E1 for Faculty
Office 365 Education E1 for Students
Office 365 Education
Exchange Online (Plan 2)	Exchange Online (Plan 2)	BPOS_S_Enterprise
Exchange Online (Plan 2) for Faculty
Exchange Online (Plan 2) for Students
Microsoft 365 A3
Microsoft 365 A5
Microsoft 365 E3
Microsoft 365 E5
Microsoft Teams Shared Devices
Office 365 E3
Office 365 E3 Developer
Office 365 E5
Office 365 Education E3
Project A Subscription

Here is an example where an AAD user had concurrently assigned 4 different license types (note that Office 365 E3 and Exchange Online Plan 2 contain the same Exchange Online license).

Please note that AddOn plans' assignment has not changed - the experience with assigning AddOn plans has always been the same, in that multiple AddOn licenses can be assigned to the same user.

What does actually happen in Exchange Online?

Exchange Online will decide on which of the actively assigned plans is the most “superior” and will ensure the features of this superior plan are available to the corresponding Exchange Online user (Mailbox User or Mail User). By ‘features’ here we refer to mailbox quotas, transport limits, protocol access etc.

When a license is removed from the AAD user, or when a license expires, the new collection of actively assigned licenses is evaluated and the new superior plan is chosen.

Hence, the new feature supports license demotions and promotions: for example, if the user has E3 and Kiosk assigned, but E3 is then removed from the AAD user, then Exchange Online will ensure the corresponding Mailbox User or Mail User will be granted access to Kiosk features only. If the user is later also assigned E5, Exchange Online will grant the user access to all the features of E5, regardless of if the user still has assigned a concurrent Kiosk license.

Exchange Online maps AAD or Microsoft 365 admin center license pack names to "capabilities", as detailed by the table above, which lists supported, stackable license packs and their corresponding capabilities. As such, in order of superiority from least superior to most superior, we have:

• Exchange Online Essentials, which maps to the capability "BPOS_S_Essentials"
• Exchange Online Kiosk, which maps to the capability "BPOS_S_Deskless"
• Business Basic, Standard, Premium and E1, which all map to the capability "BPOS_S_Standard"
• Microsoft/Office E3 and E5 plans, which map to the capability "BPOS_S_Enterprise"

What are the benefits of this approach?

Over time, the lack of this “license stacking” feature has caused customers to raise incidents with Microsoft Support. For some, it was a burden to have to manually remove the old Exchange Online license first, and then assign the new license. In some cases, if this procedure wasn't followed correctly, the Exchange Online mailbox might have been removed and put in a recoverable state for the next 30 days.

For our large Enterprise customers, who manage large license packs, it was an even bigger burden to manage license assignments. In most cases, large Enterprises manage license assignments through group-based licensing. With users being part of multiple control groups, it was a burden for admins to figure out which group to remove the user from. Often, this was managed through automation which involved complicated scripts. With the new feature, tenant admins can now manage license assignments in an easier way.

As a tenant admin, you would still need to run reporting on license assignments and determine which users might have more than one Exchange Online license assigned. You might then elect to remove the least superior licenses from that user and send them back to the pool of unused licenses, so other users can benefit from them. This is important to understand: if two (or more) licenses are assigned, all of them are “in use” (and might be billed).

The feature will also aid with license pack transitions for other services, such as Teams. We already have a success story for the transition of users from Teams Exploratory packages to Teams Essentials/Basic/Standard packages. Many services in Office 365 (Teams included) rely on Exchange Online to either store data in or to access data from mailboxes. For this reason, license packs constructed for Teams or SharePoint or other services, will sometimes include an Exchange Online license as well. Before the changes went live, the lack of support for stacking of Exchange Online licenses had been a blocker for other services such as Teams. With the new feature, Teams can now easily allow transitions of users from one Teams package to another, without causing any data loss or end user experience disruptions.

How to programmatically check which licenses are assigned to a given Exchange Online user?

We introduced a new property in Exchange Online, which exposes all the licenses assigned to a given user. Here is an example of how to verify a sample user using Exchange Online PowerShell:

 

 

Get-Mailbox test1 | select SkuAssigned, PersistedCapabilities
SKUAssigned PersistedCapabilities
----------- ---------------------
       True {MYANALYTICSP2, BPOS_S_BookingsAddOn, BPOS_S_Enterprise}

Get-Recipient test1 | select RootCapabilities

RootCapabilities
----------------
BPOS_S_Essentials, BPOS_S_Deskless, BPOS_S_Standard, BPOS_S_Enterprise

 

 

In this example, the user "test1" (mailbox user) has a license assigned (SKUAssigned = True), and the superior license assigned to him has the capability BPOS_S_Enterprise. This capability, as previously explained, maps to either E3/E5 or the standard Exchange Online (Plan 2).

In the output of Get-Recipient, the new property RootCapabilities, contains all the Exchange Online active licenses assigned to this user - the output above shows that the user is actually granted 4 different Exchange Online licenses, but because BPOS_S_Enterprise is the most superior one, then that license's features are applied to the Exchange Online user.

Please note that, being a newly introduced property, RootCapabilities will be stamped with a blank value for existing recipient objects. Once a license change is made for an existing recipient, the RootCapabilities property will be updated with the correct value. The property will also be updated once recipient sync flows will occur in the data centers automatically or as part of Microsoft Support investigations. For recipient objects created after December 15th 2022, the RootCapabilities property is already populated correctly.

What is next?

We are planning to add the same license stacking support for the equivalents of the above-mentioned license packs, for all Sovereign clouds (including Office 365 operated by 21Vianet) and Government clouds. This will be achieved in the first half of CY2023.

Alexandru Grosu and the Exchange Online Provisioning team

Update 2/1/2023: The survey is now closed; thank you for your feedback!

We’re looking into ways in which we can improve the experience of installing Exchange Server Cumulative Updates (CUs) and Security Updates (SUs).  We’d love to get your input and feedback.

We have created a brief survey for you which we will keep open until the end of this month.  The survey is anonymous, but we do give you an option to share your contact info with us if you’re open to discussing this further with us.

Please take a few moments to respond to this survey and let us know what we can do to improve the experience of installing Exchange Server updates.

Microsoft Exchange Server - Update Experience Survey
(link removed on 2/1/2023)

Exchange Server Team

Inactive mailboxes in Exchange Online are a vital part of the Microsoft Purview Data Lifecycle Management capabilities. They offer a low/no-cost and versatile way of retaining mailbox data according to your organization’s requirements. At times, though, it’s necessary for an inactive mailbox and/or its data to be moved to a user-accessible state. In those cases the options for retrieval include three methods: Recover, Restore or export with content search. Each method involves its own tools and procedures. Which one is best depends, again, on your organization’s requirements. The recover and restore methods are relatively straightforward; most Exchange administrators are familiar with the concepts and cmdlets associated with each. The content search method, on the other hand, is the least intuitive.

Content search, albeit a powerful tool when applied to typical use cases, doesn’t come with much guidance on the topic of retrieving inactive mailbox data. This post offers a way to use its strengths to bring back inactive mailbox data, in part or in whole, while preserving much of the structure of the source mailbox. Further, when inactive mailboxes include auto-expanding archiving and auxiliary archives, only the content search method is available to bring back the data.

Enabling auto-expanding archiving alone does not limit inactive mailbox data retrieval to content search. That happens when one or more auxiliary archive mailboxes are generated. Use the following command to check if a mailbox has auxiliary archives:
Get-Mailbox <MailboxID> | Select-Object -ExpandProperty MailboxLocations

In this example, the archive mailbox has an auxiliary archive mailbox, noted in green, confirming that auto-expanding archiving is enabled and in use. Larger archive mailboxes may have multiple AuxArchive locations.

Methodology

The documentation for content search for targeted collections describes how an admin can run Get-MailboxFolderStatistics to reveal the folder ID value for each folder in a mailbox. This can be done for both primary and archive mailboxes, along with their respective Recoverable Items folders. The folder ID values can be built into a search query identifying each folder to search for items and later export.

This is straightforward, but there’s a catch when it comes to inactive mailboxes. In their case it may not be possible to run Get-MailboxFolderStatistics on a mailbox without an active mailbox identity. For targeted collection content searches to work with inactive mailboxes it’s a critical prerequisite to collect the folder ID values before a mailbox is made inactive. Administrators intending to use the content search method should integrate the following steps for inactive mailboxes as part of data lifecycle management. We cannot guarantee any inactive mailboxes created without first collecting the folder ID values (assuming the mailbox owner’s account is not recoverable from Azure AD) will be eligible for using content search for targeted collections.

Preparing for target collection content search

Enumerate mailbox folder ID values

Use the guidance in Use Content search for targeted collections to prepare a script for collecting the folder ID values for a mailbox slated to be made inactive. A sample script (a bit modified from the sample in that article) is provided as the GetFolderSearchParameters.zip attachment to this blog post.

Run the script for the mailbox in preparation for conversion to inactive. In this example, the script shows the folder ID values in the console, and it also generates a CSV file with the list for both the primary and archive mailboxes.

Verify and store the folder ID data

Confirm that the list of folders and the FolderID property values match the folder list in the primary and archive mailboxes. Put the list in a safe storage location where it will be retained at least as long as the inactive mailbox. Remember, this data is critical for this method to work; if this data is lost, so is the ability to use content search for a targeted collection.

Recommended best practice: Send the CSV with folder ID data as an attachment by email into the mailbox from where the data came. Use a distinct subject or other attribute that can be easily searched should the need to retrieve the data arise. At that time an admin can use content search to locate the CSV attachment, export it, and then use the data to search the targeted collection. This way no separate storage is required, and the list is retained in the inactive mailbox.

With the folder ID attribute data secured, the process to create an inactive mailbox can proceed.

Targeted Collection of Inactive Mailbox Data Procedure

When the time comes to retrieve data from an inactive mailbox using content search, the first step is to obtain the list of folder ID values for the mailbox. If the folder ID data was sent by email to the now inactive mailbox, a preliminary content search will quickly retrieve that list. Of course, if the data was stored outside the mailbox, it must be opened from the alternative storage. In that case skip to the section called “Create, name and specify a mailbox location for a targeted collection content search.”

Preliminary content search to export the folder ID data

In the Microsoft Purview compliance portal go Content search and select New search.

Name the search, provide an optional description, and then choose a location. Switch Exchange mailboxes to On and select “Choose users, groups, or teams.”

Use the email address of the inactive mailbox to locate it. An inactive mailbox will start with a “.” in the result:

In our example, a CSV of the data was generated by the sample script and emailed to the mailbox itself as an attachment with the subject of “FolderID Values for Targeted Collection.” That subject can be used for the search to retrieve the folder ID data.

Once this preliminary search is complete, folder ID data can be exported, allowing the more extensive targeted collection to proceed.

Content search sample review allowing the export of folderID properties from an inactive mailbox.

Create, name and specify a mailbox location for a targeted collection content search

The first few steps are like those for setting up the preliminary search in the previous section. In the Microsoft Purview compliance portal, go to Content search and select New search.

Name the search, provide an optional description, and then choose a location. Switch Exchange mailboxes to On and select “Choose users, groups, or teams.”

Use the email address of the inactive mailbox to locate it. Inactive mailboxes start with a “.” in the results.

With the inactive mailbox chosen for the location to search, the targeted collection query can be built.

Build the targeted collection search query using the FolderID values

In the “Define your search conditions section” use the default Keywords query builder and enter the folderID values for search. To retrieve data from a folder, its FolderID value must be added to the query and joined to the rest by an “OR” clause, like this:

FolderID:<FolderIDValue1> OR FolderID:<FolderIDValue2> OR FolderID:<FolderIDValue3>

Suppose, for example, that an admin needs to retrieve data from the Presentations folder in the primary mailbox of Test User87 as well as the Inbox and the Inbox\Lab subfolders from the archive mailbox. The admin should copy the folder ID values for each folder listed in the mailbox’s CSV.

Each folder or subfolder must have its value added to the query, the search will not automatically recurse down from a parent folder.

The admin opens the CSV file and locates the folders, highlighted with green boxes. Each of the three folders has a unique FolderID value, highlighted in red boxes. To build the content search query those three values are put into the content search query, like this:

folderid:A6EDA8618658144A8D6F2C0A43812D6F0000000018EA0000 OR
folderid:15DB8FE3100F1542994F475280A489070000000001280000 OR
folderid:15DB8FE3100F1542994F475280A489070000000001330000

 

In the portal, the search query looks like this:

For brevity, a small number of folders are used for illustration here, but if the admin wants to find and export the closest thing to the entire mailbox then a query can include all of the IPM subtree FolderID values along with those for each of the Recoverable Items folders.

It is possible to use PowerShell to create and manage the search using the *-ComplianceSearch cmdlets, as documented here. Consider that a script can be used to automatically parse a CSV of FolderID values into an array to pass into a New-ComplianceSearch instance. How that would work is outside the scope of this post, but it’s mentioned to convey that staging and running the search can be almost entirely automated.

Export and download the data

The fine detail on how to verify the search, review samples, and then export the results isn’t necessary here. The steps aren’t different from how they are generally. For the export it’s up to the admin to pick the options that make the most sense. In our example, the default of one PST for each mailbox is chosen with no de-duplication enabled:

It should be noted, though, that exporting content search data to a PST file has a size limit of 10GB. In most cases it will require quite a few of PSTs no matter how the export is configured. The export result will be a series of PSTs like this:

If each PST is opened in Outlook, the exported folder data will appear this way:

Conclusion

With a prerequisite of preparation (to get folder IDs), the ability to use content search to locate and export data from some or all the folders in an inactive mailbox (including its archive) is a powerful option. Especially for customers working with auto-expanding archives, this is a potential lifeline to a seamless data lifecycle management plan. The 10GB PST file limit may be burdensome if using only the Outlook client, but there are several different ways of working with large numbers of PST files to import data from them into a mailbox (a topic for a different post). Please leave a comment, questions, or feedback!

I wanted to thank Jay York, Nino Bilic, Linda Harrell, and Scott Schnoll for their collaboration in producing this post.

Jesse Tedoff
Sr. Cloud Solution Architect - Engineering

On April 11, 2023, less than 90 days from today, Exchange Server 2013 reaches End of Support!

After that date, Microsoft will no longer provide:

• Technical support for problems that may occur
• Bug fixes for issues that are discovered and that may impact the stability and usability of the server
• Security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
• Time zone updates

Exchange Server 2013 will continue to run after this date, of course; however, due to the risks listed above, we strongly recommend that you migrate from Exchange Server 2013 as soon as possible. If you haven't started your migration from Exchange Server 2013 to Exchange Online or Exchange Server 2019, get going now!

In order to stay supported you can:

• Upgrade to Exchange Server 2019 and/or
• Migrate to Exchange Online

If you are upgrading to Exchange Server 2019, learn about what you need in your environment and how to safely decomission Exchange Server 2013 when you are done.

If you're migrating to Exchange Online, you might be eligible to use our Microsoft FastTrack service. FastTrack provides best practices, tools, and resources to make your migration to Exchange Online as seamless as possible. Best of all, you'll have a support engineer walk you through from planning and design to migrating your last mailbox. For more information about FastTrack, see Microsoft FastTrack.

For more information on what this means and what your options are, see Exchange 2013 end of support roadmap.

Microsoft has released Security Updates (SUs) for vulnerabilities found in:

• Exchange Server 2013
• Exchange Server 2016
• Exchange Server 2019

SUs are available in a self-extracting auto-elevating .exe package, as well as the original update packages (.msp files), which can be downloaded from the Microsoft Update Catalog.

SUs are available for the following specific versions of Exchange Server:

• Exchange Server 2013 CU23 (note that support and updates end on April 11, 2023)
• Exchange Server 2016 CU23
• Exchange Server 2019 CU11 and CU12 

The January 2023 SUs address vulnerabilities responsibly reported to Microsoft by security partners and found through Microsoft’s internal processes. Although we are not aware of any active exploits in the wild, our recommendation is to immediately install these updates to protect your environment.

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed in these SUs and do not need to take any action other than updating Exchange servers in their environment.

More details about specific CVEs can be found in the Security Update Guide (filter on Exchange Server under Product Family).

Defense-in-depth: Enable Certificate Signing of PowerShell Serialization Payload

Serialization is the process of converting the state of an object into a form (stream of bytes) that can be persisted or transmitted to memory, a database, or a file. PowerShell, for example, uses serialization (and its counterpart deserialization) when passing objects between sessions. To defend Exchange servers against attacks on serialized data we’ve added certificate-based signing of PowerShell serialization payloads in the January 2023 SUs. In the first stage of rollout, this new feature must be manually enabled by an Exchange Server admin due to feature dependencies. This article details the steps to enable certificate-based signing of serialization data in Exchange Server. We have also released a script you can use to validate/create the required auth certificate in your organization or you can do it manually.

Update 1/12/2023: if you have an Exchange Server 2013 in your environment, turning on the signing of serialization payload feature might lead to several issues impacting management in your organization. We recommend not to turn on this feature for now. We will address this in the future update. Customers with Exchange Server 2016 / 2019 only can proceed with using the certificate signing of PowerShell serialization payload feature.

Update installation

The following update paths are available:

  

• Install the latest CU. Use the Exchange Update Wizard to choose your current CU and your target CU to get directions.
• Inventory your Exchange Servers to determine which updates are needed using the Exchange Server Health Checker script. Running this script will tell you if any of your Exchange Servers are behind on updates (CUs, SUs, or manual actions).
• Re-run the Health Checker after you install an SU to see if any further actions are needed.
• If you encounter errors during or after installation of Exchange Server, run the SetupAssist script. If something does not work properly after updates, see Repair failed installations of Exchange Cumulative and Security updates.

Known issues with this release

• If Exchange Server 2016 is installed on Windows Server 2012 R2, after installation of the January 2023 SU, the AD Topology service might not start automatically, causing services that depend on it to not start automatically either. To work around this problem, start Exchange services manually. Please see Some Exchange services do not start automatically after installing January 2023 Security Update.
• Once the update is installed on an Exchange Server 2016 or 2019, web page previews for URLs shared in OWA will not be rendered properly. We will resolve this in a future update.
• Version error when you install Exchange Server in RecoverServer mode

FAQs

When should we enable the new certificate signing of PowerShell serialization payload feature?
This feature should be enabled only after you have updated all your Exchange Servers to the January 2023 (or newer) SU. Enabling the feature before all servers are updated might lead to failures and errors when managing your organization.

Why do we need to enable the new certificate signing manually? Why does Microsoft not enable the feature automatically?
Our intention is to enable certificate signing of PowerShell serialization payload by default in a future update. The feature relies on a valid auth certificate being present in the organization, so we wanted to give admins a chance to validate their certificate before enabling a feature that depends on it (certificate issues could lead to unexpected results and errors if the feature was enabled by default.) We have released a script you can use to validate / create this certificate.

Our organization is in Hybrid mode with Exchange Online. Do we need to do anything?
Exchange Online is already protected, but this SU needs to be installed on your Exchange servers, even if they are used only for management purposes. If you change the auth certificate after installing the January 2023 SU, you should re-run the Hybrid Configuration Wizard.

The last SU that we installed is a few months old. Do we need to install all SUs in order, to install the latest one?
SUs are cumulative. If you are running a CU supported by the SU, you do not need to install all SUs in sequential order; simply install the latest SU. Please see this blog post for more information.

Updates to this post:

• 1/25/2023: Added a link to a KB article on services not starting automatically if Exchange 2016 is installed on Windows Server 2012 R2.
• 1/23/2023: Added a link to a KB article for one of known issues.
• 1/12/2023: Added a note that signing of serialization payload feature is not recommended at this time if Exchange Server 2013 is present in the organization. If you have Exchange Server 2013 and already enabled this feature, you can simply disable it.
• 1/11/2023: Added an issue (still being investigated) where Exchange services might not start automatically if update is installed on an Exchange Server 2016 running on Windows Server 2012 R2.
• 1/10/2023: Added a link to Certificate signing of PowerShell serialization payload in Exchange Server KB article.

The Exchange Server Team