Exchange 5.5 left a lot to be desired when it came to enterprise deployments. It was a fantastic product in small and medium-size companies and for collaboration at the department level, but often had shortcomings in more
Detailing design limitations in Exchange 5.5
Exchange 5.5 environments generally followed a distributed deployment model in which Exchange servers were placed in each remote location that had more than 20–30 users. This was especially true for organizations that were deployed in early Exchange deployments and was due to several factors in how the product was architected and the inability of clients to reliably connect across remote network links. In addition to this limitation, Exchange 5.5 also had other architectural shortcomings that were addressed in Exchange Server 2003.
Combined administration and routing
Exchange 5.5 tied the hands of messaging architects by limiting Exchange designs around the site boundary. The Site in Exchange 5.5 was the boundary for administration as well as message routing. Exchange 5.5 directory replication occurs every 15 minutes within an Exchange site, and every server in a site communicates with every other server in that site. Messages also route within a site directly from the source to the destination server. Unless bandwidth was unlimited in the organization, architects had to draw site boundaries to control message routing and directory replication. Many organizations that chose a single-site design paid the price with frequent RPC message timeouts and eventually switched to a multisite design. Because message routing and administration are linked, a distributed administration model was automatically created that was an additional headache. Windows NT 4.0 didn't do a good job of providing granular administration. Anyone with administrative rights in the domain could add himself to the global group that was assigned rights in the Exchange Administrator program. This really meant that distributed message routing and centralized administration just was not possible if someone in the remote office needed to manage the Exchange server.
Lack of scalability
In Exchange 5.5 environments, scalability was usually a cap that was set based on the size of the mail and public folder server database size or the number of users supported per server. When the cap was reached, users were moved from one server to another. Mailbox limits could vary widely between organizations, from a conservative 500 users to a less conservative number of about 2,500. Many organizations capped the database size or number of users per server due to the 16GB mail and public folder store limitation of the standard edition of the Exchange Server software. Even after the limitation was removed in the enterprise edition, organizations were limited in the size of the database by the amount of time offline maintenance, backup, and restore operations took on the server. The cap was then set based on the organization's comfort level with the risk of losing the server and the amount of recovery time to get a failed server operational. Many organizations found that when they began to exceed about 30GB, the store became unmanageable.
Small degree of redundancy
In most Exchange 5.5 deployments, mail servers were distributed to locations that had more than 20–30 users, an arbitrary number of users that was selected on the size and availability of WAN bandwidth, whether backup links existed, and the organization's comfort with the level of risk. This was due to the desire to provide a decent level of performance with the capability to keep mail services running in the remote location online in case of WAN failure. Redundancy was also provided through the use of multiple connector servers for foreign mail, SMTP, and OWA. Having multiple connector servers allowed one connector server to fail or have a fault; another connector server would be available to service messaging routing needs.
In corporate locations, stability was achieved by keeping databases small and by separating public folders and message-routing services from mail-message services. Distributed services came in the form of dedicated public folder servers and connector servers such as cc:Mail connector servers, Outlook Web Access servers, and SMTP bridgehead servers for Internet Mail.
How Exchange Server 2003 addresses Exchange 5.5 shortcomings
Exchange Server 2003 provides the features necessary to build a more robust messaging environment. It removes many of the boundaries that tied the hands of architects and administrators in Exchange 5.5. As Exchange Server 2003 matures, the messaging designs continue to centralize, with only a portion of the services still being distributed. Exchange Server 2003 improves upon the shortcomings of Exchange 5.5 in the following ways:
- Separate administration and routing In Exchange Server 2003, separate routing and administration can be achieved through the creation of Routing and Administrative Groups. To fully use these new containers, the organization must be converted to Native Mode Exchange Server 2003. This requires all Exchange 5.5 servers to be converted to Exchange Server 2003 or be uninstalled from the organization. The combination of Administrative and Routing Groups with the granular permission of Active Directory helps messaging administrators better control access to the messaging services in the organization.
- Increased degree of scalability Scalability is provided in multiple mail and public folder databases that can be used to keep the database performance high while keeping backup and restore times low. This means that the number of users supported per server can be increased, reducing the number of servers on the network. Each database can be mounted and dismounted individually, allowing the server to continue to function even when some databases are offline.
- Improved redundancy Redundancy in Exchange Server 2003 is provided through full support of the Microsoft Cluster Service (MCS). Connectors in Exchange Server 2003 can also be redundant. By using SMTP for message delivery and a link-state routing algorithm, message-routing designs can be built to route messages efficiently and to take advantage of redundant links on the WAN.
- Enhanced stability Stability is provided within the Windows Server 2003 operating system and at the core of Exchange Server 2003 in the Extensible Storage Environment (ESE) database. Small efficient databases, redundant connector designs, and clustering technology all increase the stability of Exchange Server 2003, improving the end-user experience and letting information technology groups create service level agreements that they can stand by.
Migrating from Exchange Server 5.5 to 2003 -- 11 tips in 11 minutes
Tip 1: Comparing Microsoft Exchange Server 5.5 and 2003
Tip 2: Prerequisites for migrating to Exchange Server 2003
Tip 3: Structuring an Exchange Server migration for the best results
Tip 4: Preparing the Active Directory forest and domain for Exchange 2003
Tip 5: Installing and configuring the Active Directory Connector
Tip 6: Installing the first Exchange Server 2003 system in an Exchange 5.5 site
Tip 7: Understanding Exchange Server 2003 mailbox migration methods
Tip 8: Migrating Exchange Server 5.5 public folders to Exchange 2003
Tip 9: Migrating Exchange 5.5 connectors and services to Exchange 2003
Tip 10: Completing the migration to Exchange Server 2003
Tip 11: Best practices for migrating from Exchange Server 5.5 to 2003
This chapter excerpt from Microsoft Exchange Server 2003 Unleashed, by Rand Morimoto, is printed with permission from Pearson Education, Copyright 2005. Click here for the chapter download or purchase the book here.