Three essential steps for preparing to migrate to Exchange 2013
A comprehensive collection of articles, videos and more, hand-picked by our editors
If you've been looking to move your email to Office 365, there's a compelling argument that it gives end users
practically unlimited storage while always staying up-to-date.
But you'll come across roadblocks in your path to making this a reality. These might involve risks to data sovereignty made evident by recent news stories about the NSA; lack of control over the exact pace of upgrades; compromises to the ability to integrate business applications; or perhaps loss of the ability to respond to service issues without waiting for a third party.
Whether you're staying with on-premises Exchange for the foreseeable future or just waiting until you feel Exchange Online is ready, it makes sense to follow Microsoft's lead and update your Exchange organization. Here are three ways you can accomplish this.
1: You can simplify your Exchange infrastructure.
With an upgrade to Exchange 2013, you've got a good opportunity to reduce your Exchange footprint. The number of roles to install decreased in Exchange 2013, and Microsoft recommends installing Exchange as a multirole server.
If your Exchange 2010 infrastructure includes dedicated servers for unified messaging (UM), or if you've split the Client Access and Hub Transport roles from the mailbox servers, consolidate the number of servers you use. This would include organizations running on virtual infrastructure with some combined Client Access and Hub Transport servers. A two-node Database Availability Group and one or more UM servers can cut down six or more Exchange 2010 servers to just two Exchange 2013 servers.
For multisite deployments, you can also simplify your infrastructure. A typical scenario, for example, would be a two-site deployment that has a primary site and a disaster recovery (DR) site. With Exchange 2010, multiple Client Access arrays, primary and secondary site HTTPS namespaces, and failover and failback HTTPS namespaces mean your DR plans are too complicated. With an upgrade to Exchange 2013, there's no traditional RPC Client Access array to worry about, and you can use a single HTTPS namespace to ease failover and failback.
You can also make things easier if you're load balancing Exchange. Thanks to support for Layer 4 load balancing, you don't need an expensive or powerful load balancer to support Exchange 2013. If you're suffering through Windows Network Load Balancing, this is a great opportunity to improve the service you deliver.
2: You can upgrade to Exchange 2013 to make better use of existing hardware or help a move to less-expensive infrastructure.
One of Exchange 2010's major selling points was the reduced disk throughput requirements, which made it possible to run Exchange 2010 on slow SATA disk storage. The lower throughput requirements made it easy to run within virtual environments, as the mailbox role didn't strain the underlying storage as much as previous versions.
If you've still got a few years left to run with your current infrastructure, an upgrade to Exchange 2013 can stretch your storage infrastructure even further.
Exchange 2013 has new Automatic Reseed features, which means swapping out disks is almost as easy as using RAID storage. This means you could halve the number of disks you currently use and return a large amount of storage to your virtual infrastructure or provide a substantial increase in mailbox quotas.
If you were an early adopter of Exchange 2010, your hardware will likely approach the five-year mark within the next year. Rather than replace it with more of the same or virtualize it, cut costs by using cheaper servers with a smaller number of large disks. This often means replacing large, power-hungry external arrays with smaller rack servers that need a small number of built-in disks to support the same set of users.
3: Using the Managed Availability feature can help you worry less about keeping the lights on.
Most Exchange environments run with minimal intervention as long as they're monitored to some degree and updated. But anything you can do to make running Exchange worry-free is a bonus.
It's in Microsoft's best interest when running Exchange Online to make sure it's as low-maintenance as possible. Those benefits from the cloud directly benefit Exchange 2013 deployments, primarily through a feature called Managed Availability.
Exchange 2013 has a built-in engine to monitor the environment and perform corrective actions -- restarting failed services or ensuring critical services get the right resources, for example. When something fatally fails, Managed Availability provides the right hooks for external systems like load balancers. This helps to understand where failures occur, adjusts behavior accordingly and ensures end users aren't affected.
Finally, Systems Center Operations Manager administrators get a double benefit. The alerts that SCOM generates via the above channels rather than through SCOM agents means the alerts are more focused and consume fewer resources on your SCOM servers.
Click here for part two on making the move to Exchange 2013, which includes details on new features that benefit end users, ways to move away from third-party software reliance and how to prep for the cloud.
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners, Phoenix IT Group. Goodman has worked in the IT industry for 14 years and has worked extensively with Microsoft Exchange since version 5.5.