Link to home
Start Free TrialLog in
Avatar of Infrastructure Team
Infrastructure TeamFlag for United States of America

asked on

Default Mailbox Database on Exchange became dismounted due to carelessness

The C: volume on the exchange server grew to 98% full and someone deleted log files from the Mailbox Database folder.  After that we lost the local database and get an error even migrating mailboxes that are not even on the dismounted DB.  Here is the error when I try to mount:
"Failed to mount database "Mailbox Database 1621109887". Error: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108) Diagnostic context: Lid: 65256 Lid: 10722 StoreEc: 0x454 Lid: 1494 ---- Remote Context Beg ---- Lid: 1238 Remote Context Overflow Lid: 59596 dwParam: 0x48B72B6 Msg: JI06 Lid: 59596 dwParam: 0x48B72C6 Msg: JI07 Lid: 59596 dwParam: 0x48B7352 Msg: JI08 Lid: 59596 dwParam: 0x48B7E5E Msg: JI13 Lid: 43212 dwParam: 0x48B7E5E Msg: JT05 Lid: 43212 dwParam: 0x48B8217 Msg: JT08 Lid: 34760 StoreEc: 0xFFFFFE0B Lid: 41344 Guid: 3da05890-c04d-470d-b70b-fdd02e3150cf Lid: 35200 dwParam: 0x7FF0 Lid: 59596 dwParam: 0x48B8227 Msg: JI20 Lid: 43212 dwParam: 0x48B8227 Msg: JT05 Lid: 43212 dwParam: 0x48B8227 Msg: JT08 Lid: 59596 dwParam: 0x48B8227 Msg: WM19 Lid: 59596 dwParam: 0x48B8227 Msg: WM20 Lid: 59596 dwParam: 0x48B8237 Msg: WM21 Lid: 54472 StoreEc: 0x980 Lid: 42184 StoreEc: 0x454 Lid: 1750 ---- Remote Context End ---- Lid: 1047 StoreEc: 0x454 [Database: Mailbox Database 1621109887, Server: exchmb01.sdil.net]"


When I try to migrate it makes reference to "Unable to connect to the Microsoft Exchange Attendant"

This is not a production server but have started POC.  I have other databases on shared storage so they are protected but need to figure out how to get this one back to square one.

Help please!!
Avatar of Tom Cieslik
Tom Cieslik
Flag of United States of America image

If the Exchange log file was deleted

If the Exchange log file was deleted, you must restore the Storage Group database from a backup. Then, you must play through the log files. If you cannot restore the database from a backup, see next metod
If you cannot restore the database from a backup" section. To restore an available database, follow these steps:
Move all inconsistent databases to a backup folder.
If a new E00.log file was created, move the new E00.log file to the backup folder. Additionally, move the E00.chk file to the backup folder.
Copy all existing log files to the backup folder.

Note You must copy the log files. Do not move the log files.
Rename the last E00*.log file to E00.log.
Restore the database from a backup. Then, replay the log files. This brings the database to a consistent state. However, the database does not include the E00.log file that was copied to the backup folder. Although there is some data loss, you now have a database that can be mounted.
Start the Microsoft Exchange Information Store service.

If you cannot restore the database from a backup

If you cannot restore the database from a backup, you must run repair utilities against the database to bring the database to a consistent state. Then, follow the steps that are described above  If the Exchange log file was deleted" section.

Also you can:

To determine whether the eseutil /p command was run, follow these steps:
Click Start, click Run, type cmd, and then click OK.
Type the following at the command prompt:
c:\program files\exchsrvr\bin\eseutil /mh "c:\program files\exchsrvr\mdbdata\name of Exchange database.edb"
Note This example assumes the following:
The Exchange Server program files were installed in the c:\program files\exchsrvr folder.
Your database is in the c:\program files\exchsrvr\mdbdata folder.
Read the repair count attribute. If the repair count attribute is 0 (zero), the eseutil /p command was not run. If the repair count attribute is a number other than 0, the eseutil /p command was run on the database.
If the public and private databases are in a consistent or clean shutdown state, you can move the transaction log files to another folder. To determine whether the databases are in a consistent or clean shutdown state, follow these steps:
Click Start, click Run, type cmd, and then click OK.
To examine the private information store, type the following:
c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\priv1.edb"
To examine the public information store, type the following:
c:\program files\exchsrvr\bin>eseutil /mh "drive:\program files\exchsrvr\mdbdata\pub1.edb"
Note These examples assume the following:
The Exchange Server program files were installed in the c:\program files\exchsrvr folder.
Your database is in the c:\program files\exchsrvr\mdbdata folder.
Review the results of the consistency check. If a database is consistent (state = clean shutdown), all the log files have been committed to the information store. If the database is not consistent (state = dirty shutdown), the database may not be corrupted. The log files may not have been committed to the database yet.
If the state reports clean shutdown, move all the log files from all the mdbdata directories to a backup folder.
Mount the databases.

Also you can:

Use the correct switch to successfully run the command. The common logfile base names are e00, e01, e02 and e03. For example, the following command contains a correct logfile base name:
eseutil /r e00
Note If none of these resolutions work, contact Microsoft Product Support Services (PSS). For information about how to contact Microsoft PSS, visit the following Microsoft Web site:
Avatar of Infrastructure Team

ASKER

Here are my results below.  How do I reply Exchange Log Files?

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.01
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
         Database: c:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbo
x Database 1621109887\Mailbox Database 1621109887.edb


DATABASE HEADER:
Checksum Information:
Expected Checksum: 0x3a9ba5fb
  Actual Checksum: 0x3a9ba5fb

Fields:
        File Type: Database
         Checksum: 0x3a9ba5fb
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,20,0  (attached by 0)
 Engine ulVersion: 0x620,40,60  (efvCurrent = 8980)
Created ulVersion: 0x620,20
     DB Signature: Create time:11/04/2016 10:25:22.620 Rand:1806249132 Computer:

         cbDbPage: 32768
           dbtime: 388696 (0x5ee58)
            State: Dirty Shutdown
     Log Required: 26291-26393 (0x66b3-0x6719)
    Log Committed: 0-26394 (0x0-0x671a)
   Log Recovering: 26382 (0x670e)
   Log Consistent: 26291 (0x66b3)
  GenMax Creation: 12/04/2016 12:23:09.733
         Shadowed: Yes
       Last Objid: 2293
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00.000
 Old Repair Count: 0
  Last Consistent: (0x144,59,35D)  11/07/2016 14:20:13.966
      Last Attach: (0x145,2,268)  11/07/2016 14:20:39.884
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00.000
    Last ReAttach: (0x670B,2,268)  12/06/2016 15:51:51.044
             Dbid: 1
    Log Signature: Create time:11/04/2016 10:25:22.541 Rand:480946734 Computer:
       OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)

Previous Full Backup:
        Log Gen: 3975-4009 (0xf87-0xfa9) - OSSnapshot
           Mark: (0xFAA,1,0)
           Mark: 11/27/2016 09:10:39.674

Previous Incremental Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Previous Copy Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Previous Differential Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Current Full Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

Current Shadow copy backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00.000

     cpgUpgrade55Format: 0
    cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0

       ECC Fix Success Count: none
   Old ECC Fix Success Count: none
         ECC Fix Error Count: none
     Old ECC Fix Error Count: none
    Bad Checksum Error Count: found (60435)
Last Bad Checksum Error Date: 12/06/2016 15:51:51.075
Old bad Checksum Error Count: none

  Last checksum finish Date: 00/00/1900 00:00:00.000
Current checksum start Date: 00/00/1900 00:00:00.000
      Current checksum page: 0

  Database Header Flush Signature: Create time:12/06/2016 15:51:51.090 Rand:3335
773395 Computer:
 Flush Map Header Flush Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Co
mputer:


Operation completed successfully in 0.63 seconds.


C:\Program Files\Microsoft\Exchange Server\V15\Bin>
To resolve the warning, use one of the following procedures:
Restore data from online backup.
If there is no valid backup, repair the database by running the Eseutil /p command, and then run the isinteg -fix command on the affected store repeatedly until you receive 0 fixes or the same result for fixes two times. After you repair the database by using the Eseutil /p command and isinteg -fix, the database may not be stable and reliable. Because the repair process deletes database pages, data loss is likely. If you have to run a hard repair on your production database, we recommend that you move the data out of the repaired database to a new database or rebuild the database using the Move Mailbox command.
Now your database is dirty shutdown and to bring to clean shutdown we would required following log files

     State: Dirty Shutdown
     Log Required: 26291-26393 (0x66b3-0x6719)
Do you have the missing logs which is indicated by above ?

If you have backup of log files then you can run soft recovery to bring the database in clean shutdown state.

Perform soft recovery (Replay Logs) to bring the exchange database in clean shutdown state (Mountable State) :-

To Run soft recovery (replay log files)  ,

Go to Exchange Bin folder and run command (Before running the command move .chk file from the location)

 ESEUTIL /r e00 /L[path to log files] /d[path to database file] /i

Example:

ESEUTIL /r e00 /Lf:\mdbdata /dg:\mdbdata /i

Note :- Before running Eseutil /R with the /I option is highly recommended that you make a backup copy of your transaction log files, especially in a scenario when you are recovering databases but you plan to use these log files in the future after you have restored the missing database file, as the use of Eseutil /r makes changes to your Transaction log files and may change them so that future recovery of your missing database files is impossible.

Refer my article if you need more assistance

https://viralr.wordpress.com/2011/05/06/exchnage-store-dismounted/
If you don't have the backup of above log files then the only option left is to hardrepair exchange database to bring the database in clean shutdown state.

Please revert if you have any further questions ,we will be happy to help.
Gave the Softrecovery a try with no joy and go the error listed below:



C:\Program Files\Microsoft\Exchange Server\V15\Bin>eseutil /r e00 /L "C:\Program
 Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1621109887" /d "c:
\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1621109887
"

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.01
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: e00
            Log files: C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Ma
ilbox Database 1621109887
         System files: <current directory>
   Database Directory: c:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Ma
ilbox Database 1621109887

Performing soft recovery...
                      Restore Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ..................................X



Operation terminated with error -501 (JET_errLogFileCorrupt, Log file is corrupt
) after 229.875 seconds.
I really don't care about that DB other than I want to get it mounted in a good state.  Whether that be a different one I don't care.
Did you moved old log files out of directory before you attempt to repair database ?
Cleared out the Mailbox Database folder for the respective DB and copied over the raw files that I had from my last backup.  There was a folder, 22k+ logs, a tmp file and edb file.
ASKER CERTIFIED SOLUTION
Avatar of Viral Rathod
Viral Rathod
Flag of India image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
"Expert" delineation does not do him justice.  Wizard seems more suitable.  All posts were spot on and got me to where I needed to be. Thanks so very much!!!!