Exchange 2010 leaves support – Here are its top 5 advancements

This week in October 2013, Exchange Server 2010 left support along with the Office 2010 suite. If you moved to Office 365 some time ago, then Exchange 2010 might sound a distant memory. Still, it probably won’t surprise you that many companies have been completing their migrations throughout the last year and are only just decommissioning it.

Whilst Exchange 2007 was sometimes referred to as the Windows Vista of Exchange versions, Exchange 2010 was possible the Windows 7 of Exchange and worked well and brought advancements that are still fundamental to newer versions of Exchange, and Office 365. Here’s the Practical 365 top five advancements it heralded that made a big difference to the way Exchange works.

The Top 5 Advancements in Exchange 2010

5. Cross-Platform OWA

It seems hard to imagine, but there was a time when accessing Outlook Web App, or Outlook Web Access required you to use Internet Explorer – and with Exchange 2007, this improved slightly with a cut-down version called OWA Light. Exchange 2010 brought full support for all major browsers at the time – including Firefox, Chrome, and Safari, and it is quite hard to imagine a time where you would need to launch a special Microsoft browser just to access your email. 

Outlook Web App has been rebuilt several times in newer versions of Exchange. In Exchange Online, Outlook on the Web uses a newer interface common with Outlook.com – but fundamentally, this was the first version of OWA that people could genuinely use as a daily email client.

4. Roles Based Access Control

With Exchange Server 2010, Roles Based Access Control, or RBAC arrived, allowing IT teams to have a granular model for delegating specific rights, access to commands, and control over groups of users to administrators, helpdesk staff, and other IT teams.

RBAC remains a fundamental part of Exchange 2019 and Exchange Online and hasn’t dramatically altered since 2010 – and it’s core functionality continues to be the most advanced, in terms of delegated controls, in the Microsoft 365 suite. Over time, Azure AD and other services have begun to adopt the model, but nothing has replaced it, even in the cloud.

3. Large Mailbox Support

When I say large mailbox support, I’m really talking about what makes that possible – the ability Exchange 2010 introduced to use slower SATA/midline SAS disks that could be bought cheaply and in combination with Exchange 2010 work well. Before Exchange 2010 an Exchange deployment would typically be based around a concept of high-speed, expensive disks that could satisfy many read/write requests.

Whilst Exchange 2007 brought some improvement, it wasn’t until Exchange Server 2010 that the mainstream way to deploy Exchange was to by using slow 7200RPM, multi-terabyte enterprise SATA speed disks, in servers with a large (at the time) amount of RAM. This new model allowed Exchange Server to use RAM to store more information in fast-accessible memory to accelerate access and then write changes to databases in longer streaming writes, making performance better. The ability to use the cheapest enterprise disks available made it feasible to provide much larger mailboxes to users. If not for the improvements introduced with Exchange 2010 – would mean it’s unlikely we’d see the large 100GB mailboxes with 1TB archives available today in Exchange Online.

2. Database Availability Groups

Of course, large mailboxes on big, cheap disks wouldn’t be feasible without the ability to keep them highly available. Exchange 2007 brought the first iteration of what underpins Database Availability Groups (DAGs), Continuous Replication (CR)– and the last version of traditional single-copy clusters.

CR allowed a copy of the database locally (on the same server), in a cluster, or as a disaster recovery copy. This was a reliable technology but was complex to implement and manage, mostly if you wanted to have a remote copy and remained focused around Exchange 2003-era concepts such as storage groups and ownership by servers.

DAGs changed the entire concept of how databases relate to Exchange Servers, moving databases to being managed at an organization level, with Exchange Servers becoming member servers to a group (the DAG). DAGs also provided the ability to have up to 16 member Exchange Servers, with as many database copies as members available, across multiple sites.

DAGs, and underlying improvements to the way database replication could work (such as block-based log shipping), and improvements to site failover and failback meant that it became the de-facto standard to, where possible, build multi-site Exchange DAGs, with many organizations building multiple DAGs across datacenters and running active across both sites. Before this, most implementations were either single site, single active site, and (for single copy clusters) used complex third-party SAN replication technologies.

It’s hard to underestimate the importance of the DAG today when it relates to modern Exchange and Exchange Online. The DAG concept made building out cloud-scale Microsoft 365 services possible. The reliability of modern DAGs means that Exchange Online has become the de-facto immutable compliance store for most services in Microsoft 365.

1. Exchange Hybrid

Of course, if you have no plans to ever move to Exchange Online, then Exchange Hybrid won’t be the top of your list. But for many, many organizations, Exchange Hybrid has made a move to Microsoft 365 a relatively easy part of the move to the cloud.

Exchange Hybrid was first introduced after Exchange 2010 Service Pack 1. It involved many manual steps in configuring Exchange Server so that mail flow, mailbox migrations, and cross-forest coexistence for free/busy worked in a supported way. However, with Exchange 2010 Service Pack 2, this became wizard-driven for more straightforward implementation.

Hybrid configuration in Exchange 2010 relied – and still depends – upon a collection of different Exchange 2010 technologies such as Federated Sharing and Remote Mailbox Moves, which could also be configured for simple cross-forest migrations. In the Exchange Hybrid scenario, web-service enablement of these technologies and SMTP domain sharing allowed two Exchange organizations – your on-premises environment and Microsoft’s Exchange Online service, to act as one organization.

As a rarity in cloud-migration tools, Exchange remains one of the only services where moving a mailbox can be done in both directions – and because it’s done at a database level rather than simply copying it from a user perspective, Hybrid moves avoid painful aspects like re-synchronisation of data locally. Although improvements like cross-premises access to Shared Mailboxes, OAuth access, and Hybrid Modern Authentication have been introduced since Exchange Hybrid first debuted, the fundamental components that makeup Exchange Hybrid have remained mostly unaltered since Exchange 2010 was introduced.

Still stuck on Exchange 2010?

If you are still on Exchange 2010, you probably have your reasons – and you know, although it’s out of support, it won’t stop working overnight. However, it would be best if you moved as soon as you possibly can. If you’re on Exchange 2010 and can’t migrate, drop a comment below and let us know what’s stopping you.