Planning the Move to Exchange 2003

As stated, planning the move forward is the key to a successful deployment. Both HP and Microsoft have well-defined processes that examine all the variables associated with a migration and deployment effort and subsequently turn that information into a solution appropriate to your requirements. The assessment process outlined in Chapter 6, "The Physical Design and Developing the Pilot," can be applied to your Exchange 2003 deployment with a key focus on how your organization uses and relies on mail and messaging along with the underlying infrastructure that supports these systems.

After everything has been planned, the next key is to test everything. That includes not only the basic operations of the underlying infrastructure, but also every process associated with the migration. That, alone, will likely include

• Directory synchronization

• Messaging connectivity

• Free/Busy and Public Folder migration

• Delegate access

• Account migration

• Mailbox data migration

• Outlook profile migration

Bottom line is, if you don't plan for success, you will not be successful. It might sound like a clich , but it is absolutely the case. Your migration team, whether it is an in-house team or hired professionals, such as those from HP, need to understand every aspect of the migration. The only way to truly get your brain around what is required is to test everything.

But we've taken a huge leap. First, we need to figure out why we're moving forward.

Exchange Business Assessment

As described in Chapter 6, the first phase of your Exchange 2003 deployment is to define the justification for the Exchange 2003 deployment and identify the key participants for this project (project manager, technical architect, management sponsor and stakeholders). Like the Windows Server 2003 business justification, you want to create a vision of what issues this migration will address along with measurements for success of the project.

Adding a new mail and messaging system might cross corporate boundaries and affect business practices in other parts of your company. It's important to take into account not only the existing mail system architecture, but also how people are using mail and messaging in your enterprise. Are there business applications that are dependent on the current messaging platforms? Are there mail-enabled applications sitting on a PC or mainframe that have to be accounted for? Are there other projects in progress that might affect your mail migration?

For Exchange 2003, the business justification and requirements document will rarely be all-inclusive, but should include the following items:

• Service Level Agreement (SLA) : What availability and services will you offer to the end user ? This would include uptime, message delivery times, and mailbox retention and restore policies.

• Contingency for acquisitions and divestitures : How will these be handled?

• Server consolidation : Is it a goal for this migration to consolidate mailbox servers? Most migrations that have gone to Exchange 2000 already have done the consolidation. There may or may not be much extra room for consolidation because of Exchange 2003, although the cached-mode feature of Outlook 2003 might allow you to push your end users further away from the Exchange servers from a network perspective.

• Cost : How much will it cost for the new technology, training, and administration? This is especially true for those moving from Exchange 5.5 to the 2003 technology.

• Integration and co-existence with other e-mail systems and business systems : For example, are there customer- facing applications that use the messaging service to generate e-mail for customers?

Service Level Agreements (SLAs)

One of the most overlooked business assessment items is the SLA. As stated before, this agreement defines the end users' expectations when it comes to the availability, message delivery times, and number of messages a user can store along with expected recovery times. These SLAs influence the final design, but in truth, they are typically easy to identify and design into the infrastructure.

One key planning element is database backup, restore, and recovery times. Failure on a large database (for example, 200GB) store might take days to recover due to the amount of time necessary to restore the database from tape (or the network), reconnect the mailboxes with users, and then export and import the backed -up data. The beauty of the new generation of Exchange is that you can have many smaller databases per server instead of one database serving users, as was the case with Exchange 5.5. This new architecture allows you to deploy up to 20 databases per Exchange server. And, although each database is unlimited in terms of maximum storage, the gating factor in sizing storage is the recovery time.

For example, if your SLA is 1 hour for recovery and your backup infrastructure can restore 30GB/ hour , you can easily size each database at 20GB, leaving room for growth. Assuming a 100MB storage limit per user means you can service 200 users per database. Multiply that by the 20 databases per server and your Exchange server is now supporting 4,000 users per server. Now, this is not to say that everyone should run out and size a standalone server to this size . We still have a single point of failure with a nonclustered server and having 4,000 users out-of-commission due to a failed system board (for example) is not a good idea, but you can see the possibilities in scaling Exchange 2003 with this example. Of course, with more eggs in one basket you will definitely need to consider other high-availability technologies, such as clustering and Storage Area Networks (SANs), before you start placing many thousands of users on a server.

One of the new technologies that offers some promise is the Virtual Snapshot Services (VSS), which offers the capability to perform "snapshot" backups . VSS is actually supplied by the underlying OS, and applications, such as Exchange, can make use of it. This sounds like nirvana, but there are some "gotchas" involved. First, snapshots need to be supported not only by the OS and Exchange, but also by the backup software vendor and storage vendor. All of these pieces must be coordinated in order for snapshots to actually work. The bottom line is that this technology must be tested in your environment before implementing it in production.

Another technology that enhances availability and is introduced specifically in Exchange 2003 is the Recovery Storage Group (RSG). The RSG enables you to mount a second copy of an Exchange mailbox database on the same server as the original database, or on any other Exchange server in the same Exchange administrative group (AG). This can be done while the original database is still running and serving clients. No clients can attach to the database in the RSG, but it does allow you to fully recover a crashed or corrupted database or restore a database from which individual messages can be restored, thus negating the need for a parallel recovery Exchange organization. With this capability, you can recover data from a backup of the database, unbeknownst to the end user.

The RSG can also be used in a scenario that Microsoft calls Dial Tone messaging service . Dial Tone is implemented by immediately creating a new database for a failed database. This can be done quickly and allows users associated with that database to send and receive new messages. In the meantime, however, a backup copy of the database is recovered to the RSG. After that database has been validated via normal recovery procedures, the two databases can be swapped. In essence, the new Dial Tone database is moved into the RSG, and the recovered database is moved back into production. Then a tool such as ExMerge can be used to move the small amount of data back into the production database. Sound complicated? Well, it's a bit of a shell game, but it's workable . You obviously need to test this feature and determine whether it makes sense in your environment. The important thing to note is that this capability exists. Also note that in Exchange 2003 SP1, Microsoft enables you to move messages from a database in the RSG directly to a production database via Exchange System Manager (ESM). One final thought: Because of the way the RSG was implemented, there is no need for special versions of backup agents to use the RSG; backup is handled by the Exchange backup Application Program Interface (API).

As you work through the assessment and design, check the business assessment document to ensure that your design is meeting your business requirements. This document should also identify success criteria for the project.

Is this step and document absolutely required? No, but how will you know if you are successful or if your project is actually adding value to the business? Further, the most important aspect of this document is getting senior management buy-in to the migration effort, which is critical for any large project. Further, the information we've discussed in this section must be covered somewhere, either directly in your design document or in your operations plan.