A session summary from the Microsoft Exchange Planning Workshop heldSeptember 19-21, 1995, in Bellevue, Washington.
(These notes are taken directly from the presentation given by J. Craig Fletcher, Staff Architect at Microsoft, during the Microsoft® Exchange Planning Workshop.)
The Infrastructure Technologies group, a division of the Information Technologies group (ITG), defines the data/voice/video network model and communications infrastructure for Microsoft. This group is responsible for architectural planning, research, and standard use definition. Group members work with the Operations Engineering group to define implementation strategies, and they complete the implementation. In this capacity the Infrastructure Technologies group provides a final escalation point for problem isolation, resolution, and feedback.Implementation Approach
Microsoft's Infrastructure Technologies group began the implementation process by reviewing early product specifications, making recommendations to the product team, and staying abreast of changes to the product as it matured.
The group worked with the initial test release versions to begin validation of the decisions that had been made regarding hardware platforms, administrative models, directory services, and message routing.
The research entailed establishing message volume capacity requirements, directory modification models, and administrative support scenarios. Using WAN simulators, group members built a sample enterprise in their lab and evaluated various site models to optimize message throughput and minimize administrative overhead.
Wide-scale deployment of the Beta 2 release is now enabling validation of these strategies.Roll-out Plans
The Infrastructure Technologies group has been working with the Microsoft BackOffice™ group for over 18 months. The first steps included thoroughly reviewing the system specifications, performing initial modeling on the first test releases, providing feedback to the product group to ensure that the product scales to globally distributed enterprise environments, and then committing to system platform choices.
The current implementation is scaling as the product matures. The number of end users hosted on Microsoft Exchange Server as their electronic messaging platform is increasing with the introduction of newer versions that provide increasing functionality and stability. In this respect Microsoft's internal use will differ from the majority of its customers, because any product limitations are being addressed during development to ensure that Microsoft Exchange Server meets large enterprise needs prior to release.
An additional difference is that Microsoft had to commit to a hardware platform choice early to facilitate introduction of the product internally on a global basis prior to release. The logistics involved in procuring, deploying, and installing new hardware in 120 sites are challenging and time consuming. This dictated that a hardware platform decision be made early in the development phase.
The "real" deployment follows three phases, aligned with major product milestones. The first phase has been completed. It has confirmed Microsoft's ability to install local and remote servers, move users to the new environment, successfully manage the Microsoft Exchange Server computers, synchronize directories between the legacy system and the new system, and, finally, route messages between both environments.
The original goal was to host 1000 users on Microsoft Exchange Server. However, this target was substantially exceeded, with more than 2500 users using Microsoft Exchange Server as their production mail system. This included 800 Messaging Product Unit users hosted on servers that tracked incremental builds, 800 Windows® 95 client users hosted on MS® Mail postoffices routed through the MS Mail Connector, and 1000 Windows® for Workgroups, Windows 95, and Windows NT® users hosted on "production" Microsoft Exchange Server computers.
The second phase will stress the communication capabilities of the product and validate the domain, site, and administrative models. The original target for this phase was not a maximum number of users. Instead, Microsoft looked at areas where the greatest communication challenges might exist and then planned to extend the system to those locations. These areas included slow network links, asynchronous links, and multinational client interaction. However, with the success of the initial phase, the scope of Phase 2 has been substantially extended from 2500 users at 10 sites to 7500 users at 35 sites.
The third phase will be complete global implementation of the product, fully replacing the existing messaging backbone. Aggressive goals have been targeted so that, ideally, complete conversion of the entire company will be completed within 90 days of the final release candidate.Research Team
The considerable logistical challenges in achieving Phase 3 require communication of objectives, time frames, and schedules to numerous groups on a global basis. Upon achieving Phase 3, three groups will have been directly involved in the migration from the existing legacy transport to Microsoft Exchange Server.
The first group consists of six individuals dedicated to analyzing the product specifications, testing administrative and site strategies, and devising an overall implementation strategy. They will have been solely focused on this project for approximately two years. This is atypical of the majority of customers, as the group was working through all issues during the definition of the product specifications and development of the actual system. This group probably would have taken four to six months to fulfill their responsibilities with a "finished" product.
The second group consists of an additional 14 non-dedicated individuals. These people will be responsible for on-site installation of Microsoft Exchange Server computers and are generally involved for one to two months.
The third group will be the long-term staff necessary for 7x24 (7 days a week, 24 hours a day) centrally managed coverage. The Microsoft Exchange Server administration group will require approximately 20 individuals dedicated to the management of the servers, directory services, and public folders provided by the system.Integration Plans
Microsoft Exchange Server presents the opportunity to fulfill a long-term goal—to provide access to multiple, disparate message types through a common interface.
Microsoft has been working with third parties to extend the capabilities of the system to support access to voice, fax, and video through the new graphical client. The company has also been working with third parties to provide for "richer" retrieval options when out of the office through things such as "fax back" of any object in the inbox, or voice retrieval of not only voice but also e-mail and fax.
Microsoft is also redefining its internal BBS systems to be based on public folders. Public folders will provide greater general access and reduced administration overall. Plus, end users will then have one common access method for all messaging and information sources.
In addition, a number of work-flow applications, such as applications for procurement and secure distribution list management, are being built around the forms technology.Migration Considerations
For Microsoft, migration to Microsoft Exchange Server involves many issues that may be familiar to most large enterprises. Although Microsoft has the luxury of coming from a substantially homogenous environment, the introduction of a new transport poses challenges from both a management standpoint and an end-user support perspective. New features demand rethinking of long-used conventions in certain cases. Also, the pace at which end users can successfully adapt to a new system must be appreciated.
The transport used predominantly at Microsoft today is proprietary in nature; therefore, cumbersome gateways were initially needed while the Infrastructure Technology group worked on cleaner support for the Microsoft Exchange Server Internet Mail Connector. Directory synchronization between the two systems had to be resolved so that a consistent set of user addresses and distribution lists is available to all internal mail users.
The impact of public folders is also being explored. Microsoft has very little operational experience with this type of environment, having only reviewed Lotus Notes® when version 2 was initially released. Public folders present a tremendous opportunity to provide information sharing and distribution; they also pose new management considerations regarding resource management.Microsoft Exchange Server Topology Considerations
When planning for Microsoft Exchange Server, it is important to begin with a thorough understanding of the enterprise network and systems management structure. Identify the locations in which the company has offices, what type of connectivity exists between the offices, and where information technology administration exists.
If a Windows NT Server domain architecture does not yet exist, you must first consider this. The domain strategy must be robust and capable of supporting the Microsoft Exchange Server site architecture. While the two can be devised concurrently, they must both be given due consideration. It will be difficult to make serious changes to either without significant effort and possible service interruptions.
When determining the Windows NT Server domain and Microsoft Exchange Server site strategies, consider the underlying network, bandwidth, protocols, network costs, and traffic patterns. This can help you decide where to set site boundaries and when to use site connectors versus X.400 connectors.Windows NT Server Domain Topology
The Windows NT Server domain strategy at Microsoft is based on multiple master user domains (MUDs) that have trust relationships. All user accounts are located in the MUDs. The MUDs are proximate to the user community being served and allow for locally granular administrative privileges.
Under the MUDs are located one or more business unit domains (BUDs) that trust one of the first-tier domains. The BUDs are resource domains where SQL servers, print servers, and file servers are located.
In addition, a special domain that is global in nature has been defined in the second tier. All Microsoft Exchange Server computers will be located here to make it easy to identify messaging servers and to provide for consistently applied "global groups" to make server management easier.Microsoft Exchange Server Site Topology
The Microsoft Exchange Server site topology is configured to reflect the connectivity between regions and sites within a region. It also reflects the distribution of support responsibilities at Microsoft. Microsoft has attempted to minimize the number of sites, while at the same time providing a way to manage bandwidth consumption over dedicated links and enabling regional support of the system.
Microsoft has a highly centralized administrative model, which dictates certain choices with regard to management of the system. Planning for sites requires that the number of users and resultant server demands be determined. Sites provide for greater control over message routing and directory synchronization. However, this benefit should be weighed against the cost of managing many site connectors and "remote" directories.Naming Conventions
Naming conventions are another important consideration. There is no way to change an enterprise name, domain name, site name, or server name without rebuilding servers. This is one reason to start with fewer rather than more domains/sites—it is substantially easier to "split" than "merge."
Likewise, be sure to consider user login IDs. If your messaging system is tied to human resource or other internal systems, you must recognize the limitations imposed by the existing systems and adapt your model to reflect these.
Site and server names should reflect generally static information that is not likely to change over time. Avoid using departmental names that change frequently. Instead, try using names that are not likely to change as often, such as names based on geographic regions. Consistent application of names makes it easier to use and manage the system.Hardware
For Microsoft to achieve the migration to Microsoft Exchange Server in the time frames set out, it was necessary to determine the hardware requirements and deploy the hardware globally.
Microsoft's implementation is based on leveraging the central store. This provides the greatest benefit to LAN-based and traveling users. It takes advantage of the single-object/multipointer message store and allows for definition of a universal inbox. Microsoft Exchange Server provides for 50 MB of central store space per user. For users who require offline access to folders or archival of dated information, it is a simple matter of dragging items into the personal store before departing.
Microsoft's server configuration is high end; this decision was made to provide a viable platform for growth as well as a high level of support from local vendors. Three standard configurations were adopted to ease troubleshooting and ensure a high level of operational capability:
Microsoft has invested greatly in the planning phases of the eventual global deployment of Microsoft Exchange Server. Not only has this investment paid off in a successful roll-out of the Phase 1 plans, but it also has contributed many improvements to the product. Microsoft's goal is to complete the deployment within 90 days of the final Microsoft Exchange Server release candidate.
The descriptions of other companies' products in this document are provided only as a convenience to the reader. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult the respective manufacturers.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, this document should not be interpreted as a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of this publication.
This document is for informational purposes only and is subject to change without notice. Microsoft makes no warranties, express or implied, in this document.
©1995 Microsoft Corporation. All rights reserved. Microsoft, MS, and Windows are registered trademarks and BackOffice and Windows NT are trademarks of Microsoft Corporation.
Pentium is a registered trademark of Intel Corporation.
Lotus Notes is a registered trademark of Lotus Development Corporation.