Migrating emails from Microsoft Exchange Server to Yandex Mail

Friends, hello everyone! In the next article of the series about managing Yandex 360 for business, I will tell you how you can copy mail from the very popular Microsoft Exchange Server mail server to Yandex Mail.

I will provide step-by-step actions that an administrator needs to perform for centralized mail migration without collecting user passwords. I will share answers to the most frequently asked questions about the migration service that you may have. In addition, I will give explanations on using the mail migration tool as a solution for backing up mail from an Exchange server.

This article will be useful for mail infrastructure administrators who are about to migrate emails to the Yandex Mail service. And also for those who are just planning to prepare for such an important process, and for everyone interested in cloud services.

Plan:

1. Stages of migration

2. What should be ready in the Yandex 360 organization for business

3. Preparatory steps on the Microsoft Exchange Server side

4. Checking Migrator's access to mail

5. Preparing a CSV file

6. Performing the migration

7. Frequently asked questions about migration

8. Migration as a mail backup

Stages of migration

Yandex Mail has a migration service, let's call it Migrator. It can connect and retrieve mail from other sources in different ways.

Migrator uses the IMAP protocol to connect to mailboxes in Microsoft Exchange Server. Usually, when cloud services collect mail via the IMAP protocol, they request passwords for all accounts. But this is very inconvenient, and also unsafe. Not every user will agree to share a password. Therefore, Yandex Mail developed Migrator in such a way that it does not require entering user passwords for its operation.

The administrator specifies the name of the Exchange server where the IMAP service is running. Then feeds the Migrator a prepared CSV file with a list of Yandex Mail user logins and mailboxes on the Exchange server. After that, the migration is launched, which works in batch mode. The Migrator creates collectors that initiate client connections via the IMAP protocol from Yandex Mail to each mailbox on the Exchange server.

As a result, all emails are collected into mailboxes and automatically continue to sync until the administrator clicks “Finish migration”.

Collecting data from one mailbox takes from several minutes to several hours. After that, letters from the source mailboxes will start appearing in Yandex Mail mailboxes. The folder structure from the source mailboxes is also copied to the target mailboxes.

Migration stages in the administrator's office and details

Checking for errors

After the migration has started and the user list has been loaded, the data loaded is checked for correctness. The CSV file is checked for syntax: it is important that nothing unexpected is found in it. All internal users must exist, and email addresses must not contain errors.

If something goes wrong during the check, the details will say error with the reason. If everything goes well, then preparation for migration will begin.

Preparing for migration

A step-by-step connection in batch mode to all mailboxes in the CSV list is in progress. It occurs under an account with rights to mailboxes. The folder structure and lists of items in the boxes are unloaded.

Initial synchronization

As soon as one of the mailboxes has a list of letters and folder structures ready, the main process of copying letters starts. This is the longest of all migration stages. In detail, it will be called initial_sync.

Synchronization of new messages

After the initial synchronization of the mailbox contents is completed, nothing stops. With a certain frequency, additional synchronization of new letters that arrived in the mailbox on the Exchange server side begins. This happens individually for each mailbox in the background. In the details, this stage of migration will be displayed as Sync_newest.

Stopping migration

When the administrator clicks the “Finish Migration” button, the migration is completely stopped. It can only be restarted from the beginning. The status will be stopping or stopped.

During the migration, 0 will be displayed opposite the corresponding stage. If you see 0 at the “Migration” stage, it means that the migration of old letters from the mailboxes is complete. If you want to migrate only old letters and not collect new ones, you can manually complete the migration at this stage by clicking the “Stop” button.

What should be ready in the Yandex 360 organization for business

To start migration to Yandex 360 for Business, you need to take the following steps:

1. Create a Yandex 360 organization for business.

2. Add at least one primary domain to this organization. In our case, it will be example.com. Read how to do this in the first article of the series.

3. Create user accounts in the Yandex 360 organization. This needs to be done because the migration tool does not automatically create users. If you are migrating from Microsoft Exchange Server, you have an deployed Active Directory forest and will most likely synchronize users from this forest. Read how to do this in the second article of the series.

Preparatory steps on the Microsoft Exchange Server side

To perform migration via IMAP protocol without collecting user passwords, you need to configure IMAP on the Microsoft Exchange Server side, create an account and grant it full access rights to the contents of the transferred mailboxes. Below are the step-by-step actions.

1. You need to make sure that the IMAP service is running on the server that you will specify in the migration wizard on the Yandex 360 side. To configure this correctly, you should refer to the Microsoft Exchange documentation: Enable and configure IMAP4 on an Exchange server | Microsoft Learn.

At a minimum, the following services should be started in automatic mode:

Set-Service MSExchangeIMAP4 -StartupType Automatic
Set-Service MSExchangeIMAP4BE -StartupType Automatic

2. Publish the IMAP service on ports 993/IMAPS or 143/IMAP. This must be done at least for the Migrator IP addresses:

5.45.234.240/28
5.255.219.176/28
5.45.248.32/28
141.8.128.192/28
93.158.165.192/27
37.9.118.96/27
77.88.30.0/27
93.158.141.128/27

3. Companies usually disable the ability to connect to client protocols such as POP3/IMAP/SMTP for users. Therefore, it is necessary to check the status and allow the use of the IMAP service.

   Command to check IMAP status on a user:

   Get-CASMailbox -Identity "John Smith" | ft IMAPEnabled

   Command to enable IMAP access for a user:
   Set-CASMailbox -Identity "John Smith" -IMAPEnabled $true

4. Create a separate account with a mailbox. For example, let's call it migrator@example.com. It should just be an account with a mailbox without administrator rights. You should not tempt fate and give this account Exchange Organization Administrator rights or other roles.

5. Grant Full Mailbox Access rights — full access to the contents of the mailboxes you plan to migrate. It is the full rights to the mailboxes, and not the administrator role, that will allow the Migrator to access the contents of the mailboxes of the required users from his account.

Add-MailboxPermission -User <migration@example.com> -AccessRights Fullaccess -InheritanceType all -AutoMapping $false

You can grant full rights to the contents of all mailboxes using the following cmdlet:
get-mailbox -ResultSize unlimited | Add-MailboxPermission -User <migration@example.com> -AccessRights Fullaccess -InheritanceType all -AutoMapping $false

Now everything is done on the Exchange Server side.

How to check that the Migrator will be able to access the mail, or the most interesting place

Now we will try to connect to the user mailbox user, using the account and password of the user migrator via the IMAP protocol. To do this, you need to configure the mail client via the IMAP protocol. Since we are talking about Microsoft, Outlook will help us.

You need to set up a profile in Outlook as shown in the screenshot below.

I draw your attention to the “User” field. The data must be specified exactly as follows: example.com/migrator_account/user. What are these attributes:

• example.com is the domain under which Exchange Server authorizes the user;

• migrator_account — username of the account under which the Migrator will work;

• user — the Alias ​​or Mailnickname attribute of the source (migrated) mailbox of the Microsoft Exchange Server employee.

In the “Password” field, you must specify the password for the migration@example.com account.

Next, you need to specify the SMTP parameters according to how your SMTP service is configured. This is only necessary to configure the profile. For IMAP, this does not matter at all, but the profile will not be configured in Outlook without this.

If Outlook connected to the mailbox of the user specified in the user field, and you saw a list of folders, everything is successful. Yandex Mail Migrator emulates exactly the same connection. You can move on.

In the next article I will describe in more detail what happens under the hood of this mechanism on the Exchange server side. The information in the article will help to troubleshoot if suddenly something does not work.

Preparing a CSV file

Now that you have configured the Exchange server and tested the connection, all that remains is to create the CSV file.

A sample is given below:

"yandex_login";"external_email";"external_password"
"user1";"example.com/migration/user1";"Password"
"user2";"example.com/migration/user2";"Password"
"user3";"example.com/migration/user3";"Password"

The file structure must be saved in UTF-8 encoding. The first line and the heading names are not touched.

• In the first column, specify the username of your organization in Yandex 360 for Business. Important: specify without the domain.

• In the second column, we specify a special construction example.com/migration/user1, which will allow you to connect to the user1 mailbox on behalf of the Migrator account. For more information, see the section “Checking the Migrator's access to mail”.

• We write the password of the Migrator account. Yes, it must be duplicated in each line.

Performing the migration

We have completed all the preparatory steps, all that remains is to launch the migration wizard.

1. Let's move on to Yandex 360 management portal for business.

2. Find the “Migrations” section in the general settings.

3. We indicate what we want to transfer – letters.

4. Click “+New migration”.

5. At the “Prepare accounts” stage, confirm that the accounts have already been created and click “Done” → “Next”.

6. At the “Select where you want to migrate emails from” stage, select “Other server”.

7. Specify the name of your Exchange server on which the IMAP service is configured. Specify port 143 or 993 and check the SSL box.

8. Upload the CSV file with the list of user email addresses that we made in the previous section. Click “Next”.

I recommend specifying a small number of users the first time to check if everything is ok with the syntax and secret.

9. Finally, all that remains is to click “Start migration”.

10. We watch the numbers and, if necessary, download the details. If something goes wrong, we read the cause of the error in the details and fix it. If it doesn't work, we start a request to technical support.

11. Once everything has successfully launched with a small test set of users, it's time to click “+New Migration”. We throw in a new large CSV file to launch everyone at once.

If you have more than 20,000 employees in your company, keep in mind that you will have to prepare several files for every 20,000 lines (aka users).

12. When all the letters migrate and the hour X comes, it remains to switch MX from Exchange Online Protection to Yandex 360. Click the “Stop migration” button – this leads to the Migrator being disabled.

Frequently asked questions about migration

In my previous article about migration from Exchange Online I answered the most pressing questions – they fully apply to migration from Microsoft Exchange Server.

Let me add some clarifying points:

Only letters are transferred. Contacts, calendar events, etc. are not transferred this way.

As you know, Exchange has a special structure for storing calendar events: they are stored directly in users' mailboxes. You can create different folders in a mailbox and specify the type of objects stored in them: letters, calendars, contacts, tasks, etc.

The IMAP protocol is far from calendar events, you can’t receive and/or transmit information about meetings via it. However, when an IMAP client “knocks” on the Exchange Server via the IMAP protocol and requests the entire list of folders, then Exchange without a shred of embarrassment gives the client folders of all types, and not just those in which the type “for letters” is specified.

As a result, some IMAP client, such as Thunderbird or Yandex Mail Migrator, sees all folders and tries to synchronize them all. But if in the specified Thunderbird the user can exclude folders from synchronization, then in Migrator it is not yet possible to set such exceptions.

As a result, calendar events move around as artifacts.

No, Migrator does not delete messages. Migrator does not have delete commands at all.

In addition, it is important to remember the following nuances:

• If your Inbox contains invitation emails with a calendar event in ics format that is scheduled to happen in the future, then standard processing will be performed when importing such an email. This will result in the creation of a calendar event from such an email.

Let me emphasize once again that calendar events do not move. But when invitation letters from ics are moved, meetings are created based on them.

• Letters larger than 35 MB cannot be transferred.

• Messages from the additional Exchange Online Archiving archive box are not transferred. The reason is simple: Exchange Server does not provide access to the archive box via the IMAP protocol. If you need to transfer such messages, I recommend moving them from the archive box to the primary one in advance.

• Letters have two important dates: when received and sent. After migration, letters are placed in a mailbox using the internal transport service. As a result, the sending date remains the same as it was at the time of sending the letter, but the receiving date changes to the date when the Migrator, or rather the transport service, placed (aka delivered) the letter in the mailbox.

By the way, I would like to point out one thing for Outlook users: if you select the “Created” date, it will be the letter synchronization date in the client. Let's not forget that in the sweet couple Exchange/Outlook, the creation date of the “letter” class object is synchronized via its proprietary MAPI protocol. IPM.Note is the date the letter appeared in the Exchange Server, and it is the date that is visible in the Outlook client. But when the IMAP protocol is used, the letter creation date in Outlook is already imap savedate, or the date when the Outlook client created a local copy of the “letter” class object.

Mail Migration as a Backup Tool

Sometimes Yandex360 for Business customers use Disk, Telemost, Messenger and other digital environment products, except Mail and Calendar. They prefer to save mail for some or all employees on a local Exchange Server. In this case, you can use the steps described in this article to set up mail backup.

The administrator sets up synchronization. Users do not notice anything: they continue to work in Outlook with a mailbox in Exchange Server. And the administrator and the business receive virtually duplicate mail in the Yandex Mail infrastructure. At the same time:

• mail is sorted by user;

• users have saved the structure of their email folders. Important: this is not some kind of backup that needs to be restored;

• mail is relevant at the time of the last background synchronization. Let me remind you that after full synchronization, Migrator automatically synchronizes new letters. The maximum delta is a couple of hours.

This approach has only one peculiarity. The purpose of Migrator is to simplify and implement the transfer of letters. So it is still not a backup tool and it will not be possible to use it for a long time.

In addition, it should be taken into account that Migrator does not have delete commands. It does not apply them either to the source or to the recipient's mailbox. If the user deletes a letter in their mailbox in Exchange Server, then this letter will continue to lie in Yandex Mail. The longer the synchronization and the more often the user deletes letters in the source mailbox, the greater the difference between the mailboxes in Yandex Mail and Exchange Server.

Conclusion

Dear readers, in this article I shared the details of migration from Microsoft Exchange Server to Yandex Mail. You learned how it works, what it can and cannot do. I showed how to use the migration script for backup. I will be glad to receive feedback and questions about migration, I or my colleagues will definitely answer them.

Personally, I have long believed in cloud services: as you can see from the step-by-step instructions above, starting to use Yandex Mail instead of Exchange Server is not as difficult as it seems.

In the next article I will talk about the details of the domain/migrator/user1 design and why Microsoft Exchange Server allows you to retrieve mail in this way.