Saturday, May 31, 2014

Exchange 2013 (SP1) - Migration - Part 9 - Mailbox moves

Now we can move our mailboxes.

There are a number of options: EAC (Exchange Admin Center - GUI), EMS (Powershell cmdlets) and CSV file (with names of mailboxes to be migrated).

I'll illustrate the EAC and EMS options in the paragraphs that follow.


EAC

We manage the mailbox move from the Exchange 2013 server, EX13-1 in my case. We open the EAC and go to the "recipients" section, and then to the "migration" tab:



In the section below, we click on the plus sign "+" and select the "Move to a different database" option:


We then select the users to move:



Note: if we want to use a list in CSV format, we can navigate to the location of the file further down (not shown in the screenshot above).

We click on the plus sign (previous screenshot) to display the list of users:



Once highlighted, we can add the users we want with the "Add" button at the bottom of the list:


We'll then have something like this:


We then click "OK", then "Next", and proceed to the following screen:


We provide a name for the migration process, "Mailbox Move 1" in my case, and select either the primary mailbox, the archive mailbox, or both, and then the target database (and click "Next").

At this point, we have to designate a recipient for the report that will be sent. We can start the "batch" automatically (my choice) or manually later:


The status of the migration is summarized in the resulting page:



If we refresh the page a moment later, we should see the number 2 in the "Finalized" column (that was the case for me).


EMS

The PowerShell cmdlet for a mailbox move is quite concise. This is all we need:

New-MoveRequest john.smith@mitserv.net -TargetDatabase EXDB-2

So, besides the New-MoveRequest cmdlet itself, we indicate the mailbox to be moved (designated here by the email address) and then the target database. We could place the "-identity" parameter just before the mailbox name but since it is "positional", this is not necessary.


Mailbox access after the move

Logging on as one of the users whose mailbox was moved, I was able to access the mailbox via OWA (Outlook Web App) without a problem...




On the other hand, access via Outlook (now the equivalent of Outlook Anywhere) was unsuccessful for one user.

I am prompted for credentials and informed that I need to restart Outlook:



Unfortunately, restarting Outlook changes nothing: I am still prompted for credentials and even after entering the same password that works with OWA, I cannot connect to Exchange.

In fact, Outlook does open but does not connect to Exchange. So I can see mail received before the migration but cannot interact with Exchange. If I hold down the Ctrl key and right-click on the Outlook icon (in task bar), the "Connection Status" indicates that Outlook is still trying to connect to EX1, the Exchange 2007 server (even though the mailbox has been moved):




I can open and close Outlook, and even restart the entire computer, but autodiscover seems unable to change the Exchange server it targets.

This only affected one migrated user.

I enabled some test mailboxes on the new Exchange 2013 server and these are accessible via Outlook and OWA.

Also, four other migrated users did not encounter the problem.

Furthermore, if I delete the entire profile (and therefore the Outlook profile) of the one migrated user on the Windows 7 client, they can access their mailbox via Outlook once again (in other words, once a new profile is created). This would also, presumably, be the case of a user that had never logged on to the client machine before the mailbox migration.

***

In conclusion, I was able to migrate the mailboxes from the Exchange 2007 server to the Exchange 2013 server. However, something, apparently in the Outlook profile, prevented one migrated user from accessing their mailbox via Outlook (unlike OWA which presented no problems).

I could not reproduce the problem with other users: four of them were able to access their mailbox without difficulty (although reopening Outlook was necessary - which is normal and expected).

Since I could not reproduce the problem, I am not sure if simply recreating the Outlook profile (rather than the entire user profile) would have resolved the problem.



No comments:

Post a Comment