The key to a successful Exchange 2000 deployment project is spening adequate time planning and designing the future Active Directory and messaging environment as well as creating a well-thought-out migration plan. This chapter shows you how.

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.

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.