Mailbox compatibility between Exchange versions was reported as a significant issue by Computing’s survey respondents (see figure 1). The reason is that Exchange 2010 CAS, HT and mailbox servers are not backwards compatible with Exchange 2003/2007. This means that OWA users on earlier versions need to continue to access their mailbox on the Exchange 2003/2007 backend server until their mailbox has been migrated to Exchange 2010, after which traffic will be routed through the Exchange 2010 CAS server to their mailbox on the Exchange 2010 Mailbox server.
The pivotal role of the CAS servers (or arrays) means that to maintain high availability it can be advisable to introduce multiple CAS servers in each AD site as well as load balancing the protocols and services provided by this role.
The range of HA solutions set up by survey respondents is shown in figure 5.
[Click images to enlarge]
One big change in Exchange 2010 compared with previous versions is the high availability and disaster recovery functions of the Mailbox Server role. Previous replication functions no longer exist in Exchange 2010, having been replaced by the concept of Database Availability Groups (DAGs).
DAGs provide a software controlled layer of virtualisation and high availability, offering the capability to replicate multiple copies of mailboxes across servers. Before moving mailboxes to the DAGs, check your DAG replication and test failover and failback of the Exchange 2010 Mailbox Servers.
Scheduling for migration has to be set up and run manually as does completion tracking and reporting, so schedule time for these elements of the process.
User mailboxes will be inaccessible for a brief period when they are moved to the new environment. However modern tools enable migration to occur in background so the user can go on using the old mailbox while data is migrated until the decision is made to switch them to the new environment. For example, if migrating from Exchange 2007 to 2010 the ‘suspend when ready’ feature can be used do the majority of data migration while the user is online with the final five per cent being done when the user is off-line.
Since one of the main migration challenges is the sheer amount of time taken to move mailboxes to their new home, all possible measures should be undertaken to eliminate any drag on the process. Tips for faster migration include the following:
• Ensure the two servers are as close as possible to each another on the same subnet
• Reduce WAN bottlenecks – isolate the servers to ensure that backups of other servers on the same backbone do not slow the migration
• Turn off anti-virus software on both servers as virus scans will use resources
• Also make sure your regular scheduled backups are turned off
• Launch the migration tool from the new server rather than the old one
Migration team leaders will have to use their judgement when migrating large mailboxes – the definition of large will vary from one organisation to the next and could be anything from 1G to 5G and above.
This paper seeks to provide education and technical insight to beacons, in addition to providing insight to Apple's iBeacon specification
Focus on cost efficiency, simplicity, performance, scalability and future-readiness when architecting your data protection strategy