When you configure journaling in an Exchange organization you should also review the configuration of any databases that will be hosting journal mailboxes. Depending on the size of your organization and the way that you deploy journaling, there is potentially a very high volume of email messages that will be stored in the journal mailbox.
In some customer environments that I’ve dealt with there have been problems encountered such as:
- High volume of journal messages causes performance problems for the database
- Transaction logging for the database hosting the journal mailbox is much higher than other databases
- The content index for the database hosting the journal mailbox is constantly crawling, or regularly fails
I usually recommend the following practices for databases that will be hosting journal mailboxes:
- Host the journal mailbox on a dedicated database.
- Configure a larger transaction log volume for the database. In a properly sized environment this shouldn’t be necessary, but some customers like to run smaller t-log volumes, which is their choice to make, but they should consider an exception in this case.
- Enable circular logging only if the the database is hosted in a database availability group and has at least two copies. If the database has a single copy only, I do not recommend circular logging due to the risk of data loss if a storage volume fails. If transaction logging creates a risk of running out of free disk space on the t-log volume, and the volume can’t be made larger as recommended above, then I recommend running frequent incremental backups of the database throughout the day (usually 2-3 backups is all that is required, but your mileage may vary).
- Disable content indexing on the database.
Hi Paul,
Could you please suggest ways to migrate journal mailbox with 1 TB size from exchange 2010 to exchange 2016.
Hello Paul,
is it true that over time a journaling database grows to the sum of the individual databases (due to enabled indexing)?
We have a couple of EDBs with standard journaling enabled, which this is nightly archived.
Logs are truncated from backup, but our JournalinEDB grows over he weekend, actually it is 1,2TB with 1,5 million elements but we do not know te reason.
Actually I’ve created a new journaling EDB and moving the journaling mailbox to that EDB.
Should I disable indexing for that database?
Oliver
Paul,
We are in process of migrating exchange 2010 environment to exchange 2016. We are using enterprise vault for archiving solution. Our journal mailbox is hosted on exchange 2010 mailbox server with a dedicated database and its being archived with Symantec EV. My concern is :
1. When should we migrate journal mailbox to exchange 2016 ? Before migrating user mailbox to exchange 2016 or after migrating all user mailbox to exchange 2016?
2. Will journaling work if I am in the middle of migrating mailboxes? I mean I have 500 mailboxes. I migrate 250 mailbox to exchange 2016 and 250 remains on exchange 2010 server? How will the journaling works?
Thanks,
Sandip.
Hello,
Is there a way to move the Exchange Database (.edb files) into a Journaling mailbox without restoring the database on to Exchange?
Regards.
Hello, tell me please, what can I do with the “journal” folder? it burst up to 500 GB, can I just delete it?
Hi Paul
What process do you recommend for the Journal Mailbox and Database when migrating from 2013 to 2016?
I was thinking of creating a Journal DB and Mailbox on 2016, then switch to that.
If I create first, then change existing rule in ECP to point to new JournalMBX. Should I be stopping anything first, or will the ‘change’ cause a slight pause and carry on without missing any mail?
Is migrating the existing journal mailbox and contents a requirement? If so I would just move it. If not (i.e. you have an archiving product ingesting the journal mailbox contents) then your approach would be fine too. I don’t expect anything to be missed.
Paul,
We are running Exchange 2010 with a Journal Mailbox at 3TB with archive. It sits in its own database as well as the archive. I’m unable to perform a New-MoveRequest -Identity Journal -PrimaryOnly -TargetDatabase JournalDB -BadItemLimit unlimited -AcceptLargeDataLoss -AllowLargeItems. It freezes at 35% and I have to Remove-MoveRequest. There are over 18,000 corrupted items at 35%. We are migrating to O365 and this is part of a disk cleanup so, it’s necessary to move to another database. What do you suggest?
I would open a support case with Microsoft for that situation.
Our jounal mailbox is on a dedicated database on a dedicated physical server. We were asked by the management to retrive the mails. Since content indexing was disabled we were unable to extract mails using specific criteria. In a recovery environment we enabled content indexing, allowed it to run and then could extract the mails
Size of the mailbox/database — 1TB
Total items in DB to index 3,500,000.
I would not recommend disabling indexing. Index folder should go to backup.
If you need to search the journal mailbox then you’ll need indexing. But a lot of environments have journaling in place for third party archiving tools, they don’t keep the items in the journal mailbox permanently.
Hi Paul,
What do you recommend to implement the “they don’t keep the items in the journal mailbox”. After third party has archived the mail from journal mailbox, what would be the recommended way to keep the journal mailbox clean and from growing to big?
Thanks Paul!
Typically the system that archives the journal items will remove them from the journal mailbox as well.
got it, thats what I mostly implement. Just wanted to hear if you have any recommendation about any other steps to do this or If you’ve seen any problems doing it this way.
Thank you!