×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

mailbox databases dismounting frequently without followable reason

mailbox databases dismounting frequently without followable reason

mailbox databases dismounting frequently without followable reason

(OP)
I have a 3 node DAG (EX2016, current patchlevel), 2 in "main" AD site and 1 in backup site. It's about 400 users homed in 9 mailbox databases currently. Since a few days on of the nodes in the main AD site doesn't keep db mounts anymore.
So, when i e.g. do a manual switchover, the db is mounted properly for some seconds. Then a store transient error occurs, results in a disablement of "readfrompassive" feature, dismounts the db again and failing over to node 1 again or node 3 - depending the load.
The "error structure" respectively the "process" happening when switching active copies to this server is always the same. I can reproduce it with every database on this server.
  1. Manual or automatic switchover to "node2" occurs, starting with Event 2090 informing about.
  2. Followed by 5 ESE informational events telling the log reply and db attaching.
  3. Then "MSExchangeIS" reports that the feature component "readfrompassive" (1061) has been re-enabled.
  4. Then the first error occurs "1001 - MSExchangeIS - MSEXCH info store encountered an internal logic error"
  5. Followed by an unhandled exception "1002 - processid perf counter (0) does not match actual process id.."
  6. Followed by a watson report error (4999) of the M.E.Store.Worker
  7. Only then the next error provides a bit (!) more information: "489 ESE - attempt to open edb-file for read only access failed with system error 32 (used by another process)"
  8. This is then followed by some Windows Error Reporting events (informational, 1001), some informational MSExchangeIS events (1021,40008,40036) ...
  9. Followed by another bunch of ESE events telling about log replays of the db about to be mounted ... ??
  10. Funny enough ...: Only then "MSExchangeIS - 40008" reports that the db has been mounted successfully.
  11. Stopping worker process (1021)
  12. Starting MapiAddressBookAppPool (2000,2001)
  13. "MSExchange Mid-Tier Storage" informs about "PICW Core feature not enabled" (11000)
  14. Now another 4999 error is logged about "MSExchangeDelivery, M.ExchangeStoreProvider, M.E.M.S.DeliveryItem..." crashing > stacktrace result "MS.Mapi.CrossServerConnectionPolicy.Apply"
  15. Followed by 2 Windows Error Reporting informational events
  16. And finally followed by a ExchangeStoreDB event (126) informing about that a db copy on this server caused an error which resulted in dismounts. The reason should be looked up in previous events (see above ^^)
  17. Referring this it looks like that the server is trying to mount a db 3 times by default .... ? Every time it results in more or less same error events.
What i have already tried:
  • purge one of the passive copies on problematic node, delete related files and recreate the passive copy again newly
  • -----Try to reproduce: Still failing as described above.
  • Review file/folder permissions on db and log storage locations (separated disks/volumes).
  • -----Actually there was an issue with partially incorrect permissions -> corrected all ownership back to administrators group and re-applied default permissions
  • ----------Unfortunately, this had also no effect at all - still same failing while activating db copy on this node
  • Sending server to maintenance mode and shut down, check dbs with eseutil: all in dirty shutdown state (but still mounting even though only for a short time??)
  • Read tons of kb articles and forum discussions related to such and similar behavior - no further insights unfortunately.
Any help, ideas, tipps & tricks are highly appreciated. :)

RE: mailbox databases dismounting frequently without followable reason

(OP)
In the meantime the troubleshooting/investigation continued. At the moment i'm looking specifically at permissions on files/folders in db and log drive.Could someone share the standard/default permissions on db-drive, subfolders and db/index files, as well as the same for the log-drive/folders/files?That would be really helpful to be able to reflect existing permissions.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close