Dear Microsoft Exchange 2010, you’ve brought us, admins, a lot of joy. But your end is drawing near and fast. The end of Extended Support, also known as the end of life was planned on January 14, 2020, together with Windows Server 2008 and Windows 7. However, because of all the love for the good old 2010 version, and the fact that it still remains very popular, Microsoft reschedules Exchange Server 2010’s demise. The current date is October 13, 2020. This might seem like a lot of time. But if you have some experience performing Exchange Server migrations, you probably know that the time for planning and migrating is running out quicker than one might expect…
The article below reminds why we loved Exchange 2010 while it was in its prime, what does “end of life” really mean and what are the possible plans for the future.
- Why we loved Exchange 2010?
- What does “End of life” mean?
- Do I need to upgrade?
- What should I do next?
- Migration to Office 365
- Migration to Exchange 2016 or 2019
A bit of nostalgy
How was Exchange 2010 different from its predecessors? It brought a few cutting-edge improvements, and I will try to highlight the most relevant ones.
Exchange Management Shell
Theoretically, PowerShell was introduced to Exchange Server 2007 first. However, it was with the release of Exchange 2010 that a dedicated Exchange Management Shell was deployed. What is more, Exchange 2010 was where RBAC and PowerShell joined forces. Starting from this point, users without the right permissions are not able to see some cmdlets – they aren’t downloaded to their PowerShell console anymore. Since then, most replies to problems on technical forums start with “it’s probably a permission issue”.
With the release of soon to be gone Exchange 2010, PowerShell also got a whole lot of great new cmdlets, the most important being:
- Send-MailMessage, used primarily to spoof internal addresses (not that good) and send tons of spam emails using the console (even worse). Fortunately, it can be also used to configure email notifications for PowerShell scripts (which is awesome).
- New-MailboxExportRequest and its import-related counterpart, used to generate or take in PST files. Many administrators have used them for a flaky Exchange backup substitute (still better than no backup at all).
- Numerous cmdlets related to managing federation trusts, OWA mailbox policies, Exchange Active Sync and other features new to Exchange 2010.
Legacy public folders
Exchange 2010 was the last to host legacy public folders. Starting from Exchange 2013 up, each public folder is treated as a kind of mailbox. Before that public folders had a separate database. While this change was a good thing, migration from legacy public folders to modern public folders turned out to be a challenge best solved with third-party migration tools.
Administrator audit logs
The introduction of administrator audit logs in Exchange 2010 made it possible to track who broke what and when it happened. Since then, all security-obsessed professionals rejoice 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?
Each Microsoft product follows a scheduled lifecycle. There are 3 important dates connected with those lifecycles.
- Lifecycle Start Date– when the product starts to be officially supported. It is important to know that most products are available for testing before this date, although you should not use them in production environments.
- Mainstream Support End Date – this is when you should not expect new features and complimentary support anymore. After this date, however, Microsoft still provides security updates and fixes bugs.
- Extended Support End Date – starting from this date, you should expect no new updates, as the product enters an unsupported state. That is what will become of Exchange 2010 after October 13, 2020. While “end of extended support” is the official name, “end of life” is more commonly used.
Do I need to upgrade?
The truth is: you do not have to migrate away from Exchange 2010 (and probably some organizations won’t) before the deadline. The end of extended support does not mean that your Exchange Server 2010 will suddenly stop working. Unfortunately, when you encounter an issue, you will be alone. The only means of support will be searching through technical forums and asking other admins. There are also some high-quality technical articles that may help you. Not to brag, many of them on this blog. Unfortunately, in some cases this may turn out not to be enough.
Mind that using server software that is not supported may be unacceptable for many companies, particularly when they have strict policies. Although Exchange Server 2010 does its job very well, it is lacking in terms of security, especially when compared to Exchange 2019. When someone discovers a vulnerability of the Exchange 2010 server, you can only hope that:
- You will not be targeted.
- Someone finds a fix and publishes it out of their good will.
That’s why the time to plan a migration to a more recent Exchange version or to Office 365 is now.
What to do next?
If security by optimism and prayer is not your way to get a thrill, the only foolproof way to mitigate risks is a migration. The two most reliable destinations are Exchange Server 2019 if you want to stay on-premises, or Exchange Online if you want to minimize your on-prem infrastructure.
Migrating to Office 365 (Exchange Online)
I’ve already 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, which basically moves the whole 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 with the cloud. Exchange Server 2010 is the first to allow hybrid environments. The problem is that, while Office 365 is constantly developed in the security, scalability and functionality areas, Exchange 2010 is soon to be retired. Remote management of the cloud with a soon-to-be unsupported server is asking for trouble. So if you want a hybrid, you need to upgrade (migrate) your on-prem servers, first.
As an alternative, you can use a third-party tool: CodeTwo Office 365 Migration. It allows you to automate the migration process to make it seamless.
Migration to Exchange 2019 and 2016
If you want to see how this kind of migration process is done, take a look at the following article: How to migrate from Exchange 2010 directly to Exchange 2019.
The Exchange Team shares some best practices for migrations from 2010 to 2016 in Microsoft Tech Community. The article explains how to prepare for the move and illustrates that the process is quite complex.
The usual course of action when Exchange Server’s life is nearing an end is to migrate to the newest version available. Currently, that would be Exchange 2019. The greatest problem with that move is that Exchange Server versions which are more than two generations apart, cannot coexist in the same environment. So the only native solution is a double-hop migration. This means that you need at least twice as much time to finish it. And twice as many things can go wrong.
Another course of action is to perform a cross-forest migration with CodeTwo Exchange Migration. It allows administrators to avoid the double-hop migration, helps with the server configuration, and automates the move.
CodeTwo sp. z o.o. sp. k. is a controller of your personal data.
See our Privacy Policy to learn more.