- Mapping the Design Components
- Evaluating Different Design Options
- Active Directory Design Details
- Defining Storage Groups and Multiple Databases
- Defining Administrative and Routing Groups
- Designing Remote Access to Exchange 2000
- Exchange 2000 Support and Maintenance Tasks
- Case Study for SmallCompany Inc.
- Case Study for MediumCompany Inc.
- Case Study for LargeCompany Inc.
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Case Study for LargeCompany Inc.
This last case study takes the scenario of a large organization that has a significant number of users, sites, administration, management, and security requirements that makes the Active Directory design and Exchange 2000 deployment requirements complex and detailed. Specific Active Directory design considerations, which have not been necessary in the two previous case studies, impact this organizational structure.
In this example, LargeCompany Inc. is the world's leading supplier of laser-based solutions. Founded in 1976, LargeCompany Inc. designs and manufactures the industry's most diversified selection of laser-based products for scientific, commercial, and research uses.
Headquartered in San Jose, California, LargeCompany Inc. has representation in more than 20 countries through a mix of direct offices and distributors. With 8,000 team members, LargeCompany Inc. maintains 51 product, research, and service facilities worldwide. As a publicly traded company for more than 20 years, LargeCompany Inc.'s total revenues for the previous year exceeded $1.2 billion.
LargeCompany Inc. has 8,000 total users distributed across more than 50 locations worldwide in a network topology similar to the one sketched out in Figure 3.8. Approximately 800 users are mobile (that is, they access the network from a variety of locations). San Jose is the organization's headquarters and central network hub. The wide-area network topology is configured in a hub-and-spoke type configuration. There are two defined major spokes: Frankfurt, Germany and Buenos Aires, Brazil. All locations are linked via frame-relay type connections. The IT organization has 60 staff members that are responsible for the infrastructure, help desk support, and end-user and staff training.
){kind=link}
Figure 3.8 LARGECOMPANY INC. NETWORK TOPOLOGY.
Within the next eight to 12 months, LargeCompany Inc. expects that its number of employees will double through acquisitions of several smaller companies.
The following list summarizes vital statistics for LargeCompany Inc.:
Corporate Office: San Jose, California
Employees: 8,000
US Offices: Anchorage, Charlotte, Cheyenne, Chicago, Dayton, Detroit, Guam, Houston, Indianapolis, Las Vegas, Kansas City, Knoxville, Memphis, Minneapolis, Miami, New Orleans, Newark, New York, Oshkosh, Pittsburgh, Philadelphia, Salt Lake City, San Diego, San Francisco, Santa Fe, Seattle, Stamford, and Sunnyvale
Worldwide Offices: Algiers, Amsterdam, Bogotá, Buenos Aires, Calgary, Capetown, Dublin, Frankfurt, Kuwait, La Paz, Mexico City, Milan, Moscow, Nairobi, Oslo, Paris, Riyadh, Sao Palo, Tokyo, Toronto, and Warsaw
Current DNS Implementation
DNS is also heavily used within this organization. A combination of Unix BIND 8.x and BIND 4.x servers provide DNS for the entire organization. The installation is authoritative to the domain.
Business Requirements
LargeCompany Inc. has identified the following business requirements for its reason to migrate to Exchange 2000:
A more reliable and efficient enterprise mail system
Lower Total Cost of Ownership (TCO)
Scalability
Complete communication platform
The ability to decentralize administration
The ability to provide the highest level of performance and reliability by leveraging existing technologies implemented within the organization (storage area networks and so on)
A scalable design
A secured remote access solution for mobile user access
Deployment Roles
For LargeCompany Inc.'s Exchange 2000 project, note that there will be additional roles added that do not appear in the roles section of this chapter. The objective is to illustrate how to modify or add roles based on the needs of the organization.
For LargeCompany Inc., the CIO, IT Director, and Network Systems Manager are directly involved with this project. The organization has a highly skilled network systems support department that is qualified to lead as well as provide hands-on implementation support. In addition, LargeCompany Inc. has an internal training unit that will work with an outside vendor to provide all needed end-user and staff training. The role assignments are as follows:
Executive Sponsor: Internal company IT Director
Stakeholders: Internal company CIO, IT Director, and Network Systems Manager
Product Manager: Internal company Network Systems Manager
Project Manager: Internal company project manager
Design Architect and Design Team: Internal company design team with external contract assistance
Quality Assurance Coordinator: External contracted resource
Technology Implementation Team: Internal company IT staff with external contracted assistance
Training and Support Coordinator: Combination internal company resources along with external contracted resources
Projected DNS Implementation
The current DNS installation is exclusively Unix BIND. Due to the project time frame, limited staff availability, and level of effort required for a migration to Windows 2000 DDNS, the Design Architect has recommended that the organization maintain the current configuration. However, all BIND servers need to be upgraded to BIND version 8.2.1 or higher. This BIND version satisfies the two requirements needed to support Windows 2000 Active Directory. The two requirements are Dynamic DNS and SRV resource records. In addition, BIND 8.2.1 supports incremental zone transfers.
AD Domain Model Used
There are two possible solutions for this organization. Both the placeholder and peer root domain models deliver the functionality that the organization has outlined previously. However, the placeholder root domain model does not have the flexibility (it is not held to as many constraints) that the peer root has to allow the organization to integrate additional business units through acquisition. This solution also satisfies the administrative requirements.
Define Storage Groups and Multiple Databases
The storage solution for LargeCompany Inc. is as follows:
San Jose, Frankfurt, and Buenos Aires all currently have separate SAN solution implemented at each location to support the decentralized enterprise applications of the organization. The SAN installations have been designed to provide sufficient support for the current applications that have been identified as mission critical. Additional disk space has been reserved for future upgrades and/or additions to essential enterprise applications. These three corporate hubs use their local SAN installation as the data portal for the mail and public stores for each Exchange server installation. There are two mail and public store servers per site. Each server is configured with two separate RAID-1 sets for the transaction log and the Windows 2000 operating system.
The medium size branch offices with 250–500 users have their own servers. Each server uses RAID 0+1 for the mail and public stores defined in a single storage group configuration. Two separate RAID-1 drive sets are used for the transaction log file and Windows 2000 operating system. This configuration satisfies the two business requirements: reliability and efficiency.
The smaller branch offices with 50–100 users also have their own mail servers. The Design Team has concluded, based on the needs of the organization, that for the smaller locations, reliability outweighs the efficiency requirements. For this reason, the server configuration for these offices includes a single server, single storage group configuration. This server hosts all Exchange-related components. RAID-5 is configured for the mail and public stores and a separate RAID-1 drive set houses the storage group transaction log set. A separate RAID-1 pair contains the Windows 2000 operating system and other related services or applications. In addition, there are two databases configured within the storage group where half the users use one database for the storage of their mailboxes and the other half use the other database for their mailbox storage.
The branch offices that have fewer than 20 users will not have local Exchange servers. Instead, these locations all have a mailbox defined at the corporate hub in San Jose. Because of the wide-area bandwidth constraints and the absence of administrative support at these smaller offices, it has been decided that all mail users at these locations use the Web-enabled client (Outlook Web Access) for e-mail access.
Administrative Groups
LargeCompany Inc. uses the distributed Exchange administration model. There are three administrative groups, NorthAmerica AGroup, SouthAmerica AGroup, and Europe AGroup. Each administrative group contains its own regional routing groups, servers, public folder trees, policies, and other related objects.
Routing Design
Because of LargeCompany Inc.'s global presence and complex physical network topology, the following routing group configuration is recommended.
Multiple target bridgehead servers will be defined within each routing group. In the event that the first bridgehead server becomes unavailable, the Routing Group Connector would resort to other defined target(s) for message delivery. At every Exchange site, the Routing Group connector is configured with multiple target bridgeheads. "Cost" will be used to control the query order (basically, all sites are configured with all three RG bridgeheads as targets). In the event that all target bridgeheads on the connector become unavailable, the whole connector would be marked down and other routes would be evaluated. If there are other available routes, messages will then be rerouted. If there are no other routes available, messages will sit in the local queue until the connector comes back up.
Also, each source Routing Group bridgehead is configured with multiple target (destination) bridgeheads (also controlled by cost). For example, Frankfurt, a defined source RG bridgehead, would have both Buenos Aires and San Jose as destination RG bridgeheads.
Remote Access
For LargeCompany Inc., there are three separate front-end server clusters implemented. One at the corporate hub in San Jose and one at each major spoke in Buenos Aires and Frankfurt. Each site configuration is identical to that of MediumCompany Inc. The process that is implemented dictates that regardless of location, the assigned "virtual" server will be used. For example, if the user's mailbox resides on a server that is in the North America domain, the user, regardless of her geographic location, will access the na.webmail.largecompanyinc.com for Outlook Web Access (OWA).