In-Depth
Ensure Post-Migration Exchange Stability
Follow these few simple guidelines to ensure that your new Exchange 2003 environment is ready for prime time.
If you're in the process of migrating to Exchange 2003, you want to be sure that you do things right and make the transition as smooth as possible for your users. If you've just finished your migration, perhaps you're wondering how well it really went. Is the environment optimized? Is there a disaster waiting to happen?
Migration to Exchange 2003 can be tough, but that's just the beginning of the battle. Once you get there, you have an entirely new beast on your hands that requires attention and care to tame. You can follow a few simple guidelines to ensure that your new Exchange 2003 environment will be ready for prime time.
Post-migration stability or system stability in general is most commonly thought of as ensuring uptime. If the system is online, it's stable, right? I think we all know better than that. Exchange server uptime is really a combination of several things. A system's uptime can be affected by factors such as performance, architecture, and security. Ensuring maximum stability of an Exchange environment requires the administrator to consider all of these things.
But before worrying about how to optimize your new Exchange environment, you should take into consideration the history of the environment. Here are some common migration problems and their solutions, followed by some basic optimization and best practice recommendations that you can take advantage of immediately.
Migration Strategies
You know what they say, "Out with the old, in with the old?" Did you really clean up legacy settings? Is there something in your environment that might be affecting your Exchange servers without you knowing? Well, it might depend on the migration method you chose when deploying your Exchange environment.
There are two overall ways to approach an Exchange migration. You can either migrate into your existing Exchange Organization (ORG) or migrate into an entirely new ORG. If you decide to migrate to an entirely new ORG, then you're in luck—you probably don't need to worry about any legacy settings. However, the rest of us might have made changes over time that will come over to the new environment. Sometimes these settings are compatible; other times they are benign. But in some cases, they can be disastrous.
The migration methods typically used when upgrading an Exchange Organization are mailbox move, swing upgrade, in-place upgrade, ExMerge, and Migration Wizard. A description of these methods can be found in the Microsoft Knowledge Base Article (KBA) 327928. Of course, you can also use third-party tools to enhance or optimize the migration process, but they come at a price. No matter which migration method you choose, it's guaranteed that legacy components of your old environment will come with you. That's not a bad thing. A migration should bring your old settings with you. However, some legacy components might be incompatible or inappropriate for Exchange 2003, and these are the ones that should be of concern to you.
The upgrade method most prone to these dangers is by far the in-place upgrade. The upgrade is done by simply upgrading the existing Exchange 5.5 or Exchange 2000 server directly to Exchange 2003. Servers are not rebuilt and most, if not all, settings are preserved automatically. The preferred methods of upgrading are usually the mailbox move or swing upgrade methods. These require that new servers be built as targets for mailbox and public folder data.
Know Thyself
Knowing yourself means not only knowing who you are, but where you've come from, right? So, if you used an in-place upgrade, were you Exchange 2000 previously or Exchange 5.5? Were you Exchange 5.5 before you were Exchange 2000? These questions are not only relevant to the server, but to the Exchange ORG as well. Even if you've rebuilt all of your servers, don't forget that they share a directory. If you came from Exchange 2000, this directory hasn't changed significantly. If you came from Exchange 5.5, you had to migrate to an entirely new directory. Were there any modifications made directly to these directories in the past? What about items that don't belong to any server in particular, like connectors?
Detecting and removing legacy settings depends on the migration method you've used. If you did an in-place upgrade, you'll likely be concerned about registry keys that you might have used to tune the server in the past, like memory tuning (KBA 313707). You might also be wary of changes you made that are stored in Active Directory instead of the local registry, such as the SMTP Mailroot directory location (KBA 318230). If you had a long stay in mixed mode (Exchange 5.5/2003), you might have made some optimization settings for your MTA that are no longer appropriate when you convert to native mode (KBA 264075). No matter what migration path you took, any tuning required you to modify the Exchange Directory (5.5 or Active Directory); those settings are likely still with you. Don't forget that your connector configurations are stored in Active Directory.
In general, it is important to remember that tuning parameters or registry keys are sometimes specific to the version of Exchange or even Service Pack. These are just a few of the hundreds of changes that are possible. Really, documentation is the key. As long as you have good documentation of your configuration changes, you will be able to verify whether those changes will have any effect on your new Exchange 2003 Organization.
Tackle Common Problems
One of the main goals of any migration is to make sure the migration is smooth and provides little or no interruption to end users. Again, the migration method chosen can have a drastic impact on this. However, once you've migrated, there are a few key things to remember to make sure things are working as you'd expect.
Exchange has the capability to direct users to the proper mailbox server, even if their mailbox is not on the server that they attempt to connect to. This is known as profile redirection—make sure you take advantage of this. Plan for remote users and latecomers. Don't change that server name just yet. This means that if you decide to go with new hardware and a new Exchange server name, you should leave the old server up as long as possible. Of course, you could choose to keep the old server name on the same hardware, but that would require using an undesirable in-place upgrade or doing something like what is in KBA 822945, which results in downtime. Although not usually recommended, another little-known trick is that you can also assign multiple NETBIOS names to the same machine by setting OptionalNames (can be either REG_SZ or REG_MULTI_SZ) in HKEY_Local_Machine\System\CurrentControlSet\ Services\LanmanServer\Parameters. You could take the original server offline as long as you've set this key and your name resolution is set up properly.
No matter which method you choose to enable users to take advantage of profile redirection, clients will be able to connect using the old server name and have their Outlook profile updated automatically if needed. Use the Exchange System Manager to take a look at the account logons and the last time the mailbox was accessed to help you determine who still hasn't logged into the server. This way, you know when everyone has had a chance to access the new server and have their Outlook profiles updated before you decommission the old server.
Mail Delivery Issues
Mail delivery can sometimes be an issue depending on the migration method you've used. Users might find that messages bounce if they reply to old messages from coworkers within the organization. Messages might also bounce if they send new messages to these same users and use the autogenerated name from Outlook. Messages are delivered successfully if they compose a new message and select the name from the address book. This is usually a result of a missing or incorrect X500 proxy address attribute. This attribute defines all legacy names the mailbox might have had in the past. This attribute becomes important if the mailbox existed previously on an Exchange 5.5 server in a different site. Older messages or a cached name in Outlook will use the distinguished name of the old mailbox, not the SMTP address for internal message delivery. The mailbox must have an attribute that lets the Exchange ORG know where to deliver messages to sites or mailbox locations that might no longer exist. See KBA 313324 for more information on setting the X500 proxy address.
Earlier, I stated how important it is to "know thyself." Well, the SELF attribute might be your savior if and when troubleshooting access to user mailboxes. Organizations often find during a migration that a user somehow becomes the primary user for a mailbox that is not really his own or perhaps cannot access his own mailbox at all. For example, Bob accesses both his own mailbox and a Sales mailbox. But during the Exchange migration, a switch happens where Bob becomes primary for the Sales mailbox, and the Sales account becomes primary for Bob's mailbox. Although things seem to be working properly (Bob can access both mailboxes), problems start to occur when Bob accesses Outlook Web Access (OWA). Bob is primary for the sales mailbox, so he ends up going directly into the Sales mailbox every time he uses OWA. If he wants to access his own mailbox, he ends up having to use a URL appended with /exchange/username.
A problem with permissions can usually be corrected by examining both the "SELF" attribute and the "associated external account" permission. You can find these by examining the Exchange Advanced tab of a user object. The Exchange Advanced tab is made available by selecting "Advanced Features" from the View menu in Active Directory Users and Computers. Once on the Exchange Advanced tab, select "Mailbox Rights." Here you will see all accounts and groups that have some form of access to the user's mailbox. The inherited rights have come from ORG, Administrative Group, server, or store-level configurations. In addition to inherited rights, you should see a group called "SELF." By default, "SELF" has read permissions, full mailbox access, and is the associated external account.
In the example with Bob and the Sales mailbox, you would have seen the Sales account as the associated external account for Bob's mailbox and Bob's account as the associated external account for Sales instead of "SELF." You can correct this issue by assigning "SELF" the appropriate rights for both Bob's and the Sales account mailboxes. You can add "SELF" if it's missing. Keep in mind that you can only have one associated external account per mailbox when making changes.
Set Up Your Servers (and Yourself) for Success
You should use some basic techniques to ensure stability and prevent downtime. Now that you've migrated and taken care of some specific user issues, the last thing you want is an unstable environment.
The two resources Exchange consumes as much of as possible are disk I/O and memory. There are some basic techniques you can use in the design of your Exchange servers to deal with this. Of course, RAID should be used for all drives on the server, and hardware RAID is preferred to software RAID. However, equally important is ensuring that you've taken the time to optimize the file placement on your arrays. At a minimum, you should separate your database and log files to improve performance and recoverability. Separating data onto different physical arrays is preferred. See KBA 328794 for more information. Exchange is a disk I/O intensive application, so ensuring that your storage is optimized is the key.
Memory tuning is also extremely important for Exchange. Microsoft has numerous Knowledge Base articles on this subject of memory optimization. Depending on the amount of memory in your Exchange server, you can optimize its performance. A good rule of thumb is to never put more than 4 GB of memory in your Exchange server because Exchange addresses only up to 3 GB (even when tuned). A good starting point for memory optimization is KBA 815372.
What about processor speed? Usually processor is not the bottleneck, so just know that typically two or four processors are enough for even the largest Exchange server. Exchange will not effectively use more than eight processors at a time. See KBA 827821 for more information on CPU and memory scalability.
You should also take advantage of new (if you're coming from Exchange 5.5) features such as System Policies to configure your environment. This way, you can ensure that all of your servers conform to the same standards. KBA 822938 discusses the use of system policies for configuring mailbox storage limits. You can use these same policies to configure things such as deleted item retention or mailbox retention so that users are able to recover deleted items and you're able to recover deleted mailboxes without restoring from backup. You might also consider enabling message tracking through a server policy (especially in larger environments) so that you can troubleshoot mail-delivery issues that might arise within your organization. One thing is for certain: Exchange System Policies are there to make your life easier.
Best Practices
Remember to adhere to other best practices around Exchange architecture as you move forward. Considerations such as Global Catalog (Domain Controller) placement and optimal routing group connector configurations become more critical, especially if you've come from Exchange 5.5 where these things didn't exist. There isn't enough that can be said about how important it is to remember that your Exchange 2003 environment is something completely new with different features and requirements than you had when you ran Exchange 5.5 or even Exchange 2000. It really depends on what features you are taking advantage of.
Make sure to understand the different operating system and hardware requirements of Exchange 2003. For example, you previously needed to run Windows 2000 Advanced Server to utilize the 3 GB memory tuning switch, but you can now do the same with Windows Server 2003 Standard. Front-end servers no longer require the Enterprise Edition of Exchange. Knowing things like this can save your origination money and ensure that your new environment is designed optimally.
So, you've made it through your migration with just a few minor bruises and now it's time to push on. Going forward, make sure you take full advantage of all the new features that your Exchange 2003 environment offers. Features such as storage enhancements, OWA forms-based authentication, RPC over HTTPS, security, and memory enhancements are just the beginning—not to mention the new 75 GB mailbox store available in the Standard Edition with Service Pack 2.
Considering what's available to you will help you better optimize and stabilize your Exchange deployment in the future. There's a lot to learn once you've migrated, but it is a challenging and rewarding road that will certainly pay dividends for years to come—especially once you're ready to migrate again to the next version of Exchange.