Getting to grips with Exchange 2010
The new Exchange Server is here – is it time to move your clients to the latest version of Microsoft’s messaging platform and how much work does that mean for you?
Exchange 2010 is the latest version of Microsoft’s messaging platform, intended to act as a hub for voice and email. Like Exchange 2007, it can be installed as one server or as several, each handling different roles and adding high availability where necessary. Like the step from Exchange 2003 to Exchange 2007, there’s no direct upgrade route from any previous installations – and as it only runs on Windows Server 2008 R2, it almost certainly means adding a new operating system to a network. There’s an additional sting in the tail, as you can’t run Exchange 2007 on Windows Server 2008 R2, so any migration and upgrade requires adding one or more new servers to a network (at least temporarily).
There are many reasons for upgrading to any new version of Exchange. There may be new features that clients want, or perhaps the business has out-grown an existing messaging infrastructure, and is looking for a new solution. Exchange 2010 adds a large number of new features, including an upgraded Outlook Web Access that adds more desktop features and a conversation view similar to that in Outlook 2010. If your clients are using Exchange as part of a unified messaging service they can also get a text version of voice mail – something that could be a lot more useful than it sounds, especially for small businesses where key decision makers are frequently out of the office. For clients who are unsure about using hosted Exchange you can implement a hybrid model, using hosted Exchange as a cloud-based alternative to their on-premises system. Implementing a hybrid cloud/on-premises Exchange could also reduce the risk of outages, using hosted Exchange as a piece of any disaster recovery plans you offer. There are also improved information protection tools, important for any regulated business or for businesses where information security is a priority – including financial advisers and lawyers.
Perhaps the biggest change, and the one that’ll have the most impact on the clients you’re supporting, is the move to what Microsoft is calling ‘mailbox resiliency’. Instead of failing over at a server level, Exchange 2010 fails over at a mailbox database level. With multiple mailbox databases on multiple servers in a large installation, that’ll mean much faster failover – and quicker recovery. If you’re hosting recovery servers for a client, then you’ll be able to bring them back much more quickly. There’s also the option to provide a two-server install where all the Exchange roles are installed on each server, allowing failover between servers without having to set up a full Windows Server failover cluster. You don’t even need to set up Exchange 2010 for high availability when you install it; it’s something that can be added later as your customers grow to need it.
If you’re upgrading the server OS to Windows Server 2008 R2 for other reasons (perhaps for Branch Cache or DirectAccess), you have no choice but to move them to Exchange 2010, because Exchange 2007 won’t run on R2 (but you don’t need to upgrade from Windows Server 2008 just to run Exchange 2010).
While there are plenty of underlying changes in Exchange itself, few of them are visible; those that are show up in the Exchange Management Console. This looks much like it did in Exchange 2007 but now includes an Organizational Health view which lets you see how many users you have per server, along with how each user is using the service – useful details from the number of messaging records, to the number of users with access to OWA and to Exchange Active Sync.
Roles and certificates
Planning an Exchange 2010 upgrade may look complicated, but the actual process is relatively simple. As there’s no in-place upgrade path, upgrading from Exchange 2003 or 2007 means running two different Exchange systems together during the upgrade then migrating. This means some users will be using Exchange 2007, while others get access to Exchange 2010. That shouldn’t be a problem for a SME install, where mailboxes can be moved relatively quickly. However if you’re working with a client with a lot of large mailboxes you’ll need to be prepared for any confusion during the changeover process.
If your clients’ have more than one server in their Exchange implementation, you’ll need to upgrade the servers in a specific order. You’ll need to upgrade any Internet-facing sites first, as Client Access Server to Client Access Server proxying only works from a newer version to an older version. Any users trying to connect with a mobile device or using Outlook Web Access won’t be able to access mailboxes held on Exchange 2010 from Exchange 2007.
Start by making sure your clients’ existing Exchange implementations are running versions that can be upgraded. Both Exchange 2003 and 2007 need to be running SP2, so ensure that all the latest service packs and upgrades are installed before you start. You’ll also need to check that your clients’ networks are running an Active Directory Schema Master that’s at least Windows Server 2003 SP1.
Microsoft recommends installing the Exchange roles in the following order: Client Access Server Hub Transport Server Unified Messaging Server (if required) Mailbox Server
Setting up the first external-facing Client Access Server is possibly the most important piece of the Exchange 2010 upgrade. You’ll first need to set up a new digital certificate for any SSL connections, using a commercial certificate registry. It is possible to self sign Exchange 2010, but you will then need to distribute certificates to client PCs and mobile devices in advance of any switch over. A certificate from a commercial registry that’s already trusted by most operating systems and browsers is a much better choice. Like Exchange 2007 before it, Microsoft recommends using a Subject Alternative Name certificate, in order to support the server’s actual name, along with any CNAMEs in use (such as those required to autoconfigure remote Outlook clients and Exchange ActiveSync mobile connections, as well as any alternative names used for POP3 or IMAP connections). Wildcard certificates are also supported, but there are security implications when using certificates that are valid for all the sub domains.
One option is to install using the default self-signed certificate, then use Exchange 2010’s certificate wizard to request and install the certificates you’ll need. There’s a lot to be said for taking this approach, as it lets you deploy and test servers before locking your clients’ in to a particular PKI vendor (as well as letting you choose the most cost-effective provider – as well as one that offers SAN certificates with the appropriate number of name slots).
Once you’ve chosen how to handle client access certificates, you can set up a Windows Server 2008 R2 machine ready for the Client Access role. This means installing .NET Framework 3.5 SP1, with the Windows Server 2008 x64 updates. You’ll also need to ensure that the server is running Windows Remote Management 2.0 and PowerShell 2.0. There are additional requirements for servers that will be running as Hub Transports or Mailbox Servers, and these need the Microsoft Filter Pack, which can be downloaded from microsoft.com/downloads/details.aspx?FamilyID=60c92a37-719c-4077-b5c6-cac34f4227cc&displaylang=en; this adds IFilters for the Exchange indexing tools.
Migrating from an older version
While most of your clients may be small enough that you can manage a migration in a single scheduled downtime, larger clients will need to run Exchange 2010 in parallel with Exchange 2007 (or 2003) while you move mailboxes to the new server. With two servers coexisting, you’ll need to set up a legacy address for the older Client Access Server. This will be of the form legacy.domain (where the old server name was mail.domain). One the new Client Access Server is up and running, switch server names so that the new server is mail.domain and the server that’s being upgraded is legacy.domain. Users with mailboxes still on the old server will be redirected to the older server transparently – keeping the two Exchange infrastructures running in parallel.
There’s not much difference between configuring an Exchange 2010 Client Access Server and Exchange 2007. You will need to use PowerShell to enable key functions, like Outlook Anywhere, though you’ll be able to do most of what you need from the setup GUI – especially if you’ve defined your Client Access domain in advance. The Client Access Server also hosts Exchange ActiveSync, so you’ll need to manually copy authentication settings from your old server. You can do this using the Get-ActiveSyncVirtualDirectory and Set-ActiveSyncVirtualDirectory cmdlets.
Exchange isn’t only a mail user agent, it’s an effective mail transport system, with the Hub and Edge transport servers handling mail transfer inside and outside a network. Most SMEs combine the Hub and Edge transport functions into a single server, as well as combining internal and Internet-facing roles.
If you’re using Exchange 2007 Edge Transport servers, then you will need to first connect any Exchange 2010 Hub Servers to the existing Edge Transport systems, before installing new Exchange 2010 Edge Transport servers. These can be run in parallel with the original servers, before they are decommissioned and removed from a network.
Microsoft has changed how messages are routed in Exchange 2010, and an Exchange 2010 Hub can’t deliver mail to an Exchange 2007 Mailbox server. You’ll need to have both in the network until all mailboxes are moved to the Exchange 2010 system. Once all mailboxes are running on Exchange 2010 you will be able to decommission your clients’ old Hub servers. One thing to note: if you’re creating or updating any transport rules while Exchange 2010 is coexisting with Exchange 2007 you’ll need to make any changes in both places – as they only synchronise rules during initial setup.
The last piece of any move is moving mailboxes. As with any Exchange migration to a new server, this is a relatively simple process, using either PowerShell cmdlets or the Exchange Management Console. Moving using the console works best for a small number of mailboxes, and we’d recommend building a PowerShell script if you need to move more than ten or so. A script can be left running overnight, or used to batch up moves into manageable chunks. If you’re staging moves, then some users will be on earlier versions of Exchange. It’s a good idea to suggest that users don’t rely on any Exchange 2010-specific features (like the warning in Outlook 2010 if you’re trying to email someone who has set an out-of-office message) until the entire organisation is running on the new version.
In smaller businesses, you’re not likely to be working with Exchange implementations using unified messaging features. If you are, set up a new Exchange 2010 Unified Messaging server alongside the existing Exchange 2007 system. You will then need to create a modified dial plan so that all calls are sent to the Exchange 2010 system. This will route calls to Exchange 2010 mailboxes if they exist, or to the Exchange 2007 Unified Messaging server for mailboxes that haven’t been moved.
If your clients are using a single server, you can install the new Exchange 2010 server with the same options, and migrate mailboxes using the same techniques for a distributed network. You probably won’t need to set up a legacy address during this process, but the option is there if you want to bed a new server in before completing a switch over. Once mailboxes have been migrated you can retire the old Exchange infrastructure, either reusing the servers for other purposes, or upgrading them to Windows Server 2008 R2 and installing Exchange 2010 to increase the resilience of your clients mail infrastructure. Going from one Exchange server to two (especially with Exchange 2010’s built-in failover and clustering features) can significantly increase uptime and reduce the risk of mail outage – something that’s very important to businesses where email is both internal workflow and the main point of contact with customers and partners.
You don’t need to make your clients buy a completely new server when running an Exchange 2010 upgrade, especially if their hardware is capable of running Windows Server 2008 R2. One option is to rent them a server, running Windows Server 2008 R2 and Exchange 2010, for the duration of any upgrade project. Migrate the existing Exchange 2007 mailboxes to the temporary server, and then decommission the original Exchange 2007 server. Instead of repurposing or disposing of the original hardware, reimage it with Windows Server 2008 R2 (if required) and install Exchange 2010. With the original and temporary servers both running Exchange 2010, all you need to do is move the mailboxes back to the fresh install of Exchange 2010, before decommissioning and removing the temporary server.
Exchange 2010 system requirements
Microsoft has been tightening the hardware requirements for Exchange over the years, and Exchange 2010 adds additional requirements. While Exchange 2007 had a 32-bit version for training and for a limited number of deployment scenarios, there’s only a 64-bit implementation of Exchange 2010 – and only for Intel 64 and AMD 64, not for Itanium.
You’ll find details of memory requirements at: technet.microsoft.com/en-us/library/dd346700.aspx
There are also some operating system level issues. You’re limited to Windows Server 2008 SP2 and Windows Server 2008 R2 (our preferred deployment platform). Microsoft suggests installing Exchange 2010 on a member server for performance reasons. However you will need to be sure that the site Active Directory is at least Windows 2003 native – so make sure that you’ve raised the domain level for all the AD servers before you start an install.
Exchange 2010 will virtualise quite happily – and Microsoft supports it in production on dedicated virtual machine hosts running Hyper-V or Hyper-V R2, as well as on certified third-party hypervisors from Cisco and Citrix to Red Hat, SUSE and VMware (you’ll find a list here: windowsservercatalog.com/results.aspx?&bCatID=1521&cpID=0&avc=0&ava=0&avq=0&OR=1&PGS=25).
One thing to note, there’s no support for Unified Messaging in virtual environments. You’ll also need to use a fixed virtual disk, as expanding disks aren’t supported by Exchange 2010.
Installing Exchange 2010
The Exchange 2010 installer gives you two options – a typical all-in-one Exchange Server install, or a custom install for single role servers or to add Unified Messaging support to a server.
Choose the Internet-facing address for the new server before you start the install, as you’ll need to fill it in before you can start your install.
There are a lot of pre-requisites for a successful Exchange 2010 install. Are you running the correct version of Active Directory, is any coexisting Exchange install at the correct SP level, are the right search filters installed?
Securing Mail with Exchange 2010
Business regulations mean that it’s more and more important to manage the flow of data inside your clients’ businesses – and this means controlling the flow of email.
Exchange’s Transport Rules can be used to control messaging between different distribution lists (themselves an excellent way of grouping and managing users by role or organisation).
Messages can be protected using Exchange’s rights management tools. Set up rules using the Active Directory Rights Management Services Tools, and then apply them through a Transport Rule.
Rules don’t need to be exclusive – you can set exceptions. Perhaps the Finance Director or the Managing Director can send messages outside the business, or managers can do more with messages than their staff.