About Exchange 2013 maintenance

Since there are fundamental changes in how Exchange 2013 works in comparison to 2010 (for Exchange 2003 guys – circle is complete :-) ), I’m sure nobody will be surprised these handy scripts no longer work:

The curious thing is… they are still there. They no longer work, should not be used but they’re still present in the Scripts folder.

So what’s the mighty new solution to put one server into the maintenance mode so you can install patches, reboot it etc.? Did you expect some similar script? Because I surely did… No, of course. 😀 In the similar pattern to the “improvements” to Clean-MailboxDatabase, the new way is this:

1. Draining the Transport Queues

We need to ask our server to stop delivering messages:

If you want Exchange to register the change, you can restart the Transport service (+ Transport FrontEnd if your server is a multi-role one)

2. Draining Unified Messaging (if you have one, so most likely skip this…)

3. Redirect messages in local queues to a different server

I usually skip this one since my servers are fast and have close to no messages waiting. Plus I’m lazy like that…

4. Pause the cluster node (if the server has a Mailbox role, otherwise skip)

One good tip about this one – if you didn’t use “Run as Administrator” on your Powershell window, this one will probably fail…

5. Move active databases (If the server has a Mailbox role, otherwise skip)

It’s time to evict any active databases still lurking around:

This one will finish as quickly as the others but it may take some time for the server to actually switch the DB’s.

6. Disabling DB activation (If the server has a Mailbox role, otherwise skip)

This one just makes sure the Exchange will not decide to reactivate any DB during our maintenance (most likely due to failure of other Mailbox servers):

7. Activating the maintenance

Now it’s time to officially declare maintenance regime on the server. Don’t be confused by the misleading name of the component:


Your server should be in the Maintenance mode now. Easy, right? Well… as the say – if it were easy, everybody would do it 😀 But if you’ve read my previous post, maybe you’re starting to see a pattern with Exchange 2013…

Anyway, you can check the status of your server like this:

So now you can finally make your adjustments. Restoring the server to a full working order is a matter of reversing the process:


Of course, if you miss the easy old days of 2010, you can always make all of this into a script or two. I personally didn’t. Now when I think about it, I’m not really sure why… Because “pain in the butt” really does not do this a justice.

There is one more thing I’d like to touch on. That’s the burning question “Do I have to do it? Why just not to install patches and reboot?”. It will be another article.

Source (of wisdom): TechNet

So where is my Clean-MailboxDatabase on Exchange 2013?

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

About the new Blog


I’m Milan and this is my new blog. I used to write a blog a few years ago. It was in Czech language and contained some vaguely IT related stuff. Since then I’ve got myself pretty busy (and lazy to produce any content) and eventually I stopped writing.

So why start now again and in English? Several reasons. I’ve got this hard-to-describe “itch” for writing back. It seems my blogging burn-out is healed and I have finally (I hope) the idea what should I write about.

I decided to write in English even though it’s not my native “tongue”. The main reason is, it’s a good practice. I read, watch and listen to a ton of English every day. So my passive language skills are great. Recently I’ve got an opportunity to speak a bit. And the last part is obviously the writing. So hopefully you’ll excuse my more-than-usual language mess up (feel free to correct me in the comments section). The other advantage of not using language that can only be understood by about 15 million people (Czech + Slovak) is of course a way greater potential audience.

As I already have some experience with perils of content creation, I have decided to follow a few personal rules in hope of avoiding another burn-out:

1. Be brief
Creating content takes a lot of time. I often spent over 3 hours on single article. So I will not introduce every blog post (especially the technical ones) with detailed backstory etc. I will try not to over-explain stuff. Short article is a good article.

2. Don’t force creativity
If I’m not in a mood or don’t have time, I will not write anything. I will not let myself be pushed into creating new content just because there were no new posts for X days (weeks…).

3. Don’t spend extra time on polish
Adding extra content like pictures and making sure everything looks super nice takes a lot of time. Back to point 1.

4. Ignore naysayers
Everybody is a hero behind the keyboard. I will ignore all the negative people that will surely arrive. I will not engage them and I will likely delete the most offensive comments etc.

And what will be this blog about? IT stuff and some personal rumbling (I know – what a surprise!). I intend to publish mainly some stuff I encounter as an IT Admin (you can read about me here), however you can expect other geek related posts as well…

So as I see this post is already long enough, it’s time to go.