Jim asks about a situation where a mailbox restore is needed but the database hosting the mailbox is unknown.
If I need to restore a mailbox, and if Exchange is randomly provisioning the mailboxes to any of the allowed databases, how does one know which database needs to be restored to recover the data? Do we need to get more granular and regulary run scripts which somehow sorts the mailboxes into specific databases based upon attributes? Say DB1 is lastnames beginning with A-F, DB2 is G-M…etc?
I see two potential scenarios here:
- The mailbox has been entirely deleted from the organization, so we can’t simply use Get-Mailbox to look at attributes such as which database it is hosted on
- The mailbox has been moved around for general maintenance reasons or due to migration, and so a restore requires us to know which database it was on at the time frame that the data restore is targeting
In neither of those scenarios would I recommend a database layout scheme where specific databases are used based on surname or department or anything like that. Quite frankly such schemes are too unreliable (what if someone mistakenly places the mailbox on the wrong database?) and cause performance and capacity management issues (eg database grow at different rates).
Instead I would recommend the following.
For deleted mailboxes, your deletion process must include a mechanism to capture the database it is currently on, plus the move history of the mailbox.
For existing mailboxes, I recommend using the move history to determine where the mailbox was at the time of interest. You can view the move history for a mailbox using Get-MailboxStatistics and the -IncludeMoveHistory switch. For example:
[PS] C:\>(Get-MailboxStatistics alan.reid -IncludeMoveHistory).MoveHistory | select CompletionTimestamp,SourceDatabase,TargetDatabase | ft -auto CompletionTimestamp SourceDatabase TargetDatabase ------------------- -------------- -------------- 14/07/2014 5:41:27 AM MB-HO-04 DB01 8/01/2014 11:35:55 AM MB-HO-03 MB-HO-04 11/09/2013 11:35:24 PM MB-HO-01 MB-HO-03
The number of moves retained in the move history will depend on the version of Exchange Server and whether you’ve customized the MRS configuration.
- For Exchange Server 2010, the move history is 2 by default
- For Exchange Server 2013, the move history is 5 by default
You can customize the MRS configuration and change that value anywhere between 0 and 100. The MRS configuration is stored in the MsExchangeMailboxReplication.exe.config file found in the bin folder of the Exchange installation, for example C:Program FilesMicrosoftExchange ServerV15Bin.
You’ll find it on Exchange 2010 Client Access servers or Exchange 2013 Mailbox servers.
Look for the section in the file under MRSConfiguration.
A value of 5 is probably fine for most organizations, but if you have a high rate of mailbox moves in your org then increasing it may be wise.
Any changes you make to this value need to be changed on all other servers in your organization for consistency, otherwise you will not get the desired results. Also you will need to reapply the change after each cumulative update or service pack you install on the server.
For more information on using the move history and move reports see Tony’s post here:
Thanks. FYI – your backslashes didn’t show up in the article.
Hi Paul,
I use the movehistory parameter very often, but for some mailboxes or archive mailboxes, it’s just empty (and we recently moved all our mailboxes between databases, so I am sure there is at least one move).
I don’t get any error message, it’s just empty…
Any Idea ?
Thanks !
Luuke
Hey Paul
Lately few of our VIP mailboxes got moved to a different DB, I can dig what time the movemnet happen but I am unable to understand who moved them over.
Will you be able to suggest if there is any possible way figure this out.
Thanks in adavace & Nice article
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Admin audit logs should answer that for you.
https://www.practical365.com/exchange-server/use-admin-audit-logging-track-admin-changes/
Hi Paul,
Thanks for the article. Keeping the mailbox move history seems like a documentation nightmare when there is high employee turnover. This scenario is certainly a juggling act of priorities.
Jim
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Sure. I guess in a high turnover environment some level of automation for account decommissioning would be ideal. So this type of data collection could be inserted into that process pretty easily.