Dear Microsoft Exchange 2010, you have given us, admins, a lot of joy. But your end is drawing nearer and fast. The end of Extended Support, also known as End of Life, was planned for January 14, 2020, along with Windows Server 2008 and Windows 7. However, because of all the love for the good old 2010 version and the fact that it’s still like that after still very popular Microsoft is postponing the retirement of Exchange Server 2010. The current date is October 13, 2020. That may seem like a long time. But if you have any experience performing Exchange Server migrations, you probably know that planning and migrating time is going by faster than you might expect…
The following article is a reminder of why we loved Exchange 2010 in its heyday, what “end of life” really means, and what the possible plans are for the future.
A little nostalgia
How was Exchange 2010 different from its predecessors? It brought a few innovative improvements and I’ll try to highlight the most relevant ones.
Exchange Management Shell
In theory, PowerShell was first introduced in Exchange Server 2007. However, with the release of Exchange 2010, a dedicated Exchange Management Shell was provided. Additionally, Exchange 2010 was where RBAC and PowerShell joined forces. From this point on, users without the appropriate permissions will no longer be able to see some cmdlets – they will no longer be downloaded to their PowerShell console. Since then, most answers to problems on technical forums start with “it’s probably a permissions issue”.
With the release of Exchange 2010, which will soon be gone, PowerShell also got a whole bunch of great new cmdlets, the main ones being:
- Send-MailMessage, mainly used to spoof internal addresses (not so good) and send tons of spam emails via console (even worse). Luckily, it can also be used to configure email notifications for PowerShell scripts (which is great).
- New-MailboxExportRequest and its import related counterpart, used to generate or import PST files. Many admins have used it as an unreliable backup replacement for Exchange (still better than no backup at all).
- Numerous cmdlets related to managing federation trusts, OWA mailbox policies, Exchange Active Sync, and other new features in Exchange 2010.
Outdated public folders
Exchange 2010 was the last to host legacy public folders. Starting with Exchange 2013, each public folder is treated as a sort of mailbox. Before that, public folders had a separate database. While this change was a good thing, migrating from legacy public folders to modern public folders turned out to be a challenge that was best solved using third-party migration tools.
Administrator Audit Logs
The introduction of administrator audit logs in Exchange 2010 made it possible to track who corrupted what and when. Since then, every security-obsessed pro rejoices while every sneaky admin trembles.
The list could go on and on… But who likes long goodbyes?
What does the end of extended support mean?
Every Microsoft product follows a planned life cycle. There are 3 important dates associated with these lifecycles.
- Lifecycle Start Date – when the product will be officially supported. It’s important to note that most products before this date are available for testing, although you shouldn’t use them in production environments.
- Mainstream Support End Date – by this point, you shouldn’t expect any more new features or free support. Microsoft will continue to provide security updates and fix bugs after this date.
- Extended Support End Date – After this date, you should not expect any new updates as the product will enter an unsupported state. This will be Exchange 2010 after October 13, 2020. While “End of Extended Support” is the official term, “End of Life” is more commonly used.
Do I have to upgrade?
The truth is, you don’t have to migrate before the Exchange 2010 deadline (and some organizations probably won’t). The end of extended support does not mean that your Exchange Server 2010 will suddenly stop working. Unfortunately, when you encounter a problem, you are alone. The only way to get support is to search technical forums and ask other admins. There are also some quality technical articles that can help you. Not to brag, lots of them on this blog. Unfortunately, in some cases this may prove to be insufficient.
Note that using unsupported server software can be unacceptable for many companies, especially if they have strict policies. While Exchange Server 2010 does its job very well, it lacks security, especially when compared to Exchange 2019. If someone discovers an Exchange 2010 server vulnerability, one can only hope that:
- You will not be specifically attacked.
- Someone finds a solution and publishes it in good faith.
Therefore, now is the time to plan a migration to a newer Exchange version or to Office 365.
What do you do next?
If safety through optimism and prayer isn’t your way to get thrills, the only foolproof way to mitigate risk is to migrate. The two most reliable targets are Exchange Server 2019 if you want to stay on-premises, or Exchange Online if you want to minimize your on-premises infrastructure.
Migrate to Office 365 (Exchange Online)
I have previously published a guide for Exchange 2010 to Office 365 migrations. In short, when migrating from Exchange 2010 to Exchange Online, you have three native options:
- A cutover migration that basically moves the entire mailbox database to Office 365.
- A staged migration – similar to Cutover, but mailboxes are migrated in batches.
- And finally a hybrid migration. Hybrid migration allows you to connect your on-premises environment to the cloud. Exchange Server 2010 is the first to allow hybrid environments. The problem: While Office 365 is constantly evolving in the areas of security, scalability and functionality, Exchange 2010 is set to be phased out soon. Managing the cloud remotely with a soon-to-be-deprecated server is problematic. So if you want a hybrid, you’ll need to upgrade (migrate) your on-premises servers first.
Alternatively, you can use a third-party tool: CodeTwo Office 365 Migration. It allows you to automate the migration process to make it seamless.
Migrate to Exchange 2019 and 2016
If you want to see how this type of migration process works, take a look at the following article: How to migrate directly from Exchange 2010 to Exchange 2019.
The exchange team shares some Best practices for migrations from 2010 to 2016 in the Microsoft tech community. The article explains how to prepare for moving and shows that the process is quite complex.
The usual course of action when Exchange Server nears the end of its lifespan is to migrate to the latest version available. Currently that would be Exchange 2019. The biggest problem with this step is that Exchange Server versions that are more than two generations apart cannot coexist in the same environment. So the only native solution is a double-hop migration. This means it will take you at least twice as much time to complete it. And twice as much can go wrong.
Another approach is to perform a cross-forest migration with CodeTwo Exchange Migration. It allows administrators to avoid the double-hop migration, helps with server configuration and automates the move.
