Exchange is a complex and large product which can have one thousand and one possible issues, one more obscure as the next. The purpose of this guide is to shed some light, where possible, to how things work in Exchange (and outlook), how they can break and how you should approach the issue at hand. Unfortunately it is very time consuming to create a complete troubleshooting guide where every dependency is explained in detail. But that is not the aim of this document anyways.
What is the aim? Give you, the engineer, a way to solve the most common of scenarios and information on how that piece of technology actually works. Note that there are a significant number of differences between the different versions of Exchange, which could give you a different solution for each problem.
In troubleshooting we need as much information as we can get. Not only do we need product knowledge but we also need to know what the problem is! Who, what, where and when would be the main pillars of that knowledge and the following items will allow you to question the client and narrow down the problem…
A number of questions (and follow ups) can be asked when contacting the user that will help you determine the scope, depth and impact of the issue. The following questions should give you an insight in to what is going on and help you determine where to look.
Maybe the most pinnacle of questions for troubleshooting an issue! With this you can add depth to the impact of the issue (CEO vs. cleaning lady) and if it is limited to only a number of users you know that similarities must exist, on some level, to have the issue occurring to a defined number of users. On the other hand, if everybody is having the issue, you can determine if the issue is occurring on the client or on the server level.
Determining the impact will help you prioritizing. It should also give you a level of understanding in what kind of solutions you can apply. If everyone is down, well, there is no real issue with going for disruptive actions as no one can currently access the system anyway…
You would be surprised in how much this can help you track down the source of the issue. Did it start today, yesterday or last week? Maybe even years ago (yes there are users that will wait years before reporting an issue and expect you to solve it in minutes >_<).
Apply common sense when asking this question. Some people will get offended but it can be very helpful in finding out if something broke or there is a setting wrong…
No problem without an error, that much is simple. Something not working, an outlook error code returned when connecting or something showing up in the event log. Each and every one of these will help you out in solving the issue faster and better.
With all the information you have obtained from the user you should be getting an idea on what is going on and what the impact of the issue is. If you know the solution to it, you can skip this section, on the other hand, if you need more information you can use the following tools to narrow down specific items and get more information on them.
Maybe the single most useful tool in helping you solve a problem! Exchange errors will be logged in the application log most of the time and rarely one or two in the system log.
ExBPA is a neat little tool built in to the Exchange Management Console allowing you to run some reports and get information on configuration errors in Exchange. Note that it can create performance baselines as well as check if the environment is ready for Exchange. If you are running Exchange 2003 you will have to download exBPA (here) as it is only present in 2007 and 2010.
Also known as ExTRA and just like the ExBPA it is built in by default in to the EMC. It contains a number of common troubleshooting paths and can be very useful to collect data automatically instead of having to scour through different manual paths. The version for Exchange 2003 is available here.
Yes, this little client can be helpful although it is limited in to testing mailflow. Remember that on windows 2008 and up you will have to install the client before you can be able to use it. Don’t worry though. No reboot is required J. Commands to test mail flow:
mail from: firstname.lastname@example.org
rcpt to: email@example.com
You can get more information on this from the following URL:
Increasing the event log levels is a great way to get more information on what is going on logged in the event viewer (as well as to get your event logs flooded). Slightly different to use in Exchange 2003 and 2007/2010 but the result remains the same.
Exchange 2003: Right click the server object in the Exchange system manager console and go to the “diagnostic logging” tab. Increase the logging to the highest level for the entries related to the issue you are troubleshooting.
Exchange 2007/2010: I prefer the powershell route to increase the logging in these versions of Exchange. You can get the current eventloglevel by using the following command:
From this you can mark and copy the desired item you want to increase logging on by using the following command:
Set-eventloglevel –identity “MSEXCHANGESA\OAL GENERATOR” –Level High
Note that you can also pipe these commands if you want to increase everything in a certain set.
Get-eventloglevel MSEXCHANGSA\* | set-eventloglevel –level high
You can find more information about the commands used and the different levels at the following technet link:
If you are running in to performance issues you can use the OS built in perfmon to see what is causing your slow down. A detailed description of the performance counters are available here:
This Microsoft website allows you to test autodiscover, RPC over HTTP and activesync connections. Note that you will need a username, password, domain name and email address to test the connections. No information is stored on the Microsoft servers so in theory you are not required to use a test account, yet I still recommend it.
More security oriented, the MS BSA allows you to scan for security updates present and missing from Exchange 5.5 servers and later. Download from here.
As the name of the tool suggests, this tool would be used to administer and troubleshoot public folders. Download from this location.
A great tool for database recoveries! This tool will fix the edb file by either replaying log files in to the database or changing the log file replays required to get out of a dirty shutdown. There are a number of different options to run with this tool but the most important ones would be the following:
· Check for shutdown state (/mh)
· Offline defrag (/D)
· Hard recovery
· Soft recovery
You can get more information on this tool right here.
This tool should always be used after running an eseutil repair. Whilst eseutil will fix the physical file it is not aware of the table structure used in an edb file. ISINTEG is specifically designed to fix the table structure where possible (and chuck the data if it is FUBAR).
To run isinteg your information store needs to be running so make sure that is happening. Typically you would run it in the following context
Isinteg –s servername –tests alltest –fix
More information is available here.
There are even more tools available from Microsoft that are not directly linked to troubleshooting yet still deserve a place in this document as they might come in handy at one point:
· Exchange 2007 Anti-Spam migration
· Exchange server Jetstress
· Exchange server stress and performance
· Exchange load generator
· Exchange server profile analyser
More information on these tools (and their download locations) can be found here:
Until next time!
Technorati Tags: Microsoft,Exchange,product,purpose,outlook,dependency,Give,scenarios,information,technology,Note,