In recent years, Microsoft has put a lot of efforts to make database of the MS Exchange Server 2010 more secure than it used to be, but corruption still can and do take place. In the event of database corruption, exchange admins do have the opportunity to either restore a backup or attempt repairing the corrupt or damaged files with the help of inbuilt exchange tools - Eseutil and Isinteg. Sadly, it is not as easy as it gives the impression. There are a small number of nuances you should know, so it might be sensible to stick on to the following words of carefulness.
However, before using Eseutil and Isinteg tools, don’t forget to perform the following actions:
However, before using Eseutil and Isinteg tools, don’t forget to perform the following actions:
1. Create a Replica of a Database
Create a replica of the database files prior to repair them. If you are not confident where your database files are located, or what the names of the files are, you can locate them in Exchange System Manager by accessing the database properties. The Database page has a listing of file names and paths.
2. Dismount the EDB database from the Exchange server
Prior to trying to repair a database, you should make sure that it is dismounted properly. To carry out the same, open the Exchange Management Console (EMC) and navigate to Organization Configuration -> Mailbox, then choose the Database Management tab. This tab comprises of all the databases in your Exchange organization.
Find the database, you desire to repair and make sure that the Mounted column shows ‘Dismounted’.
If the database is mounted, you can dismount it by right-clicking the database and select the Dismount Database command.
Find the database, you desire to repair and make sure that the Mounted column shows ‘Dismounted’.
If the database is mounted, you can dismount it by right-clicking the database and select the Dismount Database command.
3. Disk Space
Confirm that you have enough disk space to perform the repair task. You should have the empty space of at least 20% of the total database size. If you are not having that much empty space on the drive where the database files are, you can use command line switches to redirect the temporary files formed throughout repair to a singular drive.
Exchange administrators can take the help of Eseutil and Isinteg utilities to repair corrupt exchange databases. Both Eseutil.exe and Isinteg.exe utilities are inbuilt with MS Exchange Server and facilitate soft and hard database recovery from the corrupt Exchange Server. By default, these tools are stored at the following drive location:
Exchange administrators can take the help of Eseutil and Isinteg utilities to repair corrupt exchange databases. Both Eseutil.exe and Isinteg.exe utilities are inbuilt with MS Exchange Server and facilitate soft and hard database recovery from the corrupt Exchange Server. By default, these tools are stored at the following drive location:
C:\Program Files\Exchsrvr\bin
Before I explain how to use ESEUTIL, I have a few words of caution. Even though now ESEUTIL does a better job of repairing databases than it used to be, there is still a high probability that you will lose some data when using it to repair an Exchange database.
ESEUTIL rebuilds the database and deletes any invalid data that it encounters during the rebuild process. Therefore, it is imperative that you back up the database before attempting a repair.
If you aren’t sure when the database was last backed up, you can get that information using ESEUTIL. To do so, navigate to the folder containing the database and enter the following command:
ESEUTIL /MH “<mailbox database name>”
Perform the following steps to run Eseutil.exe from command prompt:
1. Click on Start -> Run
2. In the run box, type “cmd” and press “ok”
3. Go to C:\Program Files\Exchsrvr\bin directory
4. Type Eseutil.exe in command line
Esutil.exe has two repair switches “/r” and “p”.
Eseutil /r command is soft database recovery mode of the Exchange Server.
If EDB files are badly damaged, then you should make use of Eseutil/p command. The command line to repair badly damaged public or private exchange database file is:
Eseutil /p C:\Program files\Exchsvr\mdbdata\ primary name.EDB
The simplest method to perform this is to have both database files (. EDB and.STM) in the same directory (which they typically are). If they are placed at different locations, then you need to point to the files on the command line.
Eseutil can be found in the \exchsrvr\bin directory formed when you install Microsoft Exchange on a server. You may need to put in \exchsrvr\bin to your system path for handiness.
Here is a loaded up Eseutil repair command line:
This command line will repair DB1.EDB placed in C drive along with its matching .STM file placed in D: drive and will place the temporary file on the E: drive.
If your streaming database file (.STM) is not matched to the database file (.EDB) or it has a problem that is blocking repair, you can repair it without adding the /createstm switch to the repair command line. This will destroy the .STM file and repair only the data in the .EDB file. What do you lose if you lose the .STM file? It depends upon what types of clients connect to your Exchange server. If everyone uses Outlook (MAPI protocol), then there will be very modest user data in the .STM file. You may lose some in the transfer of messages that have not been distributed yet. If clients connect via POP3 or IMAP, then most of the things will be in the .STM file, and its loss will be disastrous to them. If clients use Outlook Web Access, messages will be in the .EDB file, but attachments sent will be in the .STM file.
Repair can take some hours, but when it ends, it will leave you with a very comprehensive log file of what it did - call <database>. integ. raw.
Run Eseutil in /D (defragment) mode.
Repair may leave the index and space distribution tables in the database. Along with compressing the physical size of the file, defragmentation recreates the space trees and indexes.
To defragment the database, you need a space equivalent to 110% the size of the database.
As with repair, you can redirect the temporary file to a different drive if necessary, but this will take considerably longer.
2. In the run box, type “cmd” and press “ok”
3. Go to C:\Program Files\Exchsrvr\bin directory
4. Type Eseutil.exe in command line
Esutil.exe has two repair switches “/r” and “p”.
Eseutil /r command is soft database recovery mode of the Exchange Server.
If EDB files are badly damaged, then you should make use of Eseutil/p command. The command line to repair badly damaged public or private exchange database file is:
Eseutil /p C:\Program files\Exchsvr\mdbdata\ primary name.EDB
The simplest method to perform this is to have both database files (. EDB and.STM) in the same directory (which they typically are). If they are placed at different locations, then you need to point to the files on the command line.
Eseutil can be found in the \exchsrvr\bin directory formed when you install Microsoft Exchange on a server. You may need to put in \exchsrvr\bin to your system path for handiness.
Here is a loaded up Eseutil repair command line:
Eseutil /P c:\exchsrvr\mdbdata\DB1.EDB /Sd:\exchsrvr\mdbdata\DB1.STM /Te:\TEMPREPAIR.EDB
This command line will repair DB1.EDB placed in C drive along with its matching .STM file placed in D: drive and will place the temporary file on the E: drive.
If your streaming database file (.STM) is not matched to the database file (.EDB) or it has a problem that is blocking repair, you can repair it without adding the /createstm switch to the repair command line. This will destroy the .STM file and repair only the data in the .EDB file. What do you lose if you lose the .STM file? It depends upon what types of clients connect to your Exchange server. If everyone uses Outlook (MAPI protocol), then there will be very modest user data in the .STM file. You may lose some in the transfer of messages that have not been distributed yet. If clients connect via POP3 or IMAP, then most of the things will be in the .STM file, and its loss will be disastrous to them. If clients use Outlook Web Access, messages will be in the .EDB file, but attachments sent will be in the .STM file.
Repair can take some hours, but when it ends, it will leave you with a very comprehensive log file of what it did - call <database>. integ. raw.
Defrag the Exchange Database
Run Eseutil in /D (defragment) mode.
Repair may leave the index and space distribution tables in the database. Along with compressing the physical size of the file, defragmentation recreates the space trees and indexes.
To defragment the database, you need a space equivalent to 110% the size of the database.
As with repair, you can redirect the temporary file to a different drive if necessary, but this will take considerably longer.
- Run Integrity Check
- Run Isinteg in -fix -test -alltests mode.
- E.G. isinteg -s ServerName -test -all tests
Note: when you run Eseutil, you can move database files to temporary locations to make repairs. But to run Isinteg, you must put the database back in the location from which it is normally mounted.
At the end of an Isinteg fix run, you will perhaps observe hundreds of warnings. This is common as Isinteg was initially produced as an internal test utility. Just make sure that at the end of a successful Isinteg run, you have zero errors reported. Even if one error remains, you should run Isinteg once more.
If a small number of runs of Isinteg do not reduce the error count to zero, then you should not depend upon this database. You should then move mailboxes from it.
Don't run the integrity check more than 3 times as it is not suggested.
Some utter that you should anticipate spending an hour per gigabyte of data to get through the entire repair procedure.
You can relax now as this whole process will take at least 2-3 days to complete for the private mailbox store.
In case, Eseutil/ Isinteg tools doesn't fix the issue, you can go for professional Exchange Recovery tool like Stellar Phoenix Mailbox Exchange Recovery, that proficiently repairs any severely corrupt Exchange 2010 EDB file and restores all inaccessible mailboxes into a working PST.
At the end of an Isinteg fix run, you will perhaps observe hundreds of warnings. This is common as Isinteg was initially produced as an internal test utility. Just make sure that at the end of a successful Isinteg run, you have zero errors reported. Even if one error remains, you should run Isinteg once more.
If a small number of runs of Isinteg do not reduce the error count to zero, then you should not depend upon this database. You should then move mailboxes from it.
Don't run the integrity check more than 3 times as it is not suggested.
Some utter that you should anticipate spending an hour per gigabyte of data to get through the entire repair procedure.
Remount & Relax
Now remount the store using ESM and all should be well, only few emails will be lost when the server was off due to problems.You can relax now as this whole process will take at least 2-3 days to complete for the private mailbox store.
In case, Eseutil/ Isinteg tools doesn't fix the issue, you can go for professional Exchange Recovery tool like Stellar Phoenix Mailbox Exchange Recovery, that proficiently repairs any severely corrupt Exchange 2010 EDB file and restores all inaccessible mailboxes into a working PST.
0 comments:
Post a Comment