HTML> esg22fi.htm

Previous Page TOC Next Page



— 22 —
Diagnosing the Cause of a Problem


by Greg Todd

So how does one diagnose a problem with Microsoft Exchange Server? There are so many variables in a complex system such as Microsoft Exchange Server, it causes the scope of troubleshooting to be huge.

There's an old proverb that goes something like this: I can give you food and you will be hungry again, or I can teach you to fish and you will never be hungry. To do well at diagnosing Exchange problems you have to learn to fish.

Basically, troubleshooting is a process of elimination. But if you have several tools in your repertoire, you can apply them to see what light they shed on the problem. Usually, at least one tool points you to the cause of the problem. Often, more than one tool points to the same thing or illuminates different aspects of a more complex problem.

Most often, diagnosing the cause of a problem is a matter of using several tools together. For example, if a user experiences poor response time, you can check Windows NT Performance Monitor (discussed in Chapter 21, "Monitoring and Preventing Problems") to see if the server is heavily loaded. If the server looks okay, you can try RPC Ping to see if the connectivity is working properly between the client and the server. You can also check the NT Event Log for any strange-looking entries.

The Microsoft Exchange Server Administrator Guide spends about 100 pages dedicated to troubleshooting, specifically, Chapter 17, "Troubleshooting Tools and Resources" and Chapter 18, "Troubleshooting Your System." I encourage you to read these chapters for additional insight.

The Microsoft Exchange Resource Kit is also available. If you have used a Microsoft resource kit before, you know they can be quite helpful. The Exchange Resource Kit is no exception. It contains valuable tools and helpful information.

So rather than rewrite the Microsoft documentation or detail all the specific problems, this chapter highlights some of the more valuable tools and describes why you want to use them. You will find these tools help to track down the cause of a problem. Look at this chapter as a complement to the product documentation and to the tools introduced in Chapter 21, "Monitoring and Preventing Problems."

The following are the main diagnostic tools Exchange and Windows NT provides:

First this chapter discusses diagnostic tools included with Microsoft Exchange Server including RPC Ping, ISINTEG, EDBUTIL, MTACHECK, and others.

Next, the chapter looks at the Message Tracking Center, which is the message tracking utility included in the Exchange Administrator. This utility provides the capability to track the path of a message through the system.

Then, the chapter covers a few Windows NT Server administrative tools that prove helpful in troubleshooting such as Server Manager, User Manager for Domains, and Windows NT Event Viewer.

The scope of problems referred to in this chapter is limited to those problems that occur on an Exchange server. Examples are messages that don't make it to their destination, Exchange servers that don't talk to each other, a server that cannot be reached by the client, and errors that Exchange itself encounters.

This chapter does not attempt to address other issues that might still impact the server such as network problems, hardware problems, improper Windows NT configuration, and poor performance.

General Diagnostic Utilities


There are several diagnostic utilities and tools included with Microsoft Exchange Server and Windows NT. For the administrator who is trying to troubleshoot problems in the Exchange Server environment, they prove invaluable.

With the exception of the Inbox repair tool and ERROR, these utilities are run on the server. RPC Ping can use both the client and the server.

RPC Ping


If you are familiar with TCP/IP, you probably know about PING. RPC Ping serves a similar purpose to PING, but instead it uses RPCs (remote procedure calls) to ensure connectivity with the destination. RPC Ping is a handy utility to have around.

Figure 22.1 shows RPC Ping in action.

Figure 22.1. The RPC Ping utility is useful for checking connectivity from a client to an Exchange server.

In Figure 22.1, a ping has been sent to the Exchange Server called EXCHANGE by way of TCP/IP to the store endpoint. EXCHANGE responds with the appropriate responses, indicating that it is available to talk with clients. This section goes more into detail about using RPC Ping. By the end, you should understand what the screen in Figure 22.1 is telling you.

RPC Ping is located on the Microsoft Exchange Server CD, in the \SUPPORT\RPCPING directory. There is a small documentation file included there as well, which you might find useful.

There are two components to RPC Ping that make it work:


RPC Ping Server

The RPC Server for an Intel platform is called RPINGS.EXE. For Alpha, it's RPINGS_A.EXE. MIPS is RPINGS_M.EXE.

If you want to use the Ping Only mode or the Rping endpoint, you must have the RPC Ping server process running.

When the server process starts, it activates all possible protocols it can find on the server, by default, as shown in Figure 22.2.

Figure 22.2. The RPC Ping Server program has started with several protocols loaded and is ready for pinging.

Optionally, you can configure the server process to start a single protocol. This is useful if you only want to test one protocol at a time. The syntax is as follows:

RPINGS [-p protocol] where protocol can be any one of the following:


RPC Ping Client

The RPC client for an Intel platform comes in three versions:

For an Alpha platform, the client is RPINGC_A.EXE. MIPS is RPINGC_M.EXE. The RPC Ping client is what is shown in Figure 22.1.

There are multiple RPC methods the Exchange client uses to establish a connection with the Exchange server. RPC Ping supports all of these so you can test them as needed.

After ensuring the RPINGS.EXE process is running on your Exchange Server computer, you must specify three parameters in the client program before you initiate a ping:

First, the Exchange Server field specifies the name of the server to ping. You can also specify an IP address here if you're using TCP/IP.

Second, the Protocol Sequence field specifies the configuration of the RPC mechanism that is used for the NCA connection between the client and server. In order for RPC Ping to work, the client and server must both be using the same protocol sequence.

Table 22.1 shows a listing of the protocols that RPC Ping supports.

Table 22.1. Supported protocols in RPC Ping.

Protocol Sequence

Transport Mechanism

ncacn_np

Named Pipes

ncacn_nb_nb

NetBIOS over NetBEUI

ncacn_nb_tcp

NetBIOS over TCP/IP

ncacn_ip_tcp

TCP/IP

ncacn_spx

SPX

ncacn_vns_spp

Banyan VINES

ncadg_ip_udp

UDP datagram TCP/IP

ncadg_ipx

IPX datagram IPX

ncalrpc

Local procedure call (LPC)


Third, the Endpoint field specifies the protocol—specific port with which the RPC Ping client communicates on the other computers. The RPC Ping clients can communicate in one of three ways, as selected in the Endpoint field:

Optionally, you can select the Mode for RPC Ping operation. The selections in the Mode box determine how the RPC ping is carried out.

Finally, the Number of Pings box is self-explanatory—it specifies the number of times the ping operation will be carried out when the Mode is set to Ping Only.

ISINTEG


ISINTEG is the Microsoft Exchange information store integrity checker. The executable, ISINTEG.EXE, is automatically installed in the \EXCHSRVR\BIN directory on the Exchange Server during setup.

You must run ISINTEG on the Exchange Server machine, and you must stop the MSExchangeIS service before using ISINTEG.



You don't have to stop all the Exchange Services when you run ISINTEG, only MSExchangeIS. In fact, you can leave MSExchangeSA, MSExchangeDS, and MSExchangeMTA running if you like. If you just stop MSExchangeIS, the other three are left running.

See Appendix B, "Command Reference," for the syntax of ISINTEG. If you prefer to see the syntax on the screen, you can run ISINTEG with no parameters from a Windows NT command prompt.

ISINTEG serves three main purposes:

So why do you want to do these things?

Patch

In Exchange terminology, an offline backup of the Information Store is a file-level backup of the IS that does not occur when Exchange Server is not up and running. Remember, the IS is composed of two main files, PRIV.EDB and PUB.EDB, which are open while Exchange Server is running. Therefore, performing an offline backup of the IS is fundamentally a matter of shutting down Exchange Server and backing up these two files.

An offline restore of the Information Store is a file-level restore that does not support restoring the IS while Exchange Server is up and running. An offline restore of the IS is typically performed using an offline backup set or some other method that replaces PRIV.EDB and PUB.EDB.

Patch comes into play after the restore. After you perform an offline restore of the IS, you must use ISINTEG to patch the database before you can use it. Among other things, Patch replaces GUIDs (Globally Unique IDs) in the database so all entries in the database will be handled properly by Exchange.

For example, suppose you bring down the Exchange Server and save a copy of the IS—both public and private stores—somewhere, be it on tape or disk. Sometime later you restore those IS files, replacing the existing IS. When you try to start the MSExchangeIS service, you get an error and the service doesn't start. You must run ISINTEG using the following syntax to patch the IS and prepare it for use.


ISINTEG -PATCH

ISINTEG patches both the public and private stores automatically—there is currently no way to patch one or the other. It doesn't take all that long, usually under a minute, depending on the size of your IS and the speed of your computer.

I find using ISINTEG useful when I am doing performance tests with Exchange Server. I want to always start with the IS in the same state before each test run, so I stop MSExchangeIS, restore the master IS from the backup, and use ISINTEG to patch it. After rebooting the server (not necessary, but I always do), I'm ready for the next run.

Test and Fix

If your IS seems to be acting funny, run ISINTEG and see what it finds. When ISINTEG executes, it runs a suite of 22 tests on your IS—either private store, public store, or both.

For convenience test and fix have a verbose mode, and you can instruct ISINTEG to log the output to a file for later reference.

ISINTEG can take a while to run, depending on the size of your database and the speed of the computer. A 100MB database check can take about ten minutes to run all the tests.

For example, a common usage of ISINTEG is for checking the private store with verbose output and logging the results in the default ASCII text file called ISINTEG.PRI. No fixes will be performed. The command looks like this:


ISINTEG -PRIVATE -VERBOSE -L

If ISINTEG finds a problem and you want to fix it, add the -FIX parameter to the end of the parameter list and run ISINTEG again.

For example, say the power goes out while Exchange is running. When you restart the server, you find that the MSExchangeIS service logs an error on initialization and it doesn't start. The first step is to run ISINTEG and EDBUTIL (covered in next section) to see what's going on.

Technically, in this scenario there should not be a problem. When you start Exchange Server, the database automatically rolls back to the last checkpoint, and the logs are applied to the database to restore it to the point of failure. But if something goes wrong there, ISINTEG can come in handy to help set things straight.

Dump

Like -FIX and -PATCH, -DUMP is another parameter of ISINTEG. However, most users don't have a need for Dump because it is mainly for diagnostic purposes used by people who know what the dump contents mean. But if you are the curious type (like me) and want to see what a dump of the IS looks like, by all means run one. It won't hurt anything.

EDBUTIL


EDBUTIL is another useful tool for analyzing the state of the Exchange databases. It is a companion to ISINTEG. But whereas ISINTEG looks at only the public and private stores, EDBUTIL additionally looks at the Directory Service database (DS). The executable, EDBUTIL.EXE, is automatically installed in the \EXCHSRVR\BIN directory on the Exchange server during setup.

You must run EDBUTIL on the Exchange Server machine, and you must stop the MSExchangeIS service before you use any EDBUTIL utility.

See Appendix B to see the complete syntax. Also, you can run EDBUTIL with no parameters from a Windows NT command prompt to list the syntax on the screen.

EDBUTIL is really a suite of database utilities, and you invoke a particular utility in the suite by running EDBUTIL with the appropriate parameter. The EDBUTIL utilities do the following for you:

Let's look at why you use these utilities.

Defragmentation

In the case of Exchange databases, defragmenting the database is synonymous with compacting the database. You can run defragmentation on the information store and the directory.

Everyone knows about the benefits of defragmentation for a hard drive. It organizes the data to be stored in a more efficient manner by making the data on the drive contiguous. In the case of a hard drive, it doesn't necessarily save space but it puts all the data together rather than spread it out over the drive.

With Exchange databases, defragmentation can save disk space.

An Exchange database takes up space on the hard disk. In a fragmented database, there is active data mixed in with unused or deleted data. This deleted data doesn't always get cleaned up as the database grows, so the database gets larger as time goes on. Eventually, for example, you may have a 1GB database, but only 75 percent of that is active data. The other 25 percent is trash. After a defragmentation, all the active data is collected and put together contiguously so as to require only 75 percent of its former bulk to store it. The other 25 percent is then released. Defragmentation just bought 250MB of disk space.

The command to compact the private store looks like the following:


EDBUTIL /D /ISPRIV

Using the /ISPRIV, /ISPUB, and /DS switches, the utility automatically finds the databases based on their locations recorded in the Windows NT Registry.

There are several handy options in the deframentation utility, so check the syntax closely for more details.

The amount of time it takes to run EDBUTIL depends on the database size and the speed of the computer. A 100MB database can defragment in less than 10 minutes.



You must have enough free disk space to run defragment. The amount of free disk space required is equal to the size of the database that is being defragmented. This is because EDBUTIL makes its compacted copy of the database as it works. For example, if you have a 2GB database to defragment, 2GB of free space will be enough for EDBUTIL to perform the defragmentation.


Recovery

Recovery performs the task of committing all the transaction logs to a database. This utility "plays back" the transactions that are logged and commits them into the database.

Run Recovery only if you have a good reason to run it, because the IS normally manages its logs just fine on its own. And if you happen to damage the database logs, you can really mess up your IS databases. Usually you run this utility because someone at Microsoft technical support told you to, and never just for fun.

Consistency

Consistency is a read-only utility used for scanning the database to find any unreadable records. It is similar to ISINTEG in that it seeks out problems in the target database. But unlike ISINTEG, it doesn't try to fix them.

It's mainly just a way to check out a database to see if there are any problems with it. The length of time to complete depends on the database size and the speed of your server. You can check a 100MB private store in less than 10 minutes.

Upgrade

Upgrade upgrades an existing database to a new version of Microsoft Exchange Server. This is not really applicable in the initial release of Exchange so its purpose is reserved for future use.

For example, suppose you have been running on Exchange 4.0 for a while. Now Exchange Server 4.1 is out and you want to upgrade to it and retain all your database information. However, the database architecture has had some improvements in 4.1, so a 4.0 database doesn't work with the 4.1 executables. You can use the upgrade feature of EDBUTIL to upgrade your database to the new revision. Of course, one expects the upgrade process to handle that for you, but that's another subject.

File Dump

As with ISINTEG, the dump utility is mainly for diagnostic purposes. Go ahead and run it to see what it looks like. It's harmless.

MTACHECK


MTACHECK is a straightforward utility. It is to the Exchange Server MTA what ISINTEG and EDBUTIL are to the Exchange Server IS. Neither ISINTEG nor EDBUTIL do anything with the MTA—that's where MTACHECK comes into play.

The executable, MTACHECK.EXE, is automatically installed in the \EXCHSRVR\BIN directory on the Exchange Server during setup.

MTACHECK cleans up the MTA. This means it looks for and removes old objects lying around in the MTA queue that are causing problems. For example, if the MTA doesn't seem to be routing messages, if it's routing very slowly, or if the MSExchangeMTA service doesn't start at all, there might be something in the queue causing the problem. MTACHECK removes anything that shouldn't be there, and it rebuilds the queue so the MSExchangeMTA service starts again.

Its syntax is simple. The following is the typical syntax to use:


MTACHECK /V

You can run MTACHECK with a -? to produce the syntax. The options are very limited, however. Basically you can specify a verbose mode with /V and you can specify an output file, and that's about it.

You must stop the MSExchangeMTA service before running MTACHECK. Also, the directory called MTACHECK.OUT must be empty—that is where MTACHECK puts its trash.

Exchange Optimizer


Microsoft Exchange Optimizer is another useful tool that helps you troubleshoot an Exchange system. It sets the Exchange system parameters to the proper values.

If Exchange system parameters are set improperly—maybe someone messed around with them, or maybe they weren't set after installation—the Exchange server doesn't run well. So if your Exchange server seems to be performing worse than you think it should, run Exchange Optimizer and let it make some suggestions about how to set your Exchange system parameters.

The Exchange Optimizer is covered in detail in Chapter 6, "System Requirements."

Inbox Repair Tool


You use the Inbox Repair tool to repair defective personal store (PST) files; you use it if something is wrong with your PST file.

The executable, SCANPST.EXE, is actually installed with the client, not the server, and it is represented by one of the icons in the Exchange group. It is similar in function to the check MMF feature found in MS Mail.

Inbox Repair performs eight checks on the selected PST file. Its basic goal is to validate, to scavenge, and to rebuild the b-tree structure of the personal store in order to get it back in operating condition again. After you initiate it, Inbox Repair functions without user intervention unless it finds a problem. Although rare, if it does discover something wrong with your PST file, and it needs to inform you of something or needs your input, the Inbox Repair Tool will prompt you.

Message Tracking


You use the Message Tracking facility in the Exchange Administrator to track the path of messages through entry and exit points in the Exchange server.

Messages are tracked in two main places:

These two Exchange Server entities handle all the messages on a particular server, so if you track messages that pass through them, you track all the messages on the server.

Optionally, you can track messages in the Internet Mail connector and the Microsoft Mail connector if you have them installed.

Enabling Message Tracking


Enable message tracking in the IS to handle those messages that do not leave the local server. For example, if Shelly sends Katie an e-mail and they both have their mailboxes on the same Exchange server, the message never has to go to the MTA. It is handled solely by the IS.

Enabling message tracking in the MTA to handle those messages that go outside the local Exchange server. For example, if Shelly sends Tiffany an e-mail, and they have their mailboxes on separate Exchange servers, although both servers reside on the same network, the message must be handled by the MTA. Additionally, enabling message tracking provides tracking of messages sent to distribution lists because the MTA is responsible for expanding distribution lists.

However, be advised that message tracking does not follow a message onto the Internet or an X.400 public carrier. There is no way to track e-mail during the time it is outside the Exchange network.

For example, Shelly and Lynda both work for the same company, but Shelly is based in Texas and Lynda is based in Florida. When Shelly sends e-mail to Lynda via the Internet, the e-mail proceeds from Shelly's Exchange server to Lynda's Exchange server via the Internet using the MTA and the IMC on each server. The administrator can track messages up to the point where they are handed off from the MTA of Shelly's Exchange server to go out to the Internet, and then again at the time they are picked up by the MTA of Lynda's Exchange server after coming in from the Internet. But the e-mail cannot be tracked in transit from Texas to Florida, while it is not being handled by an Exchange server.



When message tracking is enabled, it applies to all Exchange servers in the Exchange site, not just to a single server.

Message tracking is not automatically enabled; it is enabled by way of the Exchange Administrator program. For the IS and MTA you can find the message tracking feature in the Information Store Site Configuration and the MTA Site Configuration objects, respectively. These are located in the Exchange Administrator under organization\site\Configuration as shown in Figure 22.3.

Figure 22.3. Message tracking is enabled in two places in the Exchange administrator.

For each object, open the properties page, look in the General tab, and check the Enable message tracking check box.

As soon as message tracking is enabled, all messages that pass through that object—either the IS or the MTA—are tracked in an ASCII log file kept in the \EXCHSRVR\TRACKING.LOG directory. A new file is created each day, based on Greenwich mean time, and it is named using a format of yyyymmdd.log. For example, if you enable tracking on June 2, 1996, the filename is 19960602.LOG.

Disabling Message Tracking


Enabling message tracking enables it for all Exchange servers in the site. But what if you don't want that? What if you want to disable tracking on a server?

You disable message tracking on a particular Exchange server with the Windows NT registry on that computer. After you disable the computer, it is excluded from the message tracking activities.

You disable the IS and the MTA separately as you do when you enable message tracking. If you have the IMC and MS Mail connector installed, you must separately disable it for those as well.



You must enable message tracking on all Exchange servers for a message to be fully tracked up to the point of delivery. If one server in the path has message tracking disabled, the message is tracked until it reaches the server that doesn't have message tracking enabled.


IS

To disable message tracking for the IS of a particular Exchange Server computer, look in the registry under HKEY_LOCAL_MACHINE and find the key \CurrentControlSet\Services\MSExchangeIS\ParamtersPrivate. Under this key there is a value called X.400 Service Event Log. If it is there, set it to 0 (zero). If it is not there, create it and set it to 0. Its data type is REG_DWORD.

MTA

To disable message tracking for the MTA of a particular Exchange Server computer, look in the registry under HKEY_LOCAL_MACHINE and find the key \CurrentControlSet\Services\MSExchangeMTA. Under this key there is a value called X.400 Service Event Log. If it is there, set it to 0 (zero). If it isn't there, create it and set it to 0. Its data type should be REG_DWORD.

Using Message Tracking


After you enable message tracking you must restart the Exchange services to activate the message tracking facility.

To actually use the facility, from the Exchange Administrator select Tools | Track Message. It asks you which server you want to connect to, and then brings up the Message tracking center. You are immediately prompted to enter parameters to select a message to track as shown in Figure 22.4.

Figure 22.4. The message tracking center is activated from within the Exchange Administrator.

The details of operating the Message tracking center are covered in the Microsoft Exchange Server Administrator's Guide in Chapter 17, "Troubleshooting Tools and Resources."



Tracking can cause server performance degradation. For example, if you enable tracking on everything in all servers in the site, expect to see some performance degradation. The degree of degradation is impossible to say. It depends on how much tracking is going on, how powerful the servers are, how much message activity there is, and other factors.


Windows NT Administrative Tools


Microsoft Exchange Server includes some useful tools to help you troubleshoot a server. However, it doesn't stop there. Windows NT Server itself has some tools that are also helpful in diagnosing problems with an Exchange Server.

Each of these three tools is found in the Administrative Tools group that is installed with Windows NT Server.

Event Viewer


Probably the most useful of these three tools is Event Viewer. In fact, Event Viewer is usually the first place you should look if something goes wrong with anything in Windows NT.

An event is simply anything noteworthy that happens in Windows NT that gets logged in the event log. So any entry listed in the event log is referred to as an event.

Figure 22.5 shows a typical event log screen. This one just happens to be a view of the system log events.

Figure 22.5. The Windows NT Event View contains entries for each event that happens in Windows NT.

The event log is continuous; that is, it does not distinguish between days or weeks or months. It logs each event as it happens with a date and time stamp. It's easy to see where the log starts. There is always an event with a source of EventLog in the system log that marks where the event log starts. The one highlighted in Figure 22.5 illustrates what I'm referring to.

There are three types of events that are logged: system, security, and application. Of those three, system and application usually get the most activity under normal circumstances.



Many times when there is an event in one log, there is a corresponding event in one of the other two logs that provides additional detail. Always check all three logs for related event entries so you can get as much information as possible about the event.

When something goes wrong with Exchange Server, the event log is a good place to start looking for the problem. Exchange is very good about logging what happens to it, and many times it points you directly to the problem.

Using Event Viewer

For example, if an Exchange server service does not start, an event is logged in either the system log or the application log, or both. There is usually a description of the problem along with relevant error codes and information.

Figure 22.6 shows a sample Application log.

Figure 22.6. The Exchange-specific events are logged in the Application log.

As you can see, there are several application events. Although some of the letters in the Source column are cut off (the column cannot be widened), among the events are Exchange-specific events:

This is a busy server.

Figure 22.7 gives you a feeling for how the events are helpful. In this figure, the event highlighted in Figure 22.6 is opened to show the event detail.

Figure 22.7. The event log can be quite helpful in assisting with diagnosing the cause of problems with Exchange services.

In this case, the IMC doesn't start because there is no domain name set in the TCP/IP configuration. A pretty simple thing to fix, but without this log entry it likely would have taken longer to figure out what the problem is.

Unfortunately, not everything is always this perfect. The level of detail in the log depends upon the type of error. Sometimes it is cut and dry as in the example. But sometimes it isn't quite so specific. That's where the other tools discussed come in handy.

However, most of the time, the event log doesn't let you down. It at least points in the right direction and gets you on the road to correcting the problem.



I recommend you check the event logs each day. Sometimes things can be going on in the system that aren't obvious. If you check the logs regularly, it helps ensure there isn't anything going on you don't know about.


Viewing Logs on Other Servers

Another convenient feature of the Event Viewer is that it provides a way to view event logs on other computers on the network. This can be handy, especially if you are trying to diagnose a problem just by looking from your desktop.

Select Log | Select Computer, and choose the domain and computer whose logs you want to examine. It's that simple.

Server Manager


You use the Windows NT Server Manager for several different tasks in the context of Windows NT networking. However, in the context of Microsoft Exchange Server, it is the most useful for enabling you to examine the services on a Windows NT Server on the network that is running Exchange Server.

From the main screen of Server Manager, highlight the computer name whose services you want to check, and select Computer | Services. You then get a list of the services on that computer.

Say you discover that an Exchange server has suddenly stopped responding to users. Every time a user attempts to connect, he or she cannot open the information store.

The first thing to do is check to ensure all the Exchange Server services are running on the server, especially the MSExchangeIS service. By opening the Server Manager and checking the services, it is simple to check and see if the proper services are actually up and running on the server.

Of course, there are the other standard Windows NT security items you can check with Server Manager. For example, you can make sure the Exchange Server computer name is listed in the NT domain. If it isn't, the computer isn't able to function in the domain. Maybe there are problems with shares; those can be checked too. Also you can check what users' sessions are active on a server to see if anything looks funny that way.

User Manager for Domains


User Manager for Domains is another troubleshooting tool. Like Server Manager, you use this program to administer NT security for the domain. NT security is one thing to always keep in mind when you are troubleshooting an Exchange server. Many problems can occur simply because someone doesn't have the proper user rights.

But aside from all the usual security issues, there is one special thing about User Manager for Domains. When Exchange Server is installed, User Manager for Domains is enhanced with an Exchange extension as shown in Figure 22.8.

Figure 22.8. The Exchange Setup program automatically installs an extension to User Manager for Domains.

This feature enables you to set an option to create and delete Exchange mailboxes when you create and delete NT user accounts. It also enables you to view Exchange property pages for the selected NT user account.

So although this particular tool might not help much with tracking down why your server crashed, it certainly helps when you are trying to sift through lists of users to see if the proper permissions exist on different mailboxes.

Summary


This chapter covers several tools available to assist in diagnosing the cause of a problem with an Exchange Server computer.

First, it discusses the diagnostic tools included with Microsoft Exchange Server: RPC Ping, ISINTEG, EDBUTIL, MTACHECK, and some others.

Next, it looks at the Message Tracking Center, which is the message tracking utility included in the Exchange Administrator. This utility provides the capability to track the path of a message through the system.

The chapter finishes by covering a few Windows NT Server administrative tools that prove helpful in troubleshooting: Server Manager, User Manager for Domains, and Windows NT Event Viewer.

Hopefully, you won't have to use the tools covered in this chapter very much. It would be great if your Exchange installation has no problems, wouldn't it? However, it's not a matter of if problems occur, but when.

With that in mind, the overriding issues to remember about troubleshooting is that there is no hard and fast rule about how to diagnose the cause of a problem. It's really a matter of using the tools you have, knowing what the tools are telling you, and learning how to fish.

Previous Page Page Top TOC Next Page