Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 19)

By /

If you would like to read the other parts in this article series please go to:

Decommissioning Exchange 2010

As part of the decommissioning process so far we’ve ensured the server is not in use by users nor devices on the network and switched the server off for a short period of time. After switching back on, we’ve began the removal process by deleting the legacy Offline Address book. We’ll continue with the decommissioning process by removing databases and then uninstalling the staging server.

Removing Databases

We only have one type of Database we need to remove from our Exchange 2010 staging server – Mailbox Databases. After removal though we will need to rename the Exchange 2013 databases to their final name.

Before we press ahead and remove the databases, we’ll need to double check that all mailboxes have been moved to Exchange 2013. To verify all mailboxes have been removed from our Exchange 2010 staging server, we’ll use the following command:

Get-Mailbox -Server <ServerName>

Image
Figure 1: Verification that no Mailboxes exist on Exchange 2010

After verifying that no mailboxes exist on the server, we’re ready to remove the databases. As part of this process Exchange 2010 will double check that no mailboxes exist – it’s not going to let us remove databases that still contain mailboxes.

We’ll use the following PowerShell command from our Exchange 2010 Server to first get a list of the databases:

Get-MailboxDatabase –Server <ServerName>

After confirming that the command is showing the correct databases, remove the Mailbox Databases using the following command;

Get-MailboxDatabase –Server <ServerName>   | Remove-MailboxDatabase

Image
Figure 2: Removing Mailbox Databases

Rename Exchange 2013 Databases

As part of the setup process for Exchange 2013 we used temporary names for our Exchange 2013 databases as we’re using the same convention for both Exchange 2010 and 2013.

As a quick reminder, our databases can be viewed in the Server section of the Exchange Admin Center, within the Databases tab. The list will now show only Exchange 2013 databases, which we intentionally prefixed with _E15:

Image
Figure 3: Exchange 2013 Databases in the Exchange Admin Center showing a temp prefix

As the underlying database paths are correct, the change is simple to perform using the Exchange Admin Center and doesn’t affect users; simply select the Edit button (pencil) from the toolbar and on the General tab, edit the Name field, then press OK:

Image
Figure 4: Updating the Database name

Alternatively this can be performed quickly and safely using the Exchange Management Shell. From the EMS on the Exchange 2013 server we can use a combination of the Get-MailboxDatabase and Set-MailboxDatabase cmdlets to retrieve the database, then change the name it currently has associated with it:

Get-MailboxDatabase <Database_E15>   | Set-MailboxDatabase   -Name <Database>

Image
Figure 5: Updating Exchange 2013 DB names en-mass

As we see in the example above it is quick and effective to change the DB names this way, so if you have a larger number of databases in your environment this may save time.

Uninstalling the Exchange 2010 staging server

With Mailbox Database configuration removed we can now uninstall Exchange Server 2010. To do this, navigate to Programs and Features, within the Control Panel and choose Uninstall after selecting Microsoft Exchange Server 2010 from the list of installed applications:

Image
Figure 6: Locating and uninstalling Exchange 2010

The Exchange Setup application is used for the uninstallation process, much like it was used for the original installation. When prompted, we’ll therefore unselect each Exchange Role installed, including Client Access, Hub Transport and Mailbox. Additionally we’ll choose to uninstall the Management Tools – which includes the Exchange Management Console and Exchange Management Shell:

Image
Figure 7: Uninstalling Exchange 2010 components

After choosing Next, Exchange Server Setup will perform checks to ensure that we’re actually ready to uninstall. After moving Send Connectors earlier in this series and performing the tasks in this article, we’ll expect each readiness test to complete successfully, allowing us to choose Uninstall:

Image
Figure 8: Verification Exchange 2010 is ready to uninstall

After choosing Uninstall we’ll expect the setup program to continue with removal of Exchange 2010. After it completes successfully we’ll be done from an Exchange Server point of view and can if required remove the Windows Server from the domain safely.

Ongoing Maintenance of Exchange 2013

Now you’ve completed your upgrade to Exchange 2013 you should find that the ongoing maintenance required is at least as little, if not less, than Exchange 2010. Reliability improvements mean that most failures will be picked up by the managed availability service and automatically corrected for you.

Checking for notifications

Don’t forget to regularly login to the Exchange Admin Center. As well as perform actions against your server, you’ll also find notifications waiting for you within the Alerts section shown below:

Image
Figure 9: Monitoring alerts in the EAC

If you prefer to administer Exchange using PowerShell, you’ll also find these same notifications available by using the Get-Notification command.

Checking Health

A summary of the current health status of the server can be obtained using the Exchange Management Shell. This information is based on Managed Availability Health Sets which use a variety of probes to check the status of various system components.

To view all areas that aren’t healthy, use the following command:

Get-HealthReport -Identity <ServerName>   | Where {$_.AlertValue   -ne “Healthy”}

In the example output below, there are issues with Transport and OWA:

Image
Figure 10: Viewing the Exchange Health Report

Reviewing Event Logs

Regularly review the Event Logs of the Exchange 2013 server to look for any critical errors.

You’ll find useful information in the System and Application logs, but don’t discount the Exchange-specific logs, found within Applications and Services>Microsoft>Exchange.

Within this folder you’ll find the ActiveMonitoring event logs providing a history of Probe Results, generated by Managed Availability. This can provide insight into what’s happening on your Exchange Server and if you have problems, provide a history of what led up to an issue:

Image
Figure 11: Reviewing Exchange event logs

Monitoring Disk Space

We performed extensive work to understand the sizing requirements for our environment before we implemented Exchange 2013, however this doesn’t mean you can discount regular checks of free disk space. For example if we designed our Exchange environment to cope with 7 days without backups, then as day 8 passes we would without successful backups expect the drives housing our Log files to fill up – a disastrous situation. Monitor both the current usage and trending growth over time of both your system drives, and your Exchange data drives.

Checking Backups

If your design includes a traditional backup solution, and is a small implementation like the one we’ve built within this series then ensuring backups are successful is critically important. Not only should you ensure your backups complete successfully, but you should also ensure that you perform regular test restores.

Applying Patches

It’s especially common with smaller environments for the Exchange environment to fall behind on regular patching. Ensure you understand the release cadence of Cumulative Updates and Service Packs, detailed on the Exchange Team Blog. Pay particular attention to the support period for each CU – you’ll have three months to update to the latest update after it’s released, so plan to patch at least once every six months.

Summary

In this series we’ve migrated from Exchange 2003 to Exchange 2013. As Exchange 2003 is so old, we’ve had to migrate via an Exchange 2010 staging server along the way. Although this is a complicated two-hop process we’ve simplified it as much as possible by removing unnecessary servers and keeping the configuration on Exchange 2010 and 2013 very similar.

If you would like to read the other parts in this article series please go to:

About The Author

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top