In the last part of the article series "Migration from Exchange 2016 to Exchange 2019", the uninstallation of Exchange 2016 is prepared and the migration completed.
The small Troubleshooting section is dedicated to the most common cause of failed or stopped MoveRequests. Problems can always occur during migrations that could not be ruled out beforehand. The causes can be manifold, so I cannot go into all eventualities here.
Troubleshooting
Before Exchange 2016 can be uninstalled, all mailboxes must be moved from the Exchange 2016 database to the Exchange 2019 database. In part 3 of this article series, MoveRequests were used for this purpose.
However, it often happens that some MoveRequests have the status "Suspended" or "Failed" and therefore the mailbox is not moved.
The status of the MoveRequests can be checked with the following command:
Get-MoveRequest
In most cases, the MoveRequests are not completed because there are defective elements within the mailboxes. Here it usually helps to raise the corresponding limit of tolerable errors. With the following command, 50 faulty elements can be permitted for existing MoveRequests:
Get-MoveRequest | Set-MoveRequest -BadItemLimit 50
The MoveRequests can then be continued:
Get-MoveRequest | Resume-MoveRequest
As already mentioned, there may also be other causes for incorrect move requests. The following command provides further information for troubleshooting:
Get-MoveRequest | Get-MoveRequestStatistics | fl
There is also another article here that can help failed MoveRequests:
As already mentioned at the beginning, there are many causes for failed MoveRequests. You are welcome to leave further causes and solutions as comments. If there are enough tips, I will be happy to include them as a separate article.
Once all MoveRequests have been successfully completed and have the status "Completed", the MoveRequests can be deleted:
Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest
To ensure that no problems occur during uninstallation, a little tidying up should be done.
Preparing to clean up and uninstall
To ensure that the uninstallation of Exchange 2016 runs as smoothly as possible, a few clean-up tasks should be carried out before the uninstallation.
While I was tidying up, for example, I noticed that I had forgotten to move the AuditLog mailbox. I didn't do this in part 3, so I'll do it now. Here are the already known commands for displaying and moving:
get-mailbox -Database DB2016 -AuditLog
get-mailbox -Database DB2016 -AuditLog | New-MoveRequest -TargetDatabase DB2019
Get-MoveRequest
Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest
Now that the AuditLog mailbox has also been moved, there should no longer be any mailboxes stored in the old Exchange 2016 database. The common mailbox types can be queried with the following commands:
get-mailbox -Database DB2016 get-mailbox -Database DB2016 -Arbitration get-mailbox -Database DB2016 -Archive get-mailbox -Database DB2016 -PublicFolder get-mailbox -Database DB2016 -AuditLog
There should now also be no more MoveRequests. If there are still MoveRequests at this point, these must first be completed and deleted (see Troubleshooting section). The following command can be used to check whether MoveRequests still exist:
Get-MoveRequest
If there are no more mailboxes in the Exchange 2016 database and no more MoveRequests are displayed, the Exchange 2016 server can be removed from the scope definition of the Send Connector:
There should now be no problems during uninstallation.
Uninstallation
Exchange 2016 can be uninstalled from the Control Panel via "Programs and Features":
Note: Before Exchange 2016 is uninstalled, any existing AntiVirus/AntiSPAM software for Exchange should be uninstalled. These programs often prevent Exchange from being uninstalled successfully.
After clicking on "Next", the uninstallation routine checks once again whether the uninstallation can be carried out:
In this case, everything is OK and the uninstallation can be started:
Uninstalling takes a few minutes:
Exchange 2016 has been successfully uninstalled and a final restart is requested:
This completes the migration to Exchange 2019. There are two further optional steps that can now be carried out.
Optional: Remove server from domain
If the Exchange 2016 server is no longer running any other services, the server can now be removed from AD and shut down. The Windows installation should no longer be used for other services. The computer account of the old Exchange 2016 server should also be deleted (if it still exists).
Note: The deinstallation routine does not remove the old database files and logs, so if the operating system of the old Exchange Server is still in operation (possibly due to other services), the database and logs should be deleted manually:
If the server hardware is to continue to be used, a clean reinstallation of the operating system is recommended.
Optional: Client Access Rules (Restrict Exchange Admin Center)
The "Client Access Rules" are a new Exchange 2019 feature that can be used to restrict access to the Exchange Admin Center (EAC), among other things.
In the test environment described here, there is a NAT entry which forwards port 443 to the Exchange 2019 server:
This NAT entry publishes Exchange 2019 on the Internet, meaning that protocols such as ActiveSync and MAPIoverHTTP can be used from the Internet. At the same time, it also makes the Exchange Admin Center (EAC) accessible from the Internet. Administrative interfaces such as EAC, which are directly accessible on the Internet, always represent a potential security risk. Especially if, as in this test environment, no web application firewall or other protective measures are used.
To ensure that administrative interfaces such as the EAC cannot be accessed directly from the Internet, access can be restricted, for example to the internal network or a dedicated management network.
For example, the following commands can be used to restrict access to the RemotePowerShell and EAC to the internal network 192.168.200.0/24:
New-ClientAccessRule -Name "Block Remote PowerShell" -Action DenyAccess -AnyOfProtocols RemotePowerShell -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24 New-ClientAccessRule -Name "Block Remote ExchangeAdminCenter" -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24
Access to EAC and PowerShell from computers outside the 192.168.200.0/24 subnet is therefore no longer possible. Of course, care must be taken here so that you do not lock yourself out.
A detailed article on the Client Access Rules will follow.