Can't mount database in Exchange 2010 - missing log file...

missing log files are never a good news !

any idea how the log file went missing ?

1. run eseutil /ml e00 and check which log file is missing
2. run eseutil /mh EDBfilename.edb and paste the result (check if it is clean or dirty shutdown)

come back to us with the above info

It is in a dirty shutdown mode.  I know that.  I'm running the "eseutil /ml e00" now and will get right back to you.  Thanks, sir.

Any idea how they got "lost" ? is circular logging enabled ?

The server was abruptly powered off...  I know, seems kinda strange...

The server is verifying logs now...  There are many logs...  almost two months' worth.  Circular logging is certainly not enabled, but most likely should be as the customer clearly lacks at backup routine.

Well...  it checked a bunch of log files and reports "no damaged log files found."

Here is the results of "eseutil /mh":

---BEGIN---

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

Initiating FILE DUMP mode...
         Database: .\mailbox database 1062822335.edb


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

Fields:
        File Type: Database
         Checksum: 0x128ea5d0
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,17
 Engine ulVersion: 0x620,17
Created ulVersion: 0x620,17
     DB Signature: Create time:07/09/2010 13:03:12 Rand:2308331 Computer:
         cbDbPage: 32768
           dbtime: 27220908 (0x19f5bac)
            State: Dirty Shutdown
     Log Required: 15380-15380 (0x3c14-0x3c14)
    Log Committed: 0-15381 (0x0-0x3c15)
   Log Recovering: 0 (0x0)
  GenMax Creation: 09/18/2010 13:52:44
         Shadowed: Yes
       Last Objid: 6848
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00
 Old Repair Count: 0
  Last Consistent: (0x3A76,8,1F)  09/16/2010 03:09:40
      Last Attach: (0x3A77,9,86)  09/16/2010 03:09:40
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00
             Dbid: 1
    Log Signature: Create time:07/09/2010 13:03:12 Rand:2303819 Computer:
       OS Version: (6.1.7600 SP 0 NLS 60101.60101)

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

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

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

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

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

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

     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: none
Old bad Checksum Error Count: none

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


Operation completed successfully in 0.63 seconds.

---END----

See anything helpful?

    Log Required: 15380-15380 (0x3c14-0x3c14)

do you have the logfile name e00..3c14.log

The last log file that I see in the directory is e00..3c10.log.

then you have 3c11 12 13 14 15 lost :(

You will need to run eseutil /P at this time but this will lead to loss of data

...running now...   thank you...

make sure you have enough disk space
it will require 110% free space as the databse size

So that's done...  now what should I do?  It created a temporary database.  

Database is now in "clean shutdown" mode but still won't mount.

1. Make a copy of the database and then you should run a eseutil /d before putting it back into production
2. I would also get a backup solution in place, unless the client really doesn't care about losing data