How and when to decommission your on-premises Exchange servers in a hybrid deployment

Artikel
10/24/2023

Note

Currently, if you keep an Exchange server running just for recipient management, you may be able to shut down your last Exchange server and manage recipients using Windows PowerShell. For more information, see Manage recipients in Exchange Hybrid environments using Management tools.

Read this article if you're ready to move from an Exchange hybrid deployment to a full cloud implementation.

Exchange Server hybrid deployments describes one of the most attractive options for getting a company to Exchange Online. This method is the only option that allows you to easily on-board and off-board mailboxes (all other native options are on-board only). In addition to the ability to off-board, a hybrid configuration has the following key options.

This article helps you understand the options for decommissioning Exchange hybrid, and when each of those options should be implemented. There are many variances in when and how to decommission Exchange hybrid servers. Taking the time to understand the implications and properly plan the full or partial decommissioning of on-premises servers is important.

Cross-premises availability: Allows you to see a user's free/busy information while scheduling a meeting, regardless of their mailbox premises.
Cross-premises archive: Allows a customer to move only a user's archive mailbox to the cloud. This move is often the first step for customers to try Microsoft 365 and Office 365, and, more specifically, Exchange Online.
Cross-premises discovery searches: Allows a customer to perform an e-discovery search that crawls mailboxes and archives in both premises (this feature requires you to configure OAuth authentication).
Outlook Web App URL redirection: Allows for users to be redirected to the proper premises for Outlook Web App access.
No profile recreation after move: Unlike other migration options, the mailbox GUID doesn't change. In other words, you don't have to recreate your profile or redownload the OST after a mailbox move.

Depending on your organization's needs, a hybrid deployment is the best option for providing the most seamless user and coexistence experience.

Other methods to migrate to Exchange Online

A hybrid deployment isn't for everyone; in fact there are better options. Many of the tenants that have chosen to deploy a hybrid configuration are under 50 seats. While the list of advantages of a hybrid deployment may sound attractive, it comes with a hefty price, regarding complexity. Some smaller tenants require the features of a hybrid deployment. But most tenant would use either a cutover, staged, or IMAP migration option. There's a program called FastTrack you can use when deciding on the migration approach to take. Information on FastTrack is described on the Microsoft 365 FastTrack page.

Use the following table to decide what type of migration works for your organization. (For more information, see Ways to migrate multiple email accounts to Microsoft 365 or Office 365.)

Existing organization	Number of mailboxes to migrate	Do you want to manage user accounts in your on-premises organization?	Migration type
Exchange 2003 or later	Less than 2,000 mailboxes	No	Cutover Exchange migration
Exchange 2007 or Exchange 2003	Less than 2,000 mailboxes	No	Staged Exchange migration
Exchange 2007 or Exchange 2003	More than 2,000 mailboxes^*	Yes	Staged Exchange migration or remote move migration in an Exchange hybrid deployment
Exchange 2010 or later	More than 2,000 mailboxes^*	Yes	Remote move migration in an Exchange hybrid deployment
Exchange 2000 Server or earlier versions	No maximum	Yes	IMAP migration
Non-Exchange on-premises messaging system	No maximum	Yes	IMAP migration

^*Some organizations with fewer than 2,000 mailboxes may benefit from features and capabilities that are only available with a hybrid deployment. It's important to carefully consider the benefits of a hybrid deployment with the complexity that introduces. We strongly recommend that customers with fewer than 2,000 mailboxes consider cutover or staged migration before proceeding with a hybrid deployment.

Why you may not want to decommission Exchange servers from on-premises

Customers with a hybrid configuration often find after a period of time that all of their mailboxes have been moved to Exchange Online. At this point, they may decide to remove the Exchange servers from on-premises. However, they discover that they can no longer manage their cloud mailboxes.

When directory synchronization is enabled for a tenant and a user is synchronized from on-premises, you can't manage most attributes from Exchange Online. Instead, you must manage those attributes from on-premises. This requirement isn't due to the hybrid configuration, but it occurs because of directory synchronization. In addition, even if you have directory synchronization in place without running the Hybrid Configuration Wizard, you still can't manage most of the recipient tasks from the cloud. For more information, see this blog article.

Can third-party management tools be used?

The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they aren't supported. The Exchange Management Console, the Exchange admin center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects. If you decide to use third-party management tools, it would be at your own risk. Third-party management tools often work fine, but Microsoft doesn't validate these tools.

Common scenarios

It isn't simple to move from a hybrid configuration to the cloud. The process for getting into a hybrid configuration is one that we've taken time to get right. While there are issues, we feel we've done a pretty good job of making the almost impossible task of going hybrid a fairly easy wizard-based process.

Depending on your immediate goals, however, getting from a hybrid configuration to the cloud only can be a fairly straight-forward process, with some guidance. The following are three common hybrid scenarios along with our recommendation for how to properly achieve the end goal of the customer.

Since the hybrid customer base is diverse, trying to fit all of them into "common" scenarios is difficult. We attempted to provide some high-level scenarios for on-premises Exchange Server decommissioning below, so as you read through these scenarios and formulate a plan to decommission, you need to determine the scenario that best fits your needs.

Scenario one

Issue: My organization has been running in a hybrid configuration and I have all of my mailboxes in Exchange Online. I don't need to manage my users from on-premises and no longer have a need for directory synchronization or password synchronization.

Solution: Since all of the users will be managed in Microsoft 365 or Office 365, and there are no other directory synchronization requirements, you can safely disable directory synchronization and remove Exchange from the on-premises environment.

Remove Exchange from the on-premises environment.

To disable directory synchronization and uninstall Exchange hybrid

Run Get-OrganizationConfig | Format-List PublicFoldersEnabled and ensure that it isn't set to Remote. If it's set to Remote, and the public folders are something you want to continue to access, you would need to migrate them to Exchange Online. For more information, see Use batch migration to migrate legacy public folders to Microsoft 365, Office 365, and Exchange Online.
Assuming that you have already moved all of the mailboxes to Exchange Online, you can point the MX and Autodiscover DNS records to Exchange Online, instead of to on-premises. For more information, see External Domain Name System records for Office 365.

Important

Make sure to update both the internal and external DNS, or you may have inconsistent client connectivity behavior.
Next, you should remove the Service Connection Point (SCP) values on your Exchange servers. This step ensures that no SCPs are returned, and the client instead uses the DNS method for Autodiscover. Some examples are shown below:

Exchange Server 2010 or 2013:
```
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $Null
```
Exchange Server 2016 or later:
```
Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri $Null
```
Note

If you have Exchange 2007 servers in the environment, you'll have to run a similar command on your Exchange 2007 servers to change these settings.
There are inbound and outbound connectors created by the Hybrid Configuration Wizard that you want to delete. Use the following steps to do this:
1. Sign in to the Microsoft 365 admin center and sign in as the Tenant Administrator.
2. Select the option to manage Exchange.
3. Navigate to Mail Flow -> Connectors.
4. You can now disable or delete the inbound and outbound connectors. The HCW creates connectors with unique namespace inbound from <unique identifier> and outbound from <unique identifier> as shown in the graphic below.
Remove the organization relationship created by the Hybrid Configuration Wizard. Use the following steps to do this:
1. Sign in to the Microsoft 365 admin center and sign in as the Tenant Administrator.
2. Select the option to manage Exchange.
3. Navigate to Organization.
4. Under Organization Sharing, remove the organization named O365 to On-Premises - <unique identifier> as shown in the graphic below.
If OAuth is configured for an Exchange hybrid deployment, disable the configuration from both on-premises and Microsoft 365 or Office 365. In most environments, you can skip these steps because only a small number of customers have OAuth configured.

To disable the on-premises configuration:
1. From an Exchange server, open the Exchange Management Shell.
2. Run the following command:
```
Get-IntraorganizationConnector -Identity ExchangeHybridOnPremisesToOnline | Set-IntraOrganizationConnector -Enabled $False
```
To disable the Exchange Online configuration:
1. Connect Windows PowerShell to Exchange Online.
2. Run the following command:
```
Get-IntraorganizationConnector -Identity ExchangeHybridOnlineToOnPremises | Set-IntraOrganizationConnector -Enabled $False
```
Note: The Identity parameter assumes that you used the Hybrid Configuration Wizard to configure OAuth. If not, you may need to adjust the value you specified for the identity of the connectors.
Disable directory synchronization for your tenants. When this step is completed, all user management tasks are done from the Microsoft 365 or Office 365 management tools. In other words, you'll no longer use the Exchange Management Console or Exchange admin center (EAC). For more information on how to disable directory synchronization, see Turn off directory synchronization for Microsoft 365 or Office 365.
You can now safely uninstall Exchange from the on-premises servers.

Scenario two

Issue: My organization has been running in a hybrid configuration for about a year now and has finally moved my last mailbox to the cloud. I plan to keep Active Directory Federation Services (ADFS) for user authentication of my Exchange Online mailboxes.

Important

This scenario applies to any customer planning to keep directory synchronization, and to keep Exchange Server on-premises to manage their recipients using Exchange Admin Center (EAC). If you don't require the use of EAC for management of recipients in your hybrid organization, you can remove the last Exchange Server on-premises, while keeping the directory synchronization.

For more information, see Manage hybrid exchange recipients with management tools.

Solution: Since the customer is planning on keeping AD FS, they'll also have to keep directory synchronization since it's a prerequisite. Because of that, they can't fully remove the Exchange servers from the on-premises environment. However, they can decommission most of the Exchange servers, but leave a couple of servers behind for user management. Keep in mind that the servers that are left running can be run on virtual machines since the workload is shifted to Exchange Online.

The graphic below describes the desired end state:

Decommission Exchange servers with some remaining.

The graphic below describes the actual end state:

State before decommissioning Exchange servers.

Tip

If you choose to remove ADFS from your infrastructure, cloud sync or Microsoft Entra Connect will synchronize your on-premises credentials with the cloud. Each service will authenticate users independently:

Microsoft 365 identity services will manage online requests.
Active directory will manage the internal authentication.

If you don't have any on-premises mailbox(es), you can safely decommission most of your exchange server(s), leaving one or more for user management purposes, because the source of authority is still defined as on-premises.

To keep AD FS and directory synchronization and decommission most of the Exchange servers

Run Get-OrganizationConfig |fl PublicFoldersEnabled and ensure that it isn't set to remote. If it is set to remote and you want to continue to access the public folders, you would need to migrate them to Exchange Online. For information on how to do this, see Use batch migration to migrate legacy public folders to Microsoft 365, Office 365, and Exchange Online.

Important

If migrating public folders to Exchange Online isn't an option, and you still need them for your users, you should not move forward.
After you have moved all of the mailboxes to Exchange Online, the first step in decommissioning most of your Exchange servers is to point the MX and Autodiscover DNS records to Exchange Online instead of to your on-premises email organization. For more information, see External Domain Name System records for Office 365.

Important

Make sure to update both the internal and external DNS, or you may have inconsistent client connectivity and mail flow behaviors.
Next, you should remove the Service Connection Point (SCP) values on your Exchange servers. This step ensures that no SCPs are returned, and the client instead uses the DNS method for Autodiscover. An example is shown below:

Exchange Server 2010 or 2013:
```
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $Null
```
Exchange Server 2016 or later:
```
Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri $Null
```
Note

If you have Exchange 2007 servers in the environment, you'll have to run a similar command on your Exchange 2007 servers to null out the settings
To prevent the hybrid configuration objects from being recreated in the future, you should remove the hybrid configuration object from Active Directory. To do this, open the Exchange Management Shell and run the following:
```
Remove-HybridConfiguration
```
Remove all Exchange servers except for the servers you retain for user management and creation. Two servers should be sufficient for user management, although you could possibly get by with one server. In addition, there's no need to have a Database Availability Group or any other high availability options.
If OAuth is configured for an Exchange hybrid deployment, disable the configuration from both on-premises and Microsoft 365 or Office 365. In most environments, you can skip these steps because only a few customers have OAuth configured.

To disable the on-premises configuration:
1. Open the Exchange Management Shell from an Exchange server.
2. Run the following command:
```
Get-IntraorganizationConnector -Identity ExchangeHybridOnPremisesToOnline | Set-IntraOrganizationConnector -Enabled $False
```
To disable the Exchange Online configuration:
1. Connect Windows PowerShell to Exchange Online.
2. Run the following command:
```
Get-IntraorganizationConnector -Identity ExchangeHybridOnlineToOnPremises | Set-IntraOrganizationConnector -Enabled $False
```
Note: The Identity parameter assumes that you used the Hybrid Configuration Wizard to configure OAuth. If not, you may need to adjust the value you specified for the identity of the connectors.
There are inbound and outbound connectors created by the Hybrid Configuration Wizard that you should delete. Use the following steps to do this:
1. Sign in to the Microsoft 365 admin center and sign in as the Tenant Administrator.
2. Select the option to manage Exchange.
3. Navigate to Mail Flow -> Connectors.
4. You can now disable or delete the inbound and outbound connectors. The HCW creates connectors with unique namespace inbound from <unique identifier> and outbound from <unique identifier> as shown in the graphic below.
Remove the organization relationship created by the Hybrid Configuration Wizard. Use the following steps to do this:
1. Sign in to the Microsoft 365 admin center and sign in as the Tenant Administrator.
2. Select the option to manage Exchange.
3. Navigate to Organization.
4. Under Organization Sharing, remove the organization named O365 to On-Premises - <unique identifier> as shown in the graphic below.

Note

It's recommended that you leave the Exchange Hybrid Deployment feature enabled in cloud sync or Microsoft Entra Connect.

Scenario three

Issue: I want to remove my Exchange servers on-premises after moving all of my mailboxes to Exchange Online. However, we discovered that they're using Exchange for other purposes, such as for a Simple Mail Transfer Protocol (SMTP) relay for an application or for access to public folders. If you have a need for Exchange servers on-premises to meet the current needs of your organization, it may not be in your best interest to remove the on-premises servers.

Solution: We recommend against removing Exchange and the hybrid configuration at this point. If you were to even start the process by pointing the Autodiscover Records to Exchange Online, you would immediately break some features like hybrid public folder access. You could change the MX record to point to Exchange Online Protection if it isn't already, you could even remove some of the on-premises Exchange servers. However, you would need to keep enough in place to handle the remaining hybrid functions. Usually, this action would lead to a small on-premises footprint. Exchange-only services and features, such as public folders, require you to either maintain your on-premises Exchange servers or migrate those services to Exchange Online. Per scenarios one and two, if you maintain identity synchronization from Active Directory, you'll need to continue to maintain at least one Exchange server on-premises.

Delen via