|< Day Day Up >|| |
Microsoft delivered the first generation of Exchange in March 1996 as Exchange 4.0, and it is still running on many servers as Exchange 5.5, suitably equipped with the latest service pack. You can characterize the first generation of servers through the use of proprietary technology and protocols. The Exchange 4.0 to 5.5 products were part of Microsoft's push into the enterprise application market. While SQL/Server showed signs of being a player in the database market, it still had not made the grade in 1996, and Exchange 4.0 was Microsoft's first enterprise application that truly achieved widespread deployment.
By one measure, Exchange 4.0 was extraordinarily late in shipping, as it debuted some 39 months after Microsoft's original date. Building an enterprise application is always difficult, but there were two special reasons that Exchange was more difficult than the average enterprise application. First, Exchange was the first Microsoft application to make extensive demands on the operating system. Up to then, Windows NT essentially hosted stand-alone applications, where computers served single purposes such as database servers or file and print servers. Exchange upped the ante and demanded that system administrators and designers begin to think about their Windows NT deployments as a single integrated whole rather than islands of separate applications. The concept of a single Exchange organization that spanned the complete company caused many administrators to look at how they dealt with Windows NT. Exchange also exposed some weaknesses in Windows NT: The security model was not very good and forced the creation of resource domains to hold Exchange servers and restrict administrative access.
The second reason why Exchange was a difficult application to develop was Microsoft's desire to be all things to all people. The messaging world in 1993-1995 (the time when much of the design work for Exchange was completed) was a very fractured entity. It was a multiprotocol proprietary world, where most major corporations ran multiple messaging systems that could not communicate very well. In fact, getting simple text messages to travel from one system to another was often a matter for celebration. Corporations allowed departments to select different email systems for many reasons. Perhaps the department was running a specific operating system such as OpenVMS or UNIX and had to select an email system that supported that platform. Perhaps the department built an underground email system that the corporate managers didn't know of by installing PCs that ran Microsoft Mail, Banyan VINES, or Lotus cc:Mail to serve small user communities. Or perhaps a salesperson had simply done a good job of selling a specific email system to a department for some reason or another. In any case, it was usual to find global corporations struggling to cope with how to make 10 or even 20 different email systems interoperate together. X.400 was the only viable way to connect disparate email systems together, and while X.500 promised great things for unified corporate directories, it had largely failed to make an impact.
Microsoft's problem was that it had to sell Exchange to the people who ran different email systems. The Exchange team had to provide a way to interoperate with the existing system during the migration period; they had to provide tools to migrate user accounts and mailboxes; and they had to support the favorite features found in the various systems, because customers would not buy Exchange if they ended up with reduced functionality. It is enlightening to read some of the original Exchange design documents and to chart how the product features accumulated over time. The result was a highly functional email system, which could interoperate with many other email systems, but Exchange certainly took time to build and even longer to debug.
As it turned out, being so late enabled Microsoft to take advantage of greater maturity in both hardware and the Windows NT operating system. It is interesting to speculate what would have happened had an immature Exchange product been rushed out to meet an arbitrary date and had to cope with the type of hardware and software environments that were available in 1994-1995. Even with the delay, companies deployed the first Exchange servers on early Pentium-powered systems running at 50 or 66 MHz and equipped with 64 MB of memory and perhaps 3 to 4 GB of disk. Windows NT 3.51 provided the platform. The early servers supported user populations of up to 200 mailboxes and provided a way for Microsoft to begin the migration of its existing Microsoft Mail population over to a new architecture.
Migrating users off Microsoft Mail was an important influence on Exchange 4.0, largely because it provided a solid user base that could be trumpeted in the marketing war between Microsoft and Lotus, who rapidly became the big two candidates for enterprise messaging deployments. Lotus had the early advantage, because Lotus Notes had been in the market far earlier and had already built a substantial user base, so it was important for Exchange to gain traction and build a user community.
Exchange 5.0 followed in October 1996 and served as a patch-up release. The final rush to get Exchange 4.0 out the door had left some components with known defects and these had to be addressed. In addition, Microsoft had started to get serious about the Internet and had realized the impact that the Internet would have on messaging, so Exchange 5.0 marked the first real integration of SMTP into the product. For many experienced Microsoft observers, the release of Exchange 5.0 served notice that Exchange was ready to deploy-no one would ever deploy the first version of a Microsoft application unless it was necessary, so the number of installations began to creep up from what had been a slow start. While suspicion about the reliability and robustness of Exchange 4.0 had been a contributory factor in slowing down deployments, the need to pay some attention to the Windows NT structure, to build a migration strategy, and to get used to the new application were other reasons why Exchange had a slow start. Microsoft reached 1 million mailboxes after about eight months, and then things took off to a point where customers deployed a million new mailboxes every month from mid-1997 onward.
Exchange 5.0 continued to ship an improved version of the Capone client, which the development team had built and included in Exchange 4.0. This client was designed as a simple email processor-create, send, forward, reply, and print messages. The separate Schedule+ application delivered nonintegrated calendaring, and there was no evidence of other Personal Information Manager (PIM) features such as contacts, notes, and the journal. Outlook, part of the Microsoft Office personal application suite, first appeared in 1997 to take over as the basic client for Exchange and deliver the missing PIM features. The first version of Outlook did not perform as well as the Exchange client and suffered from the same type of feature bloat as the other Office applications, a trend that has continued to this day.
The first version of Outlook Web Access (OWA) also appeared with Exchange 5.0. As we will discuss later, the concept of a Web-based client is very attractive to anyone who has to deploy and support thousands of clients. The original architecture worked, but OWA was not very scalable and missed many features when compared with Outlook. Despite this, OWA has been popular with customers from day one and it continues to grow in popularity today.
Exchange 5.5 arrived in November 1997. Microsoft integrated a full suite of Internet protocols (POP3, IMAP4, HTTP, SMTP, and NNTP) along with connectors for Lotus Notes, IBM PROFS, and IBM SNADS to aid migration from these systems. The connectors were the result of the purchase of LinkAge, a Canadian company, in May 1997. Exchange 5.5 lifted the 16-GB restriction on the size of the Information Store database and was the first version to support Microsoft Cluster Services in an active-passive two-node configuration. Unfortunately, clustering was an expensive solution that did not really deliver the functionality and reliability that many companies required, so it never really took off. Indeed, the pace of development in hardware enabled Exchange to support thousands of mailboxes on multi-CPU servers, so companies were able to compare the costs of dividing user communities across a set of highly specified servers against clusters, and most chose to go with individual servers.
Exchange 5.5 marked the final play in the first generation. Microsoft steadily improved the software through service packs and Exchange 5.5 is able to run very nicely on Windows 2000, a fact that has caused many companies to delay their migration to the second generation of Exchange. The cost to upgrade an existing Windows NT infrastructure to Windows 2000 or Windows 2003 and do all the redesign and architecture work to build a new Windows infrastructure has slowed migration projects. Some analysts estimate that 70 percent of Exchange's installed base still ran Exchange 5.5 in early 2003, meaning that the vast majority of Exchange 2000 deployments were new implementations and that relatively few large organizations had migrated to Exchange 2000. As with any number-counting exercise, it is hard to know quite how accurate these estimations are. However, given the millions of Exchange seats in production, we can predicate that Exchange 5.5 servers will be running in production for a number of years yet, possibly well past the time when Microsoft ceases to provide formal support.
|< Day Day Up >|| |