1.2 Exchange second generation

---

After four years, the original Exchange architecture was beginning to show some flaws. Design decisions reached in 1993-1995 did not match the world of 1997-1999, and the experience gained of running Exchange in production revealed the need to make a number of changes at the core. In addition, the work to develop the next generation of Windows NT was finally ending with the release of Windows 2000. Among the most important flaws that Microsoft had to address were:

• Implementing a single large database for mailboxes imposes a scalability limit. Few companies were willing to put more than 3,000 mailboxes on a server because of the impact on users if the database experienced any hardware or software problems.

• The Exchange 5.5 clustering solution is weak and expensive. Microsoft needed to move to active-active clustering, which allowed Exchange to use all of the hardware in the cluster as well as the ability to have more than two nodes in a cluster.

• The Message Transfer Agent (MTA) provides message routing functionality for the first-generation Exchange servers. Microsoft originally purchased the MTA code from a small U.K. company, and, although the Exchange developers extensively modified and enhanced the code over the years, its roots meant the code base was complex and difficult to update and maintain. The MTA uses the X.400 protocol, but the world of messaging now largely uses the SMTP Internet protocol. In addition, the MTA is relatively inflexible in the way that it makes routing decisions and is therefore not very resistant to changes that can occur in a dynamic environment.

• The Exchange 5.5 administrative model works superbly for small installations but is not flexible enough for large, distributed enterprises. The administration tools were developed with small servers in mind and do not work well for larger systems.

• The first-generation OWA architecture uses Active Server Pages and does not scale to take advantage of new hardware. In addition, the first-generation OWA client is very restricted in comparison to other clients.

• Exchange 5.5 has its own directory, an acceptable solution when the operating system does not incorporate a directory service. Windows 2000 and Windows 2003 leverage the Active Directory, and it makes sense for applications to exploit a common directory whenever possible.

Many companies used the same list of reasons to justify the migration to Exchange 2000, including:

• The reduction of cost that can be achieved by operating fewer servers: The experience of real-life migration projects such as HP's proves that you can consolidate Exchange 5.5 servers to a smaller set of Exchange 2000 servers, and then consolidate further when you introduce Exchange 2003.

• The availability of more comprehensive administrative tools such as Microsoft Operations Manager (MOM).

• A need to build more robustness into operational procedures by exploiting partitioned databases.

• The fact that Microsoft is pouring its development effort into the current and next generations of Exchange and therefore pays little attention to fixing anything for Exchange 5.5.

Although Exchange 5.5 is a very fine messaging system, which works well on Windows 2000, the overall feeling is that it was time to move on. Microsoft launched Exchange 2000, the first release in the second generation of Exchange, in September 2000. Microsoft certainly accomplished the jump from first to second generation but achieved mixed success: The new version of OWA proved to be hugely popular and delivered the necessary combination of features, robustness, and scalability to make browsers more than a viable client platform for large user communities. On the other hand, the Store had encountered many problems with memory fragmentation and other issues in active-active clustering, and Exchange clusters are not yet a compelling solution for companies that seek the highest possible level of reliability and availability. Jettisoning Exchange's own directory in favor of the Active Directory also posed problems, and the management tools were not as smooth as they could have been. Service packs delivered since have improved matters, especially around the interaction between Exchange and the Active Directory, but companies that deployed Exchange 2000 early also had to cope with a large number of hot fixes, as Microsoft sometimes rushed to deal with the challenges posed by making so many fundamental changes in the underlying technology.

Looking back, we should not have been surprised at the problems that Microsoft had to solve. Exchange 4.0 was not perfect either, and it took two releases (to Exchange 5.5) before the first generation of Exchange really bedded in and became a solid enterprise-class messaging system. Exchange 2000 built on the achievements of Exchange 5.5, and there were many examples where companies successfully deployed Exchange 2000 well before the release of service pack 2. It can be argued that the people who encountered problems were those who attempted to probe the edge of the envelope by overstressing clusters; partitioning the Store to the utmost degree; or implementing on top of an unstable and underprepared Windows 2000 infrastructure; and there's no doubt that all of these situations occurred.

Microsoft Exchange Server 2003, codenamed "Titanium,"^[1] is the most functional and powerful version of Exchange built to date, even if Microsoft has stripped out some of the collaboration and application development features found in Exchange 2000. Exchange 2003 enjoys all of the advantages of development based on customer feedback from actual Exchange 2000 deployments. The changes and improvements made to Windows have also assisted Exchange 2003 greatly-the world of Windows has not stayed static since Microsoft released Windows 2000 in 1999, and it is easier to build and deploy a stable infrastructure today. The personal touch cannot be overlooked either. Quite a number of system administrators were a little overwhelmed at the knowledge upgrade required to cope with Windows 2000, Exchange 2000, and new hardware advances that appeared around the same time. It is difficult for administrators to move seamlessly from a Windows NT 4.0/Exchange 5.5 environment to Windows 2000/Exchange 2000 while also focusing on domain redesign, potentially upgrading other applications, server consolidation, and the introduction of technologies such as Storage Area Networks and clusters. Early movers enjoy the benefits of new technology first, but it is a double-edged sword. Those who waited, maybe even to follow the well-aged adage of always waiting for the second version of a Microsoft product, can follow on now to move into the second generation on a solid platform of improved software, better hardware, and a vast amount of experience.

1.2.1 Titanium

Exchange 2003 builds on Exchange 2000 and uses the same architectural underpinnings, so in many ways you can look at Exchange 2003 as an upgrade similar to the move from Exchange 5.0 to Exchange 5.5. It can coexist with both Exchange 5.5 and Exchange 2000 to allow customers to introduce Exchange 2003 easily into current organizations. However, you can only upgrade an Exchange 2000 server to Exchange 2003, so if you still run Exchange 5.5, you must go through an upgrade to Exchange 2000 first. In addition, the Exchange 2000 servers must be running SP3 (or later), and the operating system must be at Windows 2000 SP3 (or later) or Windows 2003 before you can perform an in-place upgrade from Exchange 2000 to Exchange 2003. You should also upgrade any servers that host the Active Directory Connector (ADC) to the version of the ADC provided with Exchange 2003 before beginning any in-place upgrades. Finally, you must upgrade any front-end servers to Exchange 2003 before you upgrade any back-end servers. As with all architectural upgrades, planning is critical and it is important to sequence change in the right order.

You can run Exchange 2003 on Windows 2000 (SP3 or greater) or Windows 2003 (but not the Web server edition of Windows 2003). The latter is preferred because of IIS 6.0, which is more robust and secure and has better memory management than its predecessor. As with Exchange 2000, if you want to use the Enterprise version of Exchange, you need to deploy the Enterprise version of Windows. You can use the Datacenter version of Windows if you want to run four-way clusters on Exchange 2000, but you only need the Enterprise edition of Windows 2003 to support up to eight-way Exchange 2003 clusters, a change that may provoke renewed interest in clusters as server consolidation cranks up the number of mailboxes supported by servers. Aside from the sheer cost, relatively few companies deployed Windows Datacenter to support Exchange 2000 four-way clusters, because it is possible to achieve the necessary degree of uptime for email systems with either standard servers or smaller clusters, provided you manage the systems correctly and pay attention to detail. As is always the case, no amount of expensive hardware can compensate for inadequate management (systems or otherwise).

Differences still exist between the standard and enterprise editions of Exchange that deserve discussion. The enterprise edition is slightly more expensive, but it is the most suitable for enterprise deployments because it supports database partitioning, clustering, and includes the X.400 connector. These features are important when you want to support thousands of mailboxes on a server or want to build large datacenters, but they are less important when you only need to support a few hundred users and the standard edition suffices. In a change from Exchange 2000, you can use the standard edition in front-end/back-end configurations.

Exchange 2003 focuses on messaging above all, so Microsoft's incursions into the world of extended collaboration services comes to a grinding halt with the exclusion of Instant Messaging (IM), Chat, and Conferencing Services (think of a server-based version of NetMeeting), all extensions of Exchange 2000. You can upgrade an Exchange 2000 server that hosts the Chat and Conferencing components and they continue working, but you should consider how you want to use these components in the future and whether you should replace them now. However, you must remove IM (and KMS) from an Exchange 2000 server before you can upgrade it to Exchange 2003. Microsoft has replaced the Exchange 2000 version of IM with their Microsoft Office Live Communications Server, but does not now explicitly link instant messaging with Exchange.

You do not have to upgrade domain controllers and Global Catalog servers to Windows 2003 before you can begin to deploy Exchange 2003, providing that these servers run Windows 2000 SP3 or later. However, you can gain some advantages by upgrading the controllers used by Exchange 2003 to Windows 2003, including support for MAPI RPC transmission over HTTP (this feature requires Outlook 2003 clients) and improved replication of large distribution groups. The benefits of the upgrade include reductions in network traffic for Active Directory replication and a reduced load on Exchange servers.

Apart from IIS, Microsoft has integrated Exchange 2003 more tightly with other Microsoft server products. For example, the Exchange management pack for Microsoft Operations Manager, which used to be an optional extra, is now included in the base product. This may entice some extra customer interest in Microsoft's management framework over competing offerings such as NetIQ AppManager. Features such as RPC over HTTP can exploit the tighter integration between Exchange and Microsoft Internet Security and Acceleration Server^[2] (ISA), where its Web Publishing wizard recognizes and supports the need to secure Exchange communications.

1.2.2 Microsoft support policy

Losing support is a terrifying prospect for any IT manager. It is also a prompt that maybe it is time to move forward and install a new version of software. Microsoft's support policy sets clear deadlines regarding when you can expect to have support for older versions of Exchange and Outlook and so helps set timelines for when you need to have work done to prepare for a migration.

The basic policy is as follows:

• Microsoft provides mainstream support for products during the first five years of their life.

• For two years after mainstream support ends, companies can buy extended support. This offer only applies for business and development software, which includes Exchange. You can also pay Microsoft PSS for individual support incidents if you prefer not to buy a contract.

• Online support (the Microsoft Knowledge Base) is available for at least eight years after a product's initial release.

To put this policy in context, Microsoft released Exchange 5.5 in November 1997. Therefore, if Microsoft implemented the policy as written, mainstream support for Exchange 5.5 would finish at the end of 2003 (five years and a month after first release). However, because the normal approach for a migration from Exchange 5.5 is to move first to Windows 2000 and implement the the Active Directory, the process tends to be extended. Customers have been slow to move and a 2003 deadline would be unacceptable to many. Microsoft therefore extended the deadline to December 31, 2004 and aligned the end of support with that for Windows NT 4.0. You will have to pay Microsoft to extend support if you want to continue using Exchange 5.5 after this date. Even so, the writing is on the wall and the lifetime of Exchange 5.5 has an endpoint that is very visible now. Mainstream support for Exchange 2000 lasts through 2006 and extended support through 2008. Figure 1.1 illustrates the timeline from the launch of Exchange 4.0 through a finger-in-the-air prediction when the third generation of Exchange might appear.

Figure 1.1: Exchange and Windows timelines.

There are several examples of companies that have not upgraded older Exchange servers to even Exchange 5.5. For example, some of the companies that tested beta releases of Exchange 2003 operated Exchange 4.0 SP2 and Exchange 5.0 SP1 servers. The good news is that everything works, because Exchange 2003 maintains backward compatibility through MAPI (for interserver communications in a mixed-mode site) and SMTP and X.400 (for general messaging). The caveat here is that Microsoft does not formally test the combination of Exchange 2003 with servers earlier than Exchange 5.5 SP3, so obtaining support may be an issue if you run into problems.

In addition to software upgrades, Microsoft asks customers to install the latest service pack for any product as soon as their deployment schedules allow and often provides "encouragement" by declining to address support issues unless you encounter the problem with the latest service pack. The formal statement is that Microsoft supports the current service pack and the preceding service pack. Sometimes a good Microsoft Technical Account Manager (TAM) can help get support for earlier service packs, but it is generally a good idea to deploy service packs as soon as you have tested them for compatibility with your production environment.

Of course, you need to consider more than just Exchange and look at the version of the operating system you run, third-party products, client software, and so on to build a complete matrix of your support exposure and requirements. For example, Outlook 2000 has mainstream support until June 30, 2004.

1.2.3 Supporting Windows

Some confusion exists as to the version of Windows you have to deploy to be able to run Exchange 2000 or Exchange 2003. The situation is simple even if the reasons are not:

• Exchange 2000 only runs on a Windows 2000 server (including Advanced Server and Datacenter Server).

• Exchange 2003 can run on either a Windows 2000 (SP3) or Windows 2003 server.

• Exchange 2003 supports native-mode Windows 2000 and Windows 2003 environments or mixed-mode environments that include both types of servers.

• Exchange 2003 requires domain controllers and Global Catalog servers to run Windows 2003 or Windows 2000 SP3 (or later).

Table 1.1 lists the valid combinations of Windows and Exchange. See Microsoft Knowledge Base article 321648 for more information about the product support matrix and to obtain information about specific requirements. For example, because Exchange 2003 requires secure LDAP, you can only run Exchange 2003 on a Windows 2000 server that you upgrade to SP3 or better.

Table 1.1: Exchange and Windows Support Matrix

Exchange/OS	NT 4.0	Windows 2000	Windows 2000 in Windows 2003	Windows 2003
Exchange 5.5 SP3	Yes	Yes	Yes	No
Exchange 2000 SP1	No	Yes	Yes	No
Exchange 2000 SP2-SP3	No	Yes	Yes	No
Exchange 2003	No	Yes	Yes	Yes

The reasons why you cannot run Exchange 2000 on Windows 2003 are complicated. Exchange and Windows have very close connections at many points, including the Active Directory, IIS, DNS, as well as the protocols and virtual servers enabled by IIS, including SMTP, HTTP, and IMAP. Microsoft could have done the work to make Exchange 2000 operate on Windows 2003, but many of the required changes would have been architectural in nature and not appropriate for a service pack, which is what it would have released (because Exchange 2003 is also available). For example, the Exchange 2003 installation procedure is able to lock down IIS 6.0 in a mode that still allows Exchange to serve dynamic data for Outlook Web Access. Because of the huge differences between IIS 5.0 and IIS 6.0, Microsoft would have had to do a lot of work to upgrade the Exchange 2000 installation procedure to handle IIS 6.0, and, even then, it would have only done half the work. Accordingly, Microsoft made the decision to restrict Exchange 2000 to Windows 2000. Perhaps it is also taking the opportunity of making the subliminal point that the best combination is now Exchange 2003 running on Windows 2003. This is probably true, but it will take people a little while to get there, since an operating system upgrade is not something that everyone eagerly anticipates.

However, while you cannot install Exchange 2000 on a Windows 2003 server, you can run Exchange 2000 in an environment where you have deployed Windows 2003. For example, you can upgrade domain controllers and Global Catalog servers to take advantage of the improvements in Active Directory and continue to run applications such as Exchange, SQL, and file and print services on Windows 2000 servers. In much the same way, you can continue to run Exchange 5.5 servers on either Windows 2000 or Windows NT 4.0 inside a Windows 2003 environment while you prepare for and then execute the migration. In all cases, if you decide to deploy Exchange on Windows 2000, make sure that you install the latest service pack first, along with any security patches or other hot fixes recommended by Microsoft. In addition, deploy the same base level of the operating system everywhere to make support easier.

^[1] Titanium follows on from Platinum, the code name for Exchange 2000, and Osmium, the code name for Exchange 5.5.

^[2] You need Feature Pack 1 (or later) for ISA. See www.microsoft.com/isaserver.

---