Migration and Coexistence of Mail Systems

Periodically, there is the problem of migration from one mail system to another. Due to the fact that often these systems do not have the regular functionality of coexistence, their sharing may not be the easiest task. Switching from one system to another might look like this - starting on Friday evening, the system administrator configures servers, reconfigures users' mail clients and transfers user data. Despite his efforts, Monday can be a very “fun” day: either not all data was transferred, or some old system could not send messages.
I would like to tell you about another way of sharing mail systems, thanks to which you can achieve a smooth migration of users and smooth out possible problems.
For the further description I will use specific mail systems, but I will try to preserve the applicability of this description for other systems. I’ll use Microsoft Exchange 2013 as my old mail system, and Google Apps for Business will be my new mail system. Beyond the scope of this article is the process of migration of user data, as it is very dependent on 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 migration of users occurs.

The first stage of coexistence

The main purpose of this stage is to check the capabilities of the new mail system and eliminate all the 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 main domain, in our case let it be example.com , points to the old mail system. MX additional domain gtest.example.com points to a Google server. Instead of an additional domain, you can use the test domain provided by Google, example.com.test-google-a.com , to preserve the versatility of the method, I will use an 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, it’s easiest to make transport rules with the addition of a hidden recipient (BCC).

1. add transport rule New-TransportRule -Name user -SentTo user@example.com -BlindCopyTo user@gtest.example.com

Google apps

To optimize antispam performance on Google servers, you need to specify the old mail server as an incoming mail gateway, since a large number of incoming messages are possible from this server.

1. log in to the google admin console
2. Click Google Apps> Gmail> Advanced Settings.
3. in the Incoming Gateway field, enter the IP address of the incoming gateway server

Additional settings

1. you probably use SPF so that mail sent from Google Apps is not considered spam, you need to add include: _spf.google.com , the final entry might look like this v = spf1 include: _spf.google.com + mx ~ all
2. most likely you will need to add an exception to the antispam system so that emails sent from Google Apps are not filtered by the local mail system

Description of message flows:

External incoming letters

Messages are delivered via the main MX record to the old mail system. If you need to deliver a copy of a message to Google Apps, the transport rule adds BCC in the additional domain.

External outgoing letters

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 mail processing takes place, for example, by the DLP system.

Internal emails sent from the old system

Mail is delivered to the recipient in its 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 letter can be sent to Google Apps.

Pluses of double delivery

• Minor changes are made to the current mail system. You can easily roll back the changes.

Cons double delivery

• Not all things can be checked. For example, if a new system comes with anti-spam, then it does not participate in this scheme.
• Emails sent from one system do not appear in sent ones from another system.

The second stage of coexistence

It makes sense to move to this stage when most of the problems found have been eliminated and it is understood that the new system fully meets the requirements.
At the second stage of integration, the optimal method of coexistence is separate delivery. Mail messages are delivered to the system that is essential for a particular user. The primary domain MX points to Google Apps, which receives all incoming mail. If the recipient’s main mail system is an old system, the message is forwarded to the local mail server.
')

Settings

Local Mail Server

On the local mail system, configuration can be done in several ways.

• You can use transport rules to forward messages to an additional domain. You can do this with the following 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 (Internal Relay). There is a rather important limitation when using the internal relay domain: the email addresses of the displaced users should 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.

1. log in to the google admin console
2. click Google Apps> Gmail> Hosts
3. Click Add Route . The Add route for mail window opens .
4. enter the host name (preferred) or IP address for the route (allowed, but not recommended)
5. click save

Configure the routing rule.

1. Click Google Apps> Gmail> Advanced Settings.
2. select Default Routing
3. click Add Parameter
4. Go to the section Specify that the envelope recipients must match
5. in the drop-down list, select All Recipients
6. skip to section If the envelope recipient matches the above expressions , follow these steps:
7. in the drop-down list select Edit Message
8. check the box Change route . From the drop-down list, select a local mail server (for example, Exchange On-Provise)
9. in the section with parameters, click Perform this operation only with unrecognized addresses
10. click save

Message flow description

External incoming letters

All incoming messages are delivered to Google Apps. If the recipient is in Google Apps, then 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 letters

Each system is able to send messages to external recipients independently.

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 redirected to another domain.

Internal emails sent from Google Apps

There are rules for external incoming messages.

Pluses of separate delivery:

• Reduces the load on the old mail system.

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 tried to fully and thoroughly address 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.