- 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
Case Study for MediumCompany Inc.
MediumCompany Inc. is larger than the previous case study with complexity caused by not only having more users, but also more physical sites that create replication demands for the Active Directory as well as distributed administration.
MediumCompany Inc. was founded in 1989 and is a leading supplier of programmable logic devices and associated software tools. MediumCompany Inc.'s programmable logic devices address high-speed, low-power applications in the telecommunications, data communications, and industrial markets. MediumCompany Inc. is a well-known, publicly traded organization.
MediumCompany Inc. has 1,500 total users distributed across 12 locations throughout the United States with a network topology sketched out in Figure 3.7. Approximately 300 users are mobile (that is, they access the network from a variety of locations). Of the 12 locations, Sunnyvale is the organization's headquarters and central network hub. Portland, Oregon and Los Angeles, California both have dedicated point-to-point T-1 connections to the corporate hub in Sunnyvale. All other remote locations are connected to the Sunnyvale location via a frame-relay connection. The IT team consists of 20 total support staff.
The following list gives the vital statistics for MediumCompany Inc.:
Corporate Office: Sunnyvale, California
Employees: Approximately 1,500
Remote Offices: Atlanta, Austin, Baltimore, Boston, Chicago, Dallas, Denver, Los Angeles, New York, Portland, Des Moines, and Sunnyvale
Research and Development Facilities: Sunnyvale, California and Portland, Oregon
Figure 3.7 MediumCompany Inc. network topology.
Current DNS Implementation
DNS is extensively used within the organization. Unix BIND (BIND version 4.9.x) and Microsoft's Windows NT DNS co-exist, with the BIND installation defined as authoritative to the company's DNS domain and the Windows NT DNS as the subordinate. The Unix BIND installation is the defined primary zone with NT DNS as secondary.
NOTE
The server that is authoritative to a specific DNS namespace contains the read-write/master copy of the database for that space. This information is structured into units called zones.
Changes to the master database are automatically replicated to its subordinates. This process is referred to as a zone transfer. During a zone transfer, the primary zone replicates all changes, or deltas, to all known secondary zones. Resource record (RR) changes and/or updates to the space are automatically written to the primary zone.
Business Requirements
MediumCompany 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 centralize policy and administrative management
The ability to delegate administrative responsibilities to branch offices
The ability to provide the highest level of performance and reliability within the established project budget
A remote access solution that leverages the Internet
Deployment Roles
MediumCompany Inc. has 20 IT staff members with ten of them assigned to the home office responsible for managing the infrastructure and help desk. The remaining ten staff members are assigned to other locations. Many employees work out of their homes and need access to corporate resources over the Internet.
The Chief Information Officer (CIO) has determined that his staff has the required skill sets needed to ensure a successful project deployment. However, the CIO has chosen to use an outside vendor to assist in the planning and design aspects of the project. The roles for this company are as follows:
Product Manager: Internal company IT director
Project Manager: Internal company project manager
Design Architect and Design Team: Combination contracted consultant and internal IT staff
Quality Assurance Coordinator: External contracted resource
Technology Implementation Team: Internal IT Staff with external contracted assistance
Training and Support Coordinator: Internal IT staff resources
Projected DNS Implementation
The DNS configuration for MediumCompany Inc. includes both Unix BIND (BIND version 4.9.x) and Microsoft's Windows NT DNS. The BIND installation is defined as authoritative to the company's DNS domain and the Windows NT DNS as the subordinate.
The Design Architect and the Design Team have jointly decided to maintain both installations. However, these installations will be redeployed so that the Windows 2000 DDNS implementation is defined as authoritative for the organization's DNS domain. The Unix BIND servers that are not at least BIND version 8.2.1 will be upgraded. Also, the Microsoft installation will hold the role of primary with the BIND installation as secondary. Zone transfers will be defined to replicate DNS updates.
AD Domain Model Used
The single domain model would also be the right solution for MediumCompany Inc. because they could centralize policy and administrative management at the corporate hub in Sunnyvale. With this model, extensive OUs along with group and security policies could be developed to delegate local administration to selected branch offices.
Define Storage Groups and Multiple Databases
The storage solution for MediumCompany Inc. is as follows:
The larger corporate sites in Portland, Los Angeles, and Sunnyvale all have their own mail 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 20 or more users will also have their own mail servers. The Design Team has concluded, based on the needs of the organization, that for the smaller locations, reliability outweighed 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 do not have local Exchange servers. Instead, these locations all have a mailbox defined at the corporate hub in Sunnyvale. Because of the wide-area bandwidth constraints and the absence of administrative support at the 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
MediumCompany Inc. has a core IT administrative group that manages the overall health of the entire infrastructure. Within some of the larger branch offices, there are local administrators. They are responsible for the day-to-day support of the local installations. This administrative structure maps directly to the centralized policy management model. The core group determines how responsibilities will be delegated among the IT staff.
Routing Design
MediumCompany Inc. creates a routing group called West Coast RGroup to include Portland, Los Angeles, and Sunnyvale. The nine remaining remote locations, all of which are connected by varying frame-connections, are defined within their own routing group. In addition, each routing group is configured with a routing group connector that communicates directly with the West Cost RGroup routing group.
Due to the constraints of the physical wide-area network, the Design Team realizes that the routing group topology does not afford for any message routing redundancy. They have requested the assistance of the infrastructure group. This group has been recruited to evaluate and present to the Design Team with a proposed redundant or fail-over data link solution (that is, redundant VPN or ISDN fail-over). This allows the Design Team to reengineer the design of the routing group configuration to provide message routing redundancy.
Remote Access
The remote access solution used by MediumCompany Inc. includes a single front-end server for remote e-mail access for the entire organization. This server resides in the DMZ. The IT group registers a DNS hostname that can be used by remote mail users to attach to the front-end server. For example, the remote user would enter http://webmail.mediumcompanyinc_.com/exchange to establish an Outlook Web Access session. In fact, due to the number of remote access users, MediumCompany Inc. has three front-end servers configured within the DMZ in a clustered configuration using the Windows 2000 Network Load Balancing (NLB) services. This provides the density of servers needed to properly handle the remote access traffic demands of the organization.
Because remote access servers use low-bandwidth demands between the client and the front-end server, the placement of the servers can be centralized. MediumCompany Inc. places the front-end servers at the corporate hub in Sunnyvale. Regardless of where a user may be accessing the Internet, there should be no difference in the end performance over the general Internet whether the organization has this centralized Web server design or a Web server in every company location across the country.
Lastly, for MediumCompany Inc., security is an issue; therefore, Secure Socket Layer (SSL) are configured to provide secure remote sessions.