Chapter 6 - Support
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Microsoft® Exchange 2000 Server
This chapter is part of the Exchange 2000 Server Operations Guide.
An effective support environment allows you to deal more efficiently with known and unknown issues, increasing the reliability of your Microsoft® Exchange 2000 Server environment. This chapter shows how to manage your support in an Exchange 2000 Server environment.
On This Page
The more you can do with a product, the more you can do wrong. Microsoft® Exchange 2000 Server is an extremely diverse and complex product. If you use Exchange to its full potential, you will be exposing more functionality to your users than ever before, thus creating more and tougher challenges for the support environment than ever before.
To offer effective support to an Exchange 2000 Server environment, you first need to define what is being supported. There are two broad categories of support:
End user support
In this chapter, you will learn how to create an effective support environment for dealing with both end-user issues and server problems.
This chapter covers the following procedures:
Service desk support
At the end of this chapter you will be able to ensure that your environment provides appropriate support for users and administrators of Exchange 2000 Server.
Providing Support for End Users
It is likely that almost everyone in your organization will be an e-mail user. All of those users may require support at some point in time. In most environments, it is critical to maintain service as much as possible to all users. A single user without e-mail may cost the organization large amounts of money and present the organization in a bad light to any outsiders who want to e-mail that user.
Your Exchange 2000 Server environment may be one of the most complicated and diverse of your IT infrastructure. You may have a wide range of different clients, including the following:
MAPI clients (Exchange Client, Microsoft Outlook® 97 messaging and collaboration client, Outlook 98, Outlook 2000, and Outlook 2002)
POP3/IMAP4 clients (Outlook, Outlook Express, Netscape Communicator, Eudora, and so on)
HTTP clients (Microsoft Internet Explorer, Netscape Communicator, and so on) for Outlook Web Access (OWA)
Instant messaging client
Conferencing server clients (Net Meeting and others)
End users may have a number of different uses for a client. Internet Explorer can be used for OWA or alongside Net Meeting for video conferencing. Outlook XP can be used as a MAPI client, but also as a POP3, IMAP4, or HTTP client. In many cases it will be used with custom forms, or have extra third-party functionality built into it (for example, the ability to read faxes or listen to voicemail). Not only that, but your client base may be inside or outside a firewall, on the road on laptops, accessing Exchange via dial-up lines or via the Internet. The number of combinations is enormous.
Ironically, the very complexity of the client base is actually of benefit when trying to maintain service to users. For example, users having problems with their Outlook client should still be able to send and receive mail from their computer using Internet Explorer and OWA as their client. This allows you to maintain service to the users while investigating their problem.
Reducing End User Support Costs
The following are some reasons users could require support:
Client software problems
Client hardware problems
Client connectivity problems (for example, to a server running Exchange or domain controller)
Server software problems (servers running Exchange or domain controllers)
Server hardware problems (servers running Exchange or domain controllers)
Server connectivity problems (to domain controllers, other servers running Exchange or the Internet)
Educating your users is one of the key ways to reduce support costs. If users know how to use their clients efficiently and effectively, they will need to contact the Service Desk much less frequently. This results in fewer Service Desk incidents and reduced costs.
In the other areas, the main way of reducing costs is to ensure that the problems occur less frequently in the first place, and that they are resolved quickly when they do occur. This is covered in detail in the other chapters of this guide.
A best practice for reducing the cost of user support is to provide a Web site containing help information that is accessible to all messaging users. There are significant cost savings any time users can obtain the information they need without assistance from the Service Desk. The following are some examples of the type of information that might be included in the Web site:
Assistance for creating and managing mailboxes
How-to guides for client configuration (according to your standards) and for resolving common connectivity problems
Answers to frequently asked questions
Workarounds for known problems (related to the problem-management process discussed later in this chapter)
Links to other online help information (internal or external)
Server status and instructions for determining a user's mailbox server
Information about current incidents that affect more than one user. This will reduce the number of calls that tend to flood Service Desks when there is a major incident. A good example is when you've disabled parts of the system to scan for and remove virus-infected messages and/or attachments.
Even in the best of environments, you will still need to resolve end-user problems on occasion. If you are going to deal with client-support issues effectively, you will need to make sure that you clearly define which clients are supported and in what configuration they are supported. Your change and configuration management strategy should include a complete record of your client base. You can use Microsoft Windows® 2000 Group Policy and/or Systems Management Server to ensure that workstation configuration is controlled and that the Change Management Database (CMDB) remains accurate.
Note: It is important to periodically audit the CMDB to ensure that it reflects your inventory.
If you are dealing with clients outside the company firewall, it is much more difficult to have tight control over the configuration. You can, however, minimize support costs by insisting that only certain clients are supported. For example, you may choose to support Outlook Express as a POP3 client, but not Eudora. You can also choose to minimize the number of protocols supported. For example, you may choose to only support OWA as the means of access outside the firewall.
Not all of these problems are necessarily client issues. End users will be directly affected by problems at the server level. The main difference is that client issues generally affect small numbers of users, whereas server issues normally affect larger numbers of users.
Whatever the end-user support issue is, an effective support team will ensure the following:
Problems can be reported easily
End users are notified quickly that their problem is being investigated and are kept informed of the status of their problem
Problems are resolved as quickly and efficiently as possible
The result of all this should be to ensure that service is restored as soon as possible in accordance with the SLA.
Problems will typically be reported in one of two ways: as a result of your extensive monitoring (see Chapter 5), you may receive alerts that warn you of a problem; or a user may report a problem.
The sooner you can receive an accurate report of a problem from a user, the earlier you can begin to solve that problem before it becomes an issue for the organization at large.
You may want to consider using Exchange itself as the basis for your Service Desk application. You could create a custom form for Service Desk requests, which would be routed to a public folder. The Service Desk staff would examine these requests as they came in and either reroute them or deal with them. As the requests are being dealt with, further information could be added to the form. Then, when the request is resolved, this information could be routed to a second public folder and could form the basis of your internal knowledge base.
Note: There is risk to using Exchange Server as the basis for your helpdesk application, as a widespread Exchange outage will affect your ability to resolve problems.
Of course, you must not use the e-mail system as your only means of receiving user notification of e-mail problems! Ensure that there is a telephone support line which can be used as an alternative method of reporting problems. If you have a support-related web site, consider adding a problem reporting page.
Dealing with User Problems
You must have a mechanism for dealing with user problems once they are reported. The first step in this process is to determine the scope of the problem. In doing so, you should consider the following:
How many users are affected by the problem? (Does it affect a single user, all users on a server, all users in a region, and so on?
How critical is the problem? (Does it prevent users from using all e-mail? Can they use another client to send e-mail? Is just calendar functionality affected?)
This information will help you to prioritize the problem. For example, as a general rule, if one user cannot use Outlook e-mail (but can use other forms of e-mail clients), this would be a lower priority than if an entire region were unable to access their mailboxes. Other factors also affect the prioritizing of the problem. For example, if the CEO of a corporation is unable to access e-mail, that may be more important than the entire Milwaukee office not being able to do so.
Once the problem has been prioritized, you will need to gather more information about the nature of the problem to determine how it is dealt with. If you have an up-to-date Change and Configuration Management Database and tight control over the client base, you should be fully aware of the client configuration when a problem is reported. This is often critical in resolving Exchange issues swiftly. The Service Desk may be able to resolve the problem themselves, or they may need to escalate the problem further.
Once you are aware of a problem, it is important to make sure that the end users are informed of the continuing status of the problem.
Exactly how you do this depends on the nature of the problem. For example, if there is a problem with a server running Exchange being unavailable, using e-mail to notify users is pointless. You would generally post this kind of information on the corporate intranet. If, however, the problem is with public folders being unavailable to users on a particular server, it may be more appropriate to send an e-mail to all users affected, and then send another e-mail when the problem has been resolved.
Note: Generally you should be cautious about notifying users of problems via e-mail. E-mail notification can lead to floods of phone calls from users that would otherwise be unaffected by the issue.
If individual users have problems, it is generally inappropriate to post update information to the intranet. In those circumstances, you should contact the user directly. If the user's e-mail client is unavailable, call or send an instant message. However, if only one e-mail client is unavailable, you could remind your users that they can use other clients to access mail. You will then be able to use e-mail to notify them of progress with their problem.
Regardless of the scope of the problem, you will need to ensure that the initial response to the user community is quick. This ensures that they are aware that their problem is being dealt with and when they can expect a solution (even if at this stage, the time to a solution is unknown). You should define in your SLA an initial response time to Service Desk queries.
Exchange Problem Management
While the Service Desk should resolve all reported incidents associated with known problems, the role of problem management is to determine the root cause of unresolved incidents. As problem management identifies and corrects the underlying causes of problems, it should ensure that the same problems do not occur repeatedly.
One of the most complicated things about Exchange problem management is that messaging as an IT service is dependent on a large number of non-messaging technologies. The following are some of the issues that would affect a user's ability to access e-mail.
Slow client-to-server connectivity (causing RPC timeout problems for MAPI clients)
No DNS server listed in client (causing problems finding servers running Exchange, Domain Controllers and Global Catalog servers)
Global Catalog server failure (meaning no Global Address Lists are available to clients)
Name-resolution problems on a server running Exchange (causing services to stop and databases to dismount)
Moving of client from one location to another (resulting in the client accessing Exchange and the Global Catalog [for address book lookups] across the WAN)
Network connectivity problems to Routing Group Master (causing the static routing table to be used instead and resulting in unpredictable routing)
In just the few examples listed above, network-connectivity problems, name-resolution issues, and failure of Global Catalog servers could all cause problems for Exchange. In many cases, the apparent Exchange problem is not an Exchange problem at all, but is caused by the failure of a related technology. The key to good problem management for Exchange 2000 Server is a good understanding of the interdependencies Exchange has, and good knowledge management in your support environment.
To help you with Exchange problem management, you should create dependency charts for a number of scenarios. Examples include the following:
A chart for MAPI client connectivity that lists all dependencies, for example, DNS, WINS, Exchange, Active Directory™ service, and so on
A chart for POP and IMAP client connectivity that lists all dependencies, for example, DNS, WINS, Exchange, Active Directory, SMTP relay, and so on
A chart for OWA client connectivity that lists all dependencies, for example, DNS, WINS, Exchange, Active Directory, FE servers, and so on
A chart for message-delivery issues, for example, DNS, SMTP relays, Internet connection, and so on
These charts can be modular and interrelated. For example, each of the client-connectivity charts can all reference the same Active Directory chart.
Part of the problem management process is ensuring that you have good communication within and across different support departments. The closest link in terms of support should be between the Active Directory support team and the Exchange support team. Exchange configuration information is stored in Active Directory, and Exchange clients and servers both make heavy use of it. In some organizations you may choose to merge these two departments, but even if you do not, you must ensure that the Exchange team is aware of problems with access to Active Directory.
The first level of support in an organization is usually the Service Desk. Depending on your environment, the Service Desk dealing with server problems may be the same one that deals with end user problems. However, the more information the Service Desk has, the less frequently it has to refer problems to outside sources and the lower the cost of resolving the problems.
As already mentioned, you may want to use Exchange as your means of dealing with Service Desk requests. Whichever method you use, you must make sure that Service Desk issues are reported fully and that the solutions are stored in a knowledge base that is easily searchable and available to all support staff. Many problems that are reported are well-known issues. If you can ensure quick resolution of these problems, not only will those users be helped, but you will also be able to deal more quickly with other problems. This can also lower the number of problems that have to go beyond the Service Desk in the future.
If you can ensure that the knowledge base is updated in real time to reflect current incidents, problem management will be able to use it to determine the impact of a widespread problem. You may also wish to make the application available to end users online, because this can reduce the amount of direct service desk intervention.
Do not simply rely upon your own knowledge base. The Microsoft Knowledge Base (available with TechNet or on http://support.microsoft.com) is a very useful record of support issues that have been encountered by Microsoft. If your support staff finds problems that have already been resolved in the Microsoft knowledge base, they should ensure that a reference to the corresponding article in the Microsoft knowledge base is present in their own knowledge base.
You will also find useful information in the various newsgroups and list servers available for Exchange. While the information delivered from these sources cannot be guaranteed to be accurate, it is often provides useful tips on how to deal with issues.
Event monitoring can be a very useful source of information to Service Desk staff trying to resolve a problem. If you do encounter problems with an area of Exchange, the Service Desk staff may wish to increase the monitoring level for that area of Exchange. Individual events now have hyperlinks associated with them, to allow your Service Desk staff to find out more information about the particular event. Event monitoring is covered in more detail in Chapter 4.
Education of the Service Desk staff is very important too. If they are aware only of Exchange issues, it can be difficult for them to deal with many problems themselves, and also difficult to route problems accordingly. You should ensure that your support staff has a complete picture of Exchange and its interdependencies.
For most organizations, it is not economically sound to have all Exchange 2000 Server expertise directly employed within the company. Normally the higher levels of support are contracted out. This could be to Microsoft or a third-party solution provider. However, it is important to have these relationships already in place to ensure swift response times when required.
Exchange 2000 Server, with its large number of interdependencies, large user base in organizations, and sheer importance to most of those organizations is a great challenge to support effectively. However, if you do provide effective support, the many improvements in the product's reliability can allow your users and support staff to gain the real benefits offered by the product.