- 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
Exchange 2000 Support and Maintenance Tasks
There are several tasks that need to be planned for to ensure a successful completion and ongoing operation of an Exchange 2000 environment. First and foremost is training and education for both the administrators and end-users of the organization. A properly planned and implemented messaging environment can be perceived as a failure if administrators do not know how to manage the environment and end-users do not know how to send and receive messages.
Additionally, maintenance practices help keep the messaging system operational and documentation provides valuable information for debugging and problem solving if and when maintenance and support is required.
Training (Administrator and End-User Training)
There are two training tracks: one for administrators and the other for end-users. Obviously, each group needs a tailored training curriculum. The administrator training should include in-depth information regarding the maintenance and upkeep of the Exchange installation. The end-user training focuses specifically on the Exchange client (Outlook client) and if applicable, retrieving mail via remote access. Following are two sample training outlines that can be used to develop the training plan used by the organization. Keep in mind that the outlines provided are guides and each option can be used individually or in combination. The choices depend on the established training objectives.
Administrator Training
In an effort to ensure a successful deployment, it's important to properly train and prepare the support staff. There are many methods utilized by professional trainers. The ones that prove to be the most successful are tailored to accommodate diverse learning styles.
Administrator training can be covered in a classroom environment, Computer Base Training (CBT), hands-on, or in combination based on the learning styles of the organization's IT staff. In many cases the administrator of the Exchange messaging environment is also responsible for administering, managing, and troubleshooting the core Windows 2000 Active Directory environment. However, in other cases the tasks are distributed across two or more groups of administrators. An organization needs to determine whether the administrators are the same or different so that the appropriate training can be provided to all administrators involved.
Administering an Active Directory Environment
Basic Windows 2000 Active Directory training typically includes the basic background of Active Directory terminology as well as the tasks of managing and administering the Active Directory. Other values gained in training on Active Directory administration include getting hands-on experience administering Active Directory to accomplish user, group, and computer management tasks. Some of the components of an Active Directory training are
Administering the Active Directory
Using and customizing the Microsoft Management Console (MMC)
Adding users and groups
Resetting passwords
Adding computer accounts
Creating Organizational Units (OUs)
Moving users to a different OU
Creating common shared groups
Securing and testing the Active Directory OU structure
Delegating administration privileges
Testing the administration privileges
End-User Training
Training end-users on the use of Microsoft Outlook to access the messaging system is extremely challenging. This is primarily true because of the varying technical skills and experience of the users throughout an organization as well as the individual use of messaging that an individual would have. Many organizations have tried to create special training sessions broken down by skill level and departmental usage of the end-users. However, by the time the organization adds in user availability for training on a specific day and time, the logistics of planning and coordinating training to that level of detail and focus becomes extremely challenging.
In many cases, organizations find that a broader, more general initial training can get all users through a basic Microsoft Outlook training right before or immediately after the Exchange 2000 environment is implemented. Then they can run specialty sessions for more advanced users or by departments at a later date. The standard course outline detailed here is a guide that can be used in creating a structure for the basic end-user training.
Typically, training is viewed as a single occurrence; the user attends training and is then expected to use the software. However, users usually have questions after any training session. For that reason, it is suggested that after Exchange 2000 is deployed and initial end-user training is provided, post deployment support is also provided at some point after the initial training has been completed. This option offers the users a chance to work with the new software in their normal work environment and have a resource available to answer any questions they might have.
To offer post-deployment support and organization could require an Outlook trainer to spend an eight-hour day (or portion thereof) on-site answering any end-user questions. Typically, individual users sign up for a time slot during which the trainer can focus his/her attention on that individual user, answering specific questions. These are all suggestions and can be used in whole or in part based on the needs of the organization, the project budget, and the staff.
Understanding Microsoft Outlook
There are five major areas for end-user training of the Microsoft Outlook client. They include Outlook messaging, calendaring, contacts, tasks, and tools. Some of the core topics that should be covered in a Microsoft Outlook client training structured around these five areas include
Messaging:
Overview of the Outlook client
Introducing Outlook Today
Introducing the Inbox
Creating and sending mail messages
Receiving and viewing incoming mail messages
Moving a message to a different folder
Creating custom folders in Outlook
Adding an attachment to a message
Printing a message
Calendaring:
Adding a personal appointment to your calendar
Creating and sending a meeting request
Accepting a meeting request
Updating a meeting request
Contacts:
Creating a Contact
Organizing Contacts using categories
Searching for a Contact
Sending a Contact to another user
Tasks:
Creating a task
Editing existing tasks
Marking tasks as complete
Tools:
Creating an Auto Signature
Creating an Out of Office Reply
Creating Rules and Filters
Customizing the Outlook Bar
Troubleshooting the Messaging Environment
The ability to solve and troubleshoot problems that arise is important for any network administrator. Some of the components covered in common troubleshooting courses include
Tracking messages sent and received from the Exchange 2000 environment. Inevitably, a user will not receive a mail message sent by an external client or vendor, or a message sent by a user will not end up in the mailbox of the external recipient. There are several explanations for why a message does not end up at the intended destination, and most are completely unrelated to the Exchange system. For example, a user might mistype the recipient's name or domain name, the external system might be down (or non-operational), the external user's system might block large attachments, and so on. However, it is the responsibility of the Exchange administrator to track the message and explain to the user why his or her message did not end up where it was intended.
Problem solving message routing errors. Because both Active Directory and Exchange rely on the routing of information across a LAN or WAN backbone, any errors in LAN or WAN transport can cause communications errors on the network. The administrator of the network needs to understand routing and replication functions as well as debugging techniques. This is both to validate that the system is set up properly in the first place and to debug problems if or when they arise.
Remote client access problems. One of the biggest challenges to a messaging administrator is providing support to a remote user or group of users. Not only does the distance from the administrator to the user prove to be challenging, but the number of different devices that could be causing the problem or error makes problem solving a series of error isolation tasks. This type of problem solving involves both technical analysis and repair, but also very methodical problem isolation processes. In many cases, problem solving these types of issues is confirming what the problem is not, which eventually leads to limiting what the problem really ends up being.
These, along with many other problem solving, debugging, and maintenance techniques are covered in Chapter 9, "Supporting and Managing Exchange 2000."
Planning for Exchange 2000 Maintenance
Over time, performance degradation of the Exchange database can occur, sometimes even leading to corruption. This is a result of extensive updates. It is similar to the way in which hard disk partitions become fragmented due to constant read/writes. This section briefly addresses maintenance considerations. The primary utility provided by Microsoft to assist in this process is the ESEUTIL tool.
It is recommended that maintenance schedules be created. Specifically, a schedule should be created for weekly, biweekly, monthly, and periodic maintenance. Included on that schedule should be tasks that check the integrity of the database and repair corruption when it is detected.
Exchange is designed to automatically perform online maintenance. This process typically occurs during low-peak hours and performs basic clean up and online defragmentation. However, that does not mean that errors reported in the event logs should be ignored. Instead, they are serious and signal possible logical corruption within the database. ESEUTIL.EXE, the Microsoft utility that should be run against the database periodically, corrects the structure of the tables and records of the database.
NOTE
This topic is discussed in detail in Chapter 9.
Documentation
Creation of the following documents is highly recommended to ensure a successful deployment. All of these documents are recommended but none are absolutely essential. The amount of documentation and level of detail will be adjusted based on project needs and budget.
Design guide. The design guide presents a high-level design overview that describes the overall strategy for the messaging environment.
Migration guide. Whereas the design guide describes what the future environment will look like, the migration guide describes how the organization will migrate from the existing environment to the new environment. In many cases, organizations think that design and migration are one in the same; however, they need to be treated as two completely different processes, thus two completely different documents need to be created.
Diagrams. These are LAN/WAN layouts showing how sites are interconnected and how messages should flow throughout the environment. Other valuable information on the LAN/WAN diagrams include the notation of line speeds, committed information rate (CIR), and available bandwidth between connections.
Schedule. The project schedule needs to detail the dates, tasks, task interdependencies, cost, and resource requirements for the project. There may be several schedules created or the schedules may all be combined into one large schedule. However, in an end-to-end project, the schedule would include an analysis phase, a planning phase, a design phase, a prototype/proof of concept phase, a pilot/test phase, an implementation phase, and a support/training phase.
Build document. The build document is a detailed configuration summary created from the pilot and rollout phases documenting the configuration parameters of both hardware and software for the messaging system. It can be used to re-create the basic functionality of a server lost to a disaster, or for adding new servers to the Windows 2000/Exchange 2000 organization after the deployment is completed.