Eseutil Exchange 2010
Eseutil Exchange 2010 Commands
Beware! Eseutil is a dangerous tool in the wrong hands. Consequently I recommend that you practice on a test Exchange Server, or else begin with an innocuous switch such as eseutil /mh.
Having alerted you to the dangers, I want to emphasise that there will be circumstances where eseutil is a life-saver. (Or at least an email saver!)
Topics for Exchange 2010 Eseutil Commands
By highlighting the capitalization of this tool - ESEutil, the following facets of this command spring to my mind;
Whether you spell it ESEutil, Eseutil or plain eseutil, this built-in executable is three tools in one. A different switch controls each aspect of eseutil, furthermore, eseutil's switches are also case insensitive.
Simple Eseutil Commands to Replay Natural Actions
Classic Database Defrag
Troubleshooting - Death or Glory
Getting Started with Eseutil
An old trick is to copy the Address as seen in Explorer and then go to the command prompt, right-click and paste that path. (See diagram opposite.)
Alternatively, if you are going do a lot of command line troubleshooting, then it's worth appending the Path in the System Icon, Environmental Variables.
Scope of Eseutil in Microsoft Exchange 2010 Server
SolarWinds' Network Performance Monitor will help you discover what's happening on your network. This utility will also guide you through troubleshooting; the dashboard will indicate whether the root cause is a broken link, faulty equipment or resource overload.
What I like best is the way NPM suggests solutions to network problems. Its also has the ability to monitor the health of individual VMware virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you try NPM now.
The eseutil /m mode does not repair any of your Exchange files. Its main purpose is to provide you with information about the state of the database files. In particular to analyse a repair of the Exchange database file using the /p switch. However, I recommend that you start with this command to get a feel of eseutil database management ability.
Here is a simple switch to verify the state of an Exchange database. All that eseutil /mh does is to determine whether the last shutdown was clean or dirty. Eseutil /mh is also ideal to practice getting to the right path and executing eseutil without doing any harm to the mailstore databases.
To start with, familiarise your self with the names and location of the Exchange 2010 databases. My suggestion is to type this command from the Exchange Server\bin folder:
eseutil /mh "D:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage
Repair Count: 5
Examine the output for this line, 'State: Clean Shutdown' (or Dirty Shutdown). In passing, you can also see when the last backup occurred.
Another use of eseutil /mh is in disaster recovery where you want to see if eseutil /p has already been run. If 'Repair Count' is greater than zero, then you can see how many times eseutil /p has been tried already. In general, the greater the Repair Count, the less chance of a successful repair.
Eseutil / filename.edb > C:\logs\ExchHead.txt
Here is a free tool to monitor your Exchange Server. Download and install the utility, then inspect your mail queues, monitor the Exchange server's memory, confirm there is enough disk space, and check the CPU utilization.
This is the real deal - there is no catch. SolarWinds provides this fully-functioning freebie, as part of their commitment to supporting the network management community.
One scenario for Eseutil /k is to check a backup before you restore. The key verb is 'to check', while the key noun is 'header'. Just as checksum verifies a file's size, so by using eseutil /k you can verify the integrity of Exchange 2010's information stores. Another job for eseutil /k is to troubleshoot an Exchange 2010 database after an unscheduled shutdown of the Windows 2010 server. One point to note is that eseutil /k does not recover the database, for that you need the /r or /p switch - but be careful.
If you create additional mailbox stores, then check their corresponding .edb filenames.
Example: to check the default mailbox store = Mailbox Database.edb go to the command prompt and type:
Do not worry about uninititialized pages, it's normal to have several hundred in this category. However, what you don't want is bad checksums or wrong page numbers.
Another scenario is that you wish to check the transaction logs, in which case here is the command:
eseutil /k e00.log
As there are no spaces in the above file or folder names, you do not need to enclose the command with speech marks. However, to save disappointment, pay special attention to the path where the databases are stored.
You can also run checksum against a database on a transport server queue. By default, the database file name is mail.que.
Incidentally the CHKSGFILES Library programmatically verifies the integrity of the Exchange Server 2010 and database and log files.
Eseutil /d is probably the commonest, and possibly the safest of eseutil's switches. Firstly, think of 'd' for eseutil database. Secondly, realise that this /d switch works in the same way that Diskkeeper defrags a physical disk. Take the problem where Exchange's mailstore is huge and does not shrink even after you have deleted several mailboxes. You would like to recover the space occupied by the deleted mailboxes. Thus logon as a local administrator and run: eseutil /d.
If you really do not have enough free space try the Eseutil /d /t "f:\temp.edb". Where the f drive has enough free space.
Take a reading of the store size before and after running eseutil /d. Naturally, remember to remount the store once the defrag has finished.
Defrag Queue Database
LEM will alert you to problems such as when a key application on a particular server is unavailable. It can also detect when services have stopped, or if there is a network latency problem. Perhaps this log and event management tool's most interesting ability is to take corrective action, for example by restarting services, or isolating the source of a maleware attack.
Yet perhaps the killer reason why people use LEM is for its compliance capability, with a little help from you, it will ensure that your organization complies with industry standards such as CISP or FERPA. LEM is a really smart application that can make correlations between data in different logs, then use its built-in logic to take corrective action, to restart services, or thwart potential security breaches - give LEM a whirl.
Once that Mailbox store is started again, uncommitted transactions in those logs are written to the database. Also remounting the store triggers a built-in soft recovery routine.
Controlling the Checkpoint File
When you run a soft recovery, usually you want to move (or delete) the checkpoint file. This is because you will want to be safe and replay all the transaction logs. It is possible to control the checkpoint file during a soft recovery, by adding the /S switch to the recovery command:
Eseutil /r E00 /Sd:\checkpoint\
Typical Scenario for Eseutil /r
Firstly, make the best of a bad situation and backup the Exchange database as it is NOW. Then navigate to the folder containing the transaction logs, now try: eseutil /r e00 /i . Note the sequence /r e00 /i is correct. This assumes that your first, or base log is e00 not some other number. If you have a storage group with multiple stores, I am afraid that you have to dismount all stores before running the /r switch. Perhaps this reminds you that all members of a storage group share the same transaction log.
Syslog messages contain useful information for troubleshooting network problems. When something goes wrong then surely there will be an error message in the syslog datagram - if only we can find that record and interpret the event.
Here is a utility to capture and analyze network messages. The Kiwi Syslog Server filters messages and creates advanced alerts. View your syslog data via web access.
Scenario. You need to recover a store.edb database, you tried the last backup, but that was no good. Perhaps the root cause is the corresponding transaction logs are missing. You may see the error message: 'The database files in this storage are inconsistent'. Next step, gather more information try eseutil /mh. You determine that the state is inconsistent, after backing up the current database, try eseutil /p.
Follow up you repair of the database with Eseutil /d. This not only defrags but also rebuilds indexes. Finally switch to the Isinteg.exe utility and try: isinteg -fix. This Information Store Integrity Checker can repair the database at the application level.
Another spiteful problem is that you cannot backup the store. Perhaps the root case was a hardware malfunction. As a last ditch measure, you could try using eseutil /p. I was going to say backup before you try, but of course, in this instance, backup is the problem! How about a little lateral thinking and try to copy the store before you run eseutil /p.
In Exchange 2010 Eseutil /p can also repair the transport queue database on the Hub server.
The purpose of the /cc in Exchange 2003 was to force the ESE engine to replay the log files. In Exchange 2010 server, this capability has been superseded by LLR (Lost Log Resilience). The built-in LLR feature which protects Exchange databases from losing the most recent log files. LLR is most important when CCR (Cluster Continuous Replication) is in use.
You can run Eseutil in log recovery mode with the /a switch. Navigate to the folder containing the database where the LLR-protected log file is missing then experiment with this command:
Eseutil /r E00 /a (E00 maybe different on your server)
Here follows the Exchange 2003 server routine
A common scenario for this /cc switch is that you have just restored an Exchange mailstore from last night's backup and you want to replay today's logs. Eseutil /cc would achieve your goal provided you issue the command from the folder that contains the Restore.env file. This special file (Restore.env) carries information about the restore in general and the log sequence numbers in particular.
Command: eseutil /cc path to restore.env
Eseutil /cc gets the restored database up-to-date through a hard recovery process. Hard recovery replays the transaction logs after a backup, either select the 'Last Backup Set' checkbox, or use eseutil /cc. Remember that eseutil /cc looks for instructions in the Restore.env file. Perhaps you can see what I mean when I say that some aspects of Eseutil are just command line methods of controlling Exchange 2010.
In cases where you are short of disk space, call for the temp switch. Eseutil /cc "name of temp folder" /t. Naturally you would need to substitute "name of temp folder" for a real folder.
There is a sister command just to check the contents of restore.env : eseutil /cm path to restore.env
Likely contents of restore.env would include paths to source files. Names of databases .edb and .stm files. See more on restore.env here.
If you delve more deeply, you find that eseutil /c has a whole family of commands e.g. cc /ch.
Eseutil /cm - Read Restore.env
Error -501 (0xfffffe0b) JET_errLogFileCorrupt
Error -515 (0xfffffdfd) JET_errInvalidLogSequence
Error -530 (0xfffffdee) JET_errBadLogSignature
More Exchange 2010 Troubleshooting Tools
Database Recovery Management
To access these tools:
Full list of Eseutil Switches for Exchange 2010 Server
Eseutil /? The best way to learn more about these Eseutil switches.
Eseutil /a (New switch for Exchange 2010) LLR replays logs.
(Eseutil /cc Performs a hard recovery after a database restore. Exchange 2003)
Eseutil /d Performs an offline compaction of a database.
Eseutil /g Verifies the integrity of a database.
Eseutil /k Verifies the checksums of a database.
Eseutil /m Generates formatted output of various database file types. e.g. /mh
Eseutil /p Repairs a corrupted or damaged database.
Eseutil /r Performs soft recovery to bring a single database into a consistent or clean shutdown state.
Eseutil /y Copies a database, or log file.
Summary - Microsoft Exchange Server 2010 Eseutil
Eseutil is a powerful command-line utility. It has at least three jobs, defragging stores, checking the .edb database files and repairing corrupted mailbox files or logs. My advice is to practice with the /mh switch before you have to use the eseutil /r (repair) switch on a live network.
If you like this page then please share it with your friends
See more Microsoft Exchange Server 2010 topics: