Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly
more resources

Ensure Post-Migration Exchange Stability
Following these steps will help you execute a smooth transition to Exchange 2003.
by Sekou Page

October 5, 2005

Migrating 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 will require attention and care to tame. By following a few guidelines, you can ensure your new Exchange 2003 environment will be ready for prime time.

ADVERTISEMENT

Post-migration stability, and system stability in general, is most commonly thought of as ensuring uptime. Some people think—or want to think—that if the system is online, it's stable. Unfortunately, most of us know this isn't the case. Exchange server uptime is a combination of several things. A system's uptime can be affected by factors like performance, architecture, and security. Ensuring maximum stability of an Exchange environment requires the administrator to consider all of these things.

Before worrying about how to optimize your new Exchange environment, you should consider the history of the environment. These common migration problems and their solutions are followed by some basic optimization and best practice recommendations that you can take advantage of immediately.

Look at 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 it? Lingering problems could have been caused by the migration method you chose when deploying your Exchange environment.

Generally you have two methods to approach an Exchange migration. You either can migrate into your existing Exchange Organization (ORG) or migrate into an entirely new ORG. If you decide to migrate to an entirely new ORG, you're in luck—you probably don't need to worry about any legacy settings. The rest of us, however, might have made changes over time that will migrate to the new environment. Sometimes these settings are compatible, other times they are benign, and in some cases they can be disastrous.

The five migration methods typically used when upgrading an Exchange Organization are mailbox move, swing upgrade, in-place upgrade, Exmerge, and migration wizard. You can find a description of these methods in Microsoft Knowledge Base Article (KBA) 327928, A comparison of the migration methods for migrating from Exchange Server 5.5 to Exchange Server 2003 or to Exchange 2000 Server. Of course, you also can 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. This is not a bad thing, and it's what a migration should do—bring your old settings with you. But 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. This is because when using this method 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.

Back to top

Printer-Friendly Version









Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home