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

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