Migration and coexistence of mail systems
Periodically, the task of migrating from one mail system to another arises. Due to the fact that often these systems do not have regular coexistence functionality, their joint use may not be the easiest task. The transition from one system to another may look like this - starting on Friday evening, the system administrator configures the servers, reconfigures users' email clients, and transfers user data. Despite his efforts, Monday may turn out to be a very "fun" day: either not all the data was transferred, or some old system cannot send messages.
I would like to talk about another option for sharing mail systems, thanks to which you can achieve a smooth migration of users and smooth out possible problems.
For further description, I will use specific mail systems, but I will try to maintain the applicability of this description for other systems. I will use Microsoft Exchange 2013 as the old mail system, and Google Apps for Business will act as the new mail system. Outside of this article is the process of migrating user data, since it is very dependent on the current and future mail systems.
I would like to highlight 2 key stages of coexistence. The main purpose of the first stage is to check whether the functionality of the new mail system suits you. During the second stage, the main user migration occurs.
The main goal of this stage is to check the capabilities of the new mail system and eliminate all problems found. The main users at this stage are system administrators, whose mail is automatically delivered to both mail systems.
Such delivery is implemented using an additional domain and message routing rules. The MX of the primary domain, in our case, let it be example.com , points to the old mail system. The MX of the additional domain gtest.example.com points to the Google server. Instead of the additional domain, you can use the test domain provided by Google example.com.test-google-a.com , to maintain the universality of the method, I will use the additional domain.
On the old mail system, you need to configure forwarding a copy of messages to another domain. For a small number of users, this is easiest to do with transport rules with the addition of a hidden recipient (BCC).
To optimize the operation of anti-spam on Google servers, you need to specify the old mail server as an incoming mail gateway, since a large number of incoming messages is possible from this server.
Messages are delivered via the main MX record to the old mail system. If you need to deliver a copy of the message to Google Apps, the transport rule adds BCC in the secondary domain.
Each system can independently send messages to external recipients. If necessary, Google can use the old mail system as a mail gateway. This may be necessary if, before sending messages to external recipients, additional processing of mail occurs, for example, with the DLP system.
Mail is delivered to the recipient in his local mailbox. If necessary, a copy of the letter is sent to an additional domain.
Google delivers messages according to MX records. A message sent from Google Apps will be delivered to the local mail system, and, according to local transport rules, a copy of the message can be sent to Google Apps.
It makes sense to move on to this stage when most of the problems found have been eliminated and there is an understanding that the new system fully meets the requirements put forward.
At the second stage of integration, the optimal method of coexistence is separate delivery. Mail messages are delivered to the system that is basic for a particular user. The primary domain MX points to Google Apps, which receives all incoming mail. If the recipient's primary mail system is the old system, the message is forwarded to the local mail server.
On the local mail system, you can configure in several ways.
You need to add a host to forward messages to it.
Configure a routing rule.
All incoming messages are delivered to Google Apps. If the recipient is in Google Apps, the message is delivered to his inbox. If the recipient does not exist, the message is forwarded to the local mail system, which delivers it to the local mailbox.
Each system is capable of sending messages to external recipients on its own.
Messages are delivered to the new mail system if the recipient is not in the local mail system. If routing rules are used, the message is forwarded to another domain.
Rules apply for external incoming messages.
In this article, I have tried to fully and thoroughly cover the issue of the coexistence of two mail systems, while not being tied to their closed technologies and features. I hope it was interesting and useful.
Thanks to those who read the article to the end.
I would like to talk about another option for sharing mail systems, thanks to which you can achieve a smooth migration of users and smooth out possible problems.
For further description, I will use specific mail systems, but I will try to maintain the applicability of this description for other systems. I will use Microsoft Exchange 2013 as the old mail system, and Google Apps for Business will act as the new mail system. Outside of this article is the process of migrating user data, since it is very dependent on the current and future mail systems.
I would like to highlight 2 key stages of coexistence. The main purpose of the first stage is to check whether the functionality of the new mail system suits you. During the second stage, the main user migration occurs.
First stage of coexistence
The main goal of this stage is to check the capabilities of the new mail system and eliminate all problems found. The main users at this stage are system administrators, whose mail is automatically delivered to both mail systems.
Such delivery is implemented using an additional domain and message routing rules. The MX of the primary domain, in our case, let it be example.com , points to the old mail system. The MX of the additional domain gtest.example.com points to the Google server. Instead of the additional domain, you can use the test domain provided by Google example.com.test-google-a.com , to maintain the universality of the method, I will use the additional domain.
Configure dual delivery
Local mail server
On the old mail system, you need to configure forwarding a copy of messages to another domain. For a small number of users, this is easiest to do with transport rules with the addition of a hidden recipient (BCC).
- add transport rule New-TransportRule -Name user -SentTo user@example.com -BlindCopyTo user@gtest.example.com
Google apps
To optimize the operation of anti-spam on Google servers, you need to specify the old mail server as an incoming mail gateway, since a large number of incoming messages is possible from this server.
- log in to the Google Admin console
- click Google Apps> Gmail> Advanced Settings
- in the Incoming gateway field , enter the IP address of the incoming gateway server
Additional settings
- most likely you use SPF so that mail sent from Google Apps is not considered spam, you need to add include: _spf.google.com , the final entry may look like this v = spf1 include: _spf.google.com + mx ~ all
- most likely you will need to add an exception to the anti-spam system so that letters sent from Google Apps are not filtered by the local mail system
Description of message flows:
External Inbox
Messages are delivered via the main MX record to the old mail system. If you need to deliver a copy of the message to Google Apps, the transport rule adds BCC in the secondary domain.
External outgoing emails
Each system can independently send messages to external recipients. If necessary, Google can use the old mail system as a mail gateway. This may be necessary if, before sending messages to external recipients, additional processing of mail occurs, for example, with the DLP system.
Internal emails sent from the old system
Mail is delivered to the recipient in his local mailbox. If necessary, a copy of the letter is sent to an additional domain.
Internal emails sent from Google Apps
Google delivers messages according to MX records. A message sent from Google Apps will be delivered to the local mail system, and, according to local transport rules, a copy of the message can be sent to Google Apps.
Pros of dual delivery
- Minimal changes are made to the current mail system. You can easily roll back the changes.
Cons of dual delivery
- Not all things can be verified. For example, if the new system comes with anti-spam, then it does not participate in this scheme.
- Emails sent from one system do not appear in messages sent from another system.
Second stage of coexistence
It makes sense to move on to this stage when most of the problems found have been eliminated and there is an understanding that the new system fully meets the requirements put forward.
At the second stage of integration, the optimal method of coexistence is separate delivery. Mail messages are delivered to the system that is basic for a particular user. The primary domain MX points to Google Apps, which receives all incoming mail. If the recipient's primary mail system is the old system, the message is forwarded to the local mail server.
Settings
Local mail server
On the local mail system, you can configure in several ways.
- You can use transport rules to forward messages to an additional domain. You can do this with the command New-TransportRule -name user -SentTo user@example.com -RedirectMessageTo user@gtest.example.com.
- Instead of transport rules, you can use the Internal Relay domain. There is a rather important limitation when using the internal relay domain: the mail addresses of the moved users must not be available in the old system. To do this, they can be deleted or renamed. You can change the domain type with the command Set-AcceptedDomain example.com -DomainType InternalRelay.
Google apps
You need to add a host to forward messages to it.
- log in to the Google Admin console
- Click Google Apps> Gmail> Hosts
- Click Add Route . The Add Route for Mail window opens
- enter the host name (preferred) or the IP address for the route (allowed but not recommended)
- click save
Configure a routing rule.
- click Google Apps> Gmail> Advanced Settings
- select Default Routing
- click Add option
- go to the Specify that envelope recipients must match
- select All recipients from the drop-down list
- go to the section If the envelope recipient matches the above expressions , follow these steps:
- in the drop-down list, select Change message
- check the Change route box . Select a local mail server from the drop-down list (for example, Exchange On-Premise)
- in the settings section, click Perform this operation only with unrecognized addresses
- click save
Description of message flows
External Inbox
All incoming messages are delivered to Google Apps. If the recipient is in Google Apps, the message is delivered to his inbox. If the recipient does not exist, the message is forwarded to the local mail system, which delivers it to the local mailbox.
External outgoing emails
Each system is capable of sending messages to external recipients on its own.
Internal emails sent from the old system
Messages are delivered to the new mail system if the recipient is not in the local mail system. If routing rules are used, the message is forwarded to another domain.
Internal emails sent from Google Apps
Rules apply for external incoming messages.
Pluses of separate delivery:
- The load on the old mail system is reduced.
Cons of separate delivery:
- Often mail systems come with additional functionality, the use of which can be difficult. For example, calendars.
In this article, I have tried to fully and thoroughly cover the issue of the coexistence of two mail systems, while not being tied to their closed technologies and features. I hope it was interesting and useful.
Thanks to those who read the article to the end.