Planning and Designing an Exchange 2000 Environment
- 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
In This CHAPTER
-
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.
End goals are met through proper planning and implementation. The recommended approach is one that allows a phased or stepped process. This chapter introduces and explains the important concepts that need to be covered during the planning and design phase of an Exchange 2000 rollout. Once the concept is understood, it can then be applied to the environment and the technology can be leveraged to meet the established requirements. At the end of this chapter, three case studies are presented. Each has the same business requirements; however, the physical network topology and infrastructure implementation differs between the case studies. The objective is to show that there are different ways to apply the concepts introduced in this chapter as a means of achieving the desired end results.
This chapter illustrates several different Exchange 2000 design configurations and scenarios using a common set of business requirements. With each case study, the design process is broken down, examined, and the logic behind the decisions is explained. This includes detailing the process and the rationale behind the design options selected in each of the scenarios.
There are key elements that are essential to the success of the Exchange 2000 deployment. They are mentioned where appropriate and to provide indicators where in the design process these objects should be researched and incorporated into the project plan. For example, the Active Directory implementation is an important and integral part of the Exchange 2000 deployment. However, the Active Directory design is discussed as an overview rather than in detail. The same is true for other infrastructure components such as the current Network Operating System (NOS) (WinNT, NetWare, and so on) and the migration strategy from the existing to the new mail system.
Mapping the Design Components
Prior to engaging in the actual design of an Exchange 2000 environment, a strategy needs to be developed that identifies, defines, and outlines the components needed to complete the design phase.
Defining the Design Components
There are several design components that need to be identified as part of the initial phase of the Exchange 2000 design. The components represent the items that need to be chosen based on the size, topology, and environment of an individual organization. This does not mean that all components are required for all projects.
Once the component list has been completed, it's important to ensure that the entire team is aware how each component is defined within the context of the project. This may seem insignificant, but in fact it is extremely important to the success of the project. Everyone on the team should be clear with regard to expectations associated with each of the components necessary to complete this phase. The different components are discussed in the next few sections.
Determining Functional Requirements
To determine the functional requirements for the Exchange design, the organization can map the stated business requirements to the available technologies. Some of the concepts to identify and document include the following:
Confirm the business requirements of the organization (such as to have a reliable e-mail messaging system, or to create an enterprise knowledge management system, or to have basic e-mail in place so that a sales force automation add-in that works with Outlook and Exchange can be deployed).
Establish whether Exchange 2000 offers all the features necessary to fulfill the stated business requirements. Sometimes user expectations exceed the features and functions of the product being deployed. It's a lot easier to reset expectations early on during the design and testing phase of a project than to wait for the solution to be fully deployed. That way, users will not make assumptions about what they can and cannot do.
Verify whether there are additional dependencies on the messaging system rollout. (For example, third-party add-on software or applications that directly or indirectly interface with Exchange 2000 such as network faxing, integrated voicemail, or document imaging.)
Choosing Deployment Roles
Assign roles and responsibilities to each project member. Determine the number of staff and their availability to this project. Assess the skill level of each staff member on the project and assign roles based on the experience and skill set of the individuals.
Some of the recommended roles are
Product manager. The product manager sets the objectives, manages outside vendor contacts, and sets the budget for the project.
Project manager. The project manager is responsible for tracking timelines, budget, and controlling changes in scope. (More specific project manager roles and responsibilities are highlighted in Chapter 4, "Prototyping and Piloting Exchange 2000.")
Design architect(s). The design architect is responsible for the technical specifications of the project design.
Quality assurance coordinator. The quality assurance coordinator oversees the prototype phase and is responsible for making sure that all dependent components are functioning as required.
Technical consultant. The technical consultant provides an additional level of expertise for all phases of the project and is responsible for the development of the design.
Training and support coordinator. The training and support coordinator makes sure that needed training is provided for users and staff. In addition, this person would be responsible for determining support needs and assembling the support staff.
Technology implementation team. The technology implementation team is a group of technical personnel responsible for the actual project implementation.
Creating Groups in the Active Directory with Exchange 2000 in Mind
There are five group types directly related to Exchange 2000. They include Security, Distribution, Domain Local, Global, and Universal Groups. There are benefits associated with each of these groups. The type and extent of the groups chosen is based on the business requirements of the organization. Some of these requirements are detailed in the following list:
Define the Active Directory mode to be used. Will it be mixed or native mode? As noted in Chapter 1, when the Active Directory domain is configured in mixed mode to support Windows 2000 clients as well as legacy Windows 95, Windows 98, and Windows NT4 clients, the organization cannot use Universal Security Groups. This means that if the organization wants to create a group that comprises members from multiple domains within a forest, the only way to do it is to create a universal distribution list. The universal distribution list can be mail-enabled to allow for global message distribution, but any security assignments would require the use of multiple global groups to accomplish the same task.
Determine which groups will best meet the business requirements. When creating groups in Windows NT4 or Windows 2000, many administrators just choose the default Global Security group to create and place members into. However, for users who belong to a group that is only relevant to a local domain (such as a group of local janitors in a domain that has no interaction with other individuals in other domains in the enterprise), there is no need to propagate the group information around the enterprise. In the cases where the group information does not need to be propagated, the organization should choose the Domain Local Security group to place members into. On the other hand, an organization may want to create a group where the member names specifically are exposed to Exchange users regardless of the domain in which the user is viewing the group. In these cases, the organization must use either a Universal Distribution List or a Universal Security group. Since the default Global Security group will have the group name propagate throughout the enterprise, the actual member names within the group will not propagate beyond the domain where the group was originally created.
Assess the advantages and disadvantages of each group type and the way in which each will affect the installation. As noted in the previous examples, the different types of groups have different impacts on how Exchange 2000 clients will be able to see or not see the group name. This is dependent on the domain the user belongs to—an Exchange 2000 client would or would not be able to view the members of a group.
Defining Storage Groups and Multiple Databases
Each organization's needs are going to be different. Based on the availability and support objectives, the number of storage groups and databases will be determined.
Determine the number of required storage groups. An Exchange 2000 server can have up to 15 storage groups per server. A storage group is used to group together databases into a logical grouping so that data can be backed up, administered, or managed in operational groupings.
Determine the number of databases per storage group. Each Exchange 2000 storage group can have up to six databases per storage group. To minimize the size of data stored in a single database, the organization can split the data across multiple databases. However, you can group the databases into storage groups for easier management and administration.
Defining Administrative and Routing Groups
Administrative groups are used to delegate Exchange specific administrative access control. The routing groups organize server communications based on connectivity constraints. In Exchange 2000, administration and message routing are completely different tasks, which allows organizations to delegate administrative control of Exchange (for adding, deleting, and modifying users). Also, the organization can separately develop message routing based on the server-to-server communication requirements of the organization.
Determine the number of administrative groups. An administrative group is created to build the boundary where an administrator has control for adding, deleting, and modifying messaging information.
Determine the number of routing groups per administrative group. Routing groups need to be designed and configured properly so that messages are successfully routed from server to server.
Determine the type of connector to be used to transport mail data between routing groups. Information can be routed between routing groups using the Routing Group Connector (RGC), SMTP connector, or x.400 connector. If the servers are connected to a fairly high-bandwidth WAN connection, RGC is the most robust connector between sites because it tracks inbound and outbound messages and handles more information than other routing options.
Identify source and destination routing group bridgeheads. The bridgehead servers of a routing group are the masters from which other systems send or receive messages to or from other servers within the routing group. In a fairly complex hub and spoke configuration, a single routing group bridgehead server could provide the routing for all of the servers in a region or a continent for other servers throughout the organization.
Assess whether or not securing the transport is necessary. When messages are routed over a private WAN connection, it is assumed that server-to-server messaging traffic is secured within the organization's backbone. However, if the Internet is used as the routing backbone, setting up secured server-to-server messaging transport would most likely be desired.
Identifying Remote Access Requirements
Based on the needs of the organization, the remote access requirement defines how users remotely access the mail system.
Determine the Outlook Web Access specifications and parameters for both internal and external access. Outlook Web Access (OWA) is not just an e-mail–access method for traveling or mobile users, but OWA can be used as a substitute client for internal messaging users as well. External OWA clients would need a secured transport to the OWA server, whereas internal OWA clients would not. Other parameters to choose include load balancing front-end OWA servers based on the number of users accessing the system either internally or externally.
Determine how virtual private networking will be used. Some users may require the full 32-bit Outlook client for their messaging access and need to have dial-up or virtual private network access to the messaging system. In these cases, connections need to be provided for remote client access.
Developing Exchange 2000 Maintenance Practices
Planning an Exchange implementation requires a methodology that addresses both pre- and post-implementation tasks. A document should be created to include the organization's maintenance policy and procedures.
Address the maintenance schedule. This can be most effectively done by determining the daily, weekly, biweekly, monthly, and other periodic maintenance procedures and checklists.
Determine general support procedures. This includes everything from problem solving and debugging processes and procedures to simple help desk knowledgebase support procedures.
Creating Service Level Agreements (SLAs)
Service level agreements are the IT department's commitments to the organization as to the level of service the Exchange users can expect. Specific parameters are determined for response and resolution times for Exchange problems.
The needs of the staff and the organization determine how availability, performance, problem response, and response time will be addressed. Providing service level agreement support extends beyond just tracking and reporting on service level operations. It also includes creating problem resolution procedures that can minimize operation failures as well as improve overall system uptime in a methodical manner.
Validating Hardware and Software Requirements
Based on the business objectives, the available technology, and the vendor requirements, the hardware and software requirements will be determined.
Size the installation by determining the site requirements based on size and services required.
Determine the vendor requirements and the additional software and hardware needed to meet the project objectives. This might involve re-using existing equipment (if properly configured with the appropriate memory, processing speed, and disk capacity required for the new environment). It might require minor upgrades or updates to the existing system or a complete replacement of servers and devices to meet the requirements of the new environment.
Outlining Training (Support and End-User Training)
Since a new application will be rolled out, training and method of delivery for both support staff and users will be required.
Determine the training budget and the method(s) of training that will be implemented. Typical options include full-day, hands-on courses, demonstration-only sessions, distance learning or Web-based training, or self-study training. The length, depth, and detail of the training will determine the overall cost and the per-individual cost for training.
Determine the training criteria, options, format, and materials. Visual-only training sessions cost less than sessions that have extensive documentation on training use and operations.
Establish the training schedule so that it is in sync with the deployment. Note that this schedule differs for the user and the IT staff personnel.
Preparing Documentation
It is critical to record all processes associated with each phase of the project. As an example, complete descriptions of the business requirements, all project phases, modifications to existing systems, as-builts, and so on should be included in the final documentation.
Determine what information will be included in the documentation. Typical options include textual design documents, graphical design visual documents, sequenced flow charts, and interactive Web-based documentation.