Occasionally the mailbox would need to be recovered soon after it was deleted and if an administrator searched for the deleted mailbox in the console, the Disconnect Mailboxes would be empty:
If we were to check with PowerShell would come back with the same results using this code:
Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -eq "Disabled" } | ft DisplayName,Database,DisconnectDate
Source – Connect or Restore a Disabled Mailbox
Prior to Exchange 2013 (Exchange 2010 or 2007) the normal process was to run a ‘clean-mailbox’ cmdlets against either all mailbox databases or the single mailbox database where the mailbox that needs recover used to reside. Why would this be required? Simply put, Active Directory may know about mailboxes that are already disconnected, but have not been marked in the Exchange database as disconnected. Clean-MailboxDatabase will crawl AD to look for these disconnections and mark them in Exchange. Once this occurs, you can either manipulate the disconnected mailboxes in the GUI or with PowerShell.
Exchange 2013
With Exchange 2013, the cmdlets that we need to perform the AD check has been changed. The cmdlets we need is Update-StoreMailboxState. What does this mean for you? Well, the syntax for the cmdlets is a bit different now. For one, you can no longer specify which Domain Controller to run this on. I find this unusual as most Exchange PowerShell cmdlets seem to have this option. Second, ‘Database’ is the new parameter used to specify which database to check for disconnected users in. Next, the ‘Identity’ parameter no longer means the name of the database, but instead means the identity of the mailbox that needs to be checked in Active Directory. The identity switch allows for a more granular approach I would assume is to reduce the amount of time needed to fix one mailbox in a large environment. Lastly, the ‘Confirm’ and ‘WhatIf’ switches are still present in this cmdlets as well.
The recommendation from Microsoft is to first find the mailboxes in AD using this cmdlets:
Get-MailboxDatabase | Get-MailboxStatistics | Format-List DisplayName,MailboxGuid,Database,DisconnectReason,DisconnectDate
source – https://technet.microsoft.com/en-us/library/jj860462(v=exchg.150).aspx
However, this will get all mailboxes in an environment and we only need the disconnected ones. To simplify this, I wrote a pair of one-liners in PowerShell that would find ALL disconnected mailboxes:
$mailboxes = Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -eq "Disabled" }
foreach ($line in $mailboxes) {Update-StoreMailboxState -Database $line.database -Identity $line.mailboxGUID}
There should be no feedback from PowerShell to tell you if the cmdlets ran successfully or not. However, you should be able to reconnect the disconnected mailboxes now in Exchange 2013.
Opinion
Wow. I find this process a pain. Going from the old days or right clicking on a database and choosing “Run Cleanup Agent” in Exchange 2003, to a simple one-liner in PowerShell “get-mailboxdatabase | clean-mailboxdatbase [Exchange 2007/2010] and ending up with the mess I had to write just above this section. I really feel that, while the cmdlets are completely doable, they are certainly not user-friendly. This is especially true of the fact that you need to be able to feed the ‘Update-StoreMailboxState’ cmdlet both the database where the mailbox was, but also the ID of the mailbox that needs to be checked. While the options are welcome, the identity should have been left as the database name and an optional requirement for the mailbox could have been provided. This would have allowed an easier transition, easier to run as well as allowing further granularity in the cmdlets. Just my opinion, but I had when ‘updates’ only introduce complexity and not simplicity with optional complexity.
One More Note
So, if you’ve read the article, you’ll notice I don’t mention any way to do this in the EAC (the new ‘GUI’). Well, that’s because there isn’t a way to do this in the new Exchange 2013 Console. Like a lot of things in Exchange 2013, PowerShell is your only way to perform some sort of administrative action. While I am personally a huge proponent of PowerShell, I see this as a learning curve issue that could turn off an Administrator who just wants a visual on what’s disconnected or whatever they need. I hope this changes in the next version of Exchange. Administrators need to have a GUI options for some functions.
Resources
Clean-MailboxDatabase
Update-StoreMailboxState
