Sunday, December 9, 2018

Exchange 2010 > 2016 migration - Part 8 (uninstall Exchange 2010)

In this blog post, I will remove an Exchange 2010 server from a DAG (Database Availability Group) and then uninstall Exchange from the server. The server being removed is EX13-2. In many examples, you will see the roles being moved to server EX13-1.

DAG operations

We can use either the EMC or the EMS. I will use the latter option.

First, we have to ensure that the server being removed does not hold the active copy of the databases and is not the PAM (Primary Active Manager) of the DAG. In my case, this is server EX13-2. We can verify that with the following command:

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus

Note: the command Get-MailboxDatabase alone does not show passive copies. The active copy of the database is the "mounted" copy and the passive copy is the "healthy" copy (if everything is normal).

Note: you can click on the images to enlarge.

We can view the PAM with this command:

Get-DatabaseAvailabilityGroup -status | format-list *primary*

Note: the command is abbreviated in the screenshot.

If necessary, we can move the active copy of the mailbox database with this command:

Move-ActiveMailboxDatabase DB01 -ActivateOnServer EX1

Note: DB01 and EX1 are simple examples.

As for the PAM, we can place the server in DAG maintenance mode to move the role to another server (and remove it from maintenance mode immediately thereafter if needed).

There are other methods that vary depending on the OS version. With Server 2012 and later, we can use a PowerShell cmdlet, for example:

Move-ClusterGroup "Cluster Group" -Node EX13-1

This command does not work with 2008/R2. For this OS, I was able to use the following command instead:

cluster dag1.mynet.lan group "Cluster Group" /moveto:EX13-2

We should also make sure that the server that will host the active copy of the mailbox is not in maintenance mode (although we would know soon enough from the inevitable error message if it was):

The status for the activation policy should be "unrestricted" rather than "blocked". In addition, the command below should show that no servers are in maintenance mode:

After these verifications, we can remove the server from the DAG.

Step 1: remove the mailbox database copy from the DAG

We remove the copy of the mailbox database with this command:

Remove-MailboxDatabaseCopy DB1\EX13-2

If we need to identify the name of the mailbox database copy, we must use this cmdlet (already mentioned earlier):

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus

Note: there is not a corresponding "Get-MailboxDatabaseCopy" cmdlet.

Step 2: remove the server from the DAG

Next, we remove the server from the DAG with this command:

Remove-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX13-2

Note: DAG1 is the name of the DAG in my test environment.

Once again, if we want to verify the name of the servers in the DAG, we have to use this command:


There is NOT a Get-DatabaseAvailabilityGroupServer cmdlet (in Exchange 2010).

Note: if the absence of operational servers surprises you, remember that you have to add the -status parameter to see certain details:

Optionally, we can remove EX13-1 from the DAG and then the DAG itself at this time (or wait until later).

Step 3: remove the DAG

First, we have to remove the last server (EX13-1). The command is the same as above...

Remove-DatabaseAvailabilityGroupServer DAG1 -MailboxServer EX13-2

But if you look quickly, there is also a message indicating the cluster has been removed because EX13-1 is the last server of the DAG:

Note: you can click on the images to enlarge.

If we view the properties of the DAG now, we see a DAG with no servers:

We remove the DAG itself with this command:

Remove-DatabaseAvailabilityGroup DAG1

We can confirm the removal of the DAG with the command:


There should be no results (see screenshot directly above).

Other uninstall prerequisites

Source server for Send Connectors

We can remove the server as a source server for the "Send Connectors" with this command:

Set-SendConnector MYNET-SendConn-1 -SourceTransportServers EX13-1

Because of the way the command functions, if we indicate only the server(s) we want to retain, the other (unmentioned) server is automatically eliminated.

We also need to verify that the server is not that one responsible for the generation of the Offline Address Book (OAB). If that is the case, we can move the OAB generation server with this command:

Move-OfflineAddressBook "Default Offline Address Book" -Server EX13-1

Note: since the server hosts no more databases, it logically cannot hold mailboxes and there is no need to move system mailboxes as we might have to do in other scenarios.

Uninstall Exchange

For the uninstall of Exchange itself, we can go to "Programs", select Exchange 2010 and then uncheck all the boxes below, including "Management Tools":

If all goes well, we should obtain these results:


I have concentrated on Exchange. We may also want to remove the server from the domain and disable monitoring of the system by management tools such as SCOM (or PowerAdmin) and any centrally managed antimalware solution. The removal of the server from such consoles exceeds the scope of this blog post.

As for removing the last Exchange 2010 server (EX13-1), we would do what we did above but moving any mailbox databases or other Exchange components to our Exchange 2016 server(s).

Tuesday, December 4, 2018

Exchange 2010 > 2016 migration - Part 7

Now that I've prepared my environment (please see previous blog posts of this series), I'll migrate mailboxes from Exchange 2010 to 2016. In fact, I have only one user mailbox that I had intended to migrate to Exchange Online. I'll use it to demonstrate the Exchange 2010 to 2016 mailbox migration procedure. I also have some system mailboxes to migrate.

We can use either the Exchange Admin Center (GUI) or the Exchange Management Shell (PowerShell command line interface) to migrate mailboxes. I'll demonstrate the use of the EAC for a user mailbox and then the EMS for the system mailboxes.


Mailbox migration with the EAC

We login to the EAC and go to the recipients tab and then select migration. We click on the + sign and select "Move to a different database":

We can use a .CSV file with a list of users or simply select them manually. I'll use this latter option. Once again, I click on a + sign to select the users (a single user in my case)...

And select them in the list before clicking add:

The user (test user Alan Reid) has now been selected. We click on Next to continue:

In the following step, we name what is called the "migration batch", decide if the archive mailbox will be moved with the primary mailbox (if applicable) and then select the target database (click on Browse):

I select and add the target database for the migration:

I did not select an archive database (this was not necessary). I can adjust the "bad item limit". If the number of bad items is exceeded, the migration will fail:

Now we can start the batch, configuring the report setting and then the schedule:

Once we click on new (in the screenshot above), the migration process starts and we can view the status. The duration of the migration can depend on a number of factors (mailbox size, network latency). You may have to click on the refresh icon from time to time:

If we click on view details (screenshot above), more information on the individual mailboxes is provided. Below, the status is "Completed" and we can see the number of items synced:

That's quite a few screenshots. The command line equivalent is much more concise. Here is one variation:

Get-Mailbox Alan.Reid | New-MoveRequest -TargetDatabase DB01

Mailbox migration with the EMS

Moving system mailboxes can be more challenging. First of all, some are not visible in the GUI (EAC). Second, the name can be difficult to type. Concerning the arbitration mailboxes, I proceeded as shown in the screenshots below.

We need to add the parameter -Arbitration to display these mailboxes. I also limited the output to mailboxes on the old Exchange 2010 server (EX13-1) using the where-object cmdlet (abbreviated below as "where"):

Next I pipeline the output to the cmdlet New-MoveRequest with the target database DB01. This avoids having to type the long alpha-numerical names:

Afterwards, I can re-run the first command to verify that no mailboxes remain on the old server (EX13-1).

Of course, we can use the command line to move simple user mailboxes as well. In addition to the example at the end of the previous section, we could do this:

New-MoveRequest Alan.Reid -TargetDatabase DB01

These mailboxes moved very quickly and the migration had already completed when I executed the cmdlet Get-Request. Consequently, I did not examine all the options of this cmdlet but for those interested, you can find more details here: