One of the commands I like to use a lot on my Exchange 2010 databases is this one:

Every mailbox has two parts – the database object and the Active Directory object. All the content is – you’ve guessed it – in the database and things like e-mail addresses, alias, mail flow stuff etc. resides in the Active Directory object. That’s btw one of the reasons why Exchange desperately needs stable and instant connection to Active Directory….

But sometimes there is a need to separate these two. You may want to take away the content from one account and assign it to the other (why would you want to do that is a topic for another post) or you’re migrating the content from one Exchange database to another. Or even migrate the content from one Exchange version to another (newer).

In that cases the link between the two parts needs to be updated. Microsoft says it should be a very quick and automatic operation. From my experience, it takes a while. And waiting is annoying. You may want to try to run some scripts after the reconnection and in that case you’ll find out that these fail to complete. Or, in case of cross-Exchange move, the mailbox will not be accessible immediately.

That’s when the Clean-MailboxDatabase comes into play. It forces the update of the attributes and thus speeds up the process immensely. I like to use the command all the time. I have to admit that even in cases where there is no need for it. See… I have a relationship with it 🙂 And than you migrate to Exchange 2013 and the most favorite command disappears… After some searching I discovered the replacement command:

It basically does the same thing. But it’s way more difficult to remember, more annoying to write and so on. The command above updates the attributes for particular mailbox, not for all mailboxes in all databases (which is what I preferred).

I should point out that updating the attributes on all mailboxes of all databases might not be good idea if you’re working on a very large deployment, your servers are under a heavy load or perhaps if they’re in multiple locations with sub-optimal connection to each other.

But if you have the luxury to ignore these cases, it’s super-simple just to write command to do everything. In my cases, it’s usually quick and takes only few seconds. If you want to run an equivalent of the original command, you’ll have to resort to something like:

From a quick test I’ve done it takes a way longer to complete and, of course, transfers some load of the command from the server to the client (since it uses ForEach-Object). So I recommend selecting at least a DB:

My greatest gripe about this new command really is that it does not accept parameters via the pipeline well. For example, this command will not work:

And that’s despite the fact that Get-Mailbox contains all the information the Update-StoreMailboxState needs to work (ExchangeGuid and Database name). While I understand the insistence to use ONLY the ExchangeGuid as the only acceptable identity (you cannot use alias, SamAccountName, PrimarySMTPAddress etc.), the need to also specify the DB name is less obvious.

But perhaps the Exchange team thought I use the Clean-MailboxDatabase too much and tried to come up with a way to stop the overuse of it. They succeeded – I use it a lot less now 😀 Perhaps my (still yet potential) reads will have some valuable insight. I might have missed something (or didn’t realize it). Leave a comment! Thanks!

Sources: Microsoft TechNet 1, Microsoft TechNet 2