Home > Articles > Information Technology

Planning and Designing an Exchange 2000 Environment

  • Print
  • + Share This
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.
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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020