An important aspect of premigration Exchange 2000 planning involves taking a look at how Exchange servers fit into the topology of your enterprise network. You need to consider their placement and roles prior to upgrading from Exchange 5.5. During this planning phase, you should:

  • Consider collapsing existing 5.5 sites before the upgrade.
  • Verify connector support and assess placement of bridgehead servers.
  • Determine which Routing Groups to place servers in.
  • Decide whether to use Outlook Web Access (OWA).
Carol Bailey’s series on Exchange 2000 planning

Consider collapsing existing 5.5 sites before the upgrade
Exchange 5.5 (and earlier) “sites” are replaced with Administrative Groups and Routing Groups in Exchange 2000, which means you can effectively split the server configuration from the connector configuration. This gives you a certain amount of added flexibility because when all your servers are upgraded to Exchange 2000, you can switch to Exchange 2000 Native mode and then drag and drop all Routing Groups into a new Administrative Group. Typically, you’d do this to delegate control of this new Administrative Group to specific users who specialize in configuring connectors only.

This flexibility of moving Routing Groups is great once you’re in Native Mode. However, you still can’t move the Servers containers (unless you uninstall the servers and reinstall them into a new Administrative Group). This means that an in-place upgrade from Exchange 5.5 to Exchange 2000 will involve a direct one-to-one relationship—a 5.5 site will become an Exchange 2000 Administrative Group.

If you want to move your servers between Administrative Groups or collapse them, it’s a good idea to do it before the upgrade because the Exchange 5.5 Move Server wizard can help you. You can get the Move Server Wizard from the Microsoft site or from the Exchange Service Pack (see  How to Obtain Move Server Wizard).

Connectors and bridgehead servers
You want to verify that your existing connectors are supported in Exchange 2000 (for example, mainframe connectors, such as SNADS and PROFS, are not). Document their configuration, because after an in-place upgrade, some reconfiguration may be required.

Familiarize yourself with Exchange 2000 connectors and their configuration abilities and suitability. In Exchange 2000, the Site Connector is replaced with the Routing Group Connector, which is the most common and easiest of the Exchange 2000 connectors to work with. It simply requires a reliable, permanent network connection, and available bandwidth is less an issue than it was with Exchange 5.5 Site Connectors. However, an SMTP Connector may be a better choice if you need messages to be encrypted with SSL or you need to queue messages until the other end requests them. This offers better bandwidth usage and control.

You should also assess bridgehead server placement. Bridgehead servers in Exchange 2000 are designated to route traffic rather than house data stores. If you’re looking to migrate to new, more powerful servers to run Exchange 2000, you might consider converting your less powerful machines into bridgehead servers.

Server placement in Routing Groups
An Exchange 2000 Routing Group is the equivalent of an Exchange 5.5 site, with peer-to-peer communication. But you need to consider whether your servers should be in the same Routing Group. Put them into the same Routing Group if communication between them will enable a permanent and reliable connection and:

  • Scheduling with other servers is not needed.
  • Restrictions on messages are not needed.
  • You have no requirement for Public Folder customization (preventing referrals).
  • There is good communication with the server designated the Routing Group Master to receive the latest link state information.

Put servers into different routing groups if you want to:

  • Control message flow (using bridgehead servers and costs).
  • Control public folder access (disable Public Folder referrals).
  • Schedule communication between servers.
  • Set user permissions at different times.
  • Send large attachments at various times.

With the factors listed above, note that WAN speeds are a lesser issue, but reliability is very important.

Decide whether to use Outlook Web Access
Outlook Web Access (OWA) offers a Web-based interface to Exchange so that users can access their e-mail remotely without having to install the full “fat client,” Microsoft Outlook. One of the nice things about OWA is that it is also suitable for non-Windows clients.

Many administrators have been offering OWA with Exchange 5.5 after installing it from the NT4 Option Pack and IIS v4. However, OWA didn’t ship with the base version of Exchange 5.5, and some administrators were not prepared to have outside HTTP access into their Exchange databases.

Now is the time to reassess whether you could benefit from OWA. It’s much improved in Exchange 2000 and comes as part of the base product. Also, IIS is a required part of Exchange 2000.

However, you should be aware that OWA lacks the following features your users may be used to with the full Outlook client:

  • Tasks
  • Journaling
  • Rules
  • Offline folders
  • Copying items between Public Folders and personal mailboxes
  • Printing templates
  • Spell checking
  • Some delivery options
  • Calendar reminders

For additional security with OWA, consider:

  • Disabling client-side Web caching (this can make OWA seem slower for users).
  • Disabling the Save Password feature if using IE5 or above.
  • Educating users to log off or close the Web browser when they have finished checking their mail.

Microsoft recommends always using SSL with OWA, so make sure that your Web server has a secure server certificate to support this. If you’re using your own internal Certificate Authority (CA), be sure that it’s in place and that users have installed the root certificate so they know to trust the server certificate source.

Summary
We’ve covered several important topology, design, and network planning issues involved in Exchange 2000 migration prep. My next article will extend this discussion by covering front-end servers, clustering, and the ports you need to open on routers and firewalls.