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:
|
1 2 |
StartDagServerMaintenance.ps1 StopDagServerMaintenance.ps1 |
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:
|
1 |
Set-ServerComponentState SERVERNAME -Component HubTransport -State Draining -Requester Maintenance |
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…)
|
1 |
Set-ServerComponentState SERVERNAME -Component UMCallRouter -State Draining -Requester Maintenance |
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…
|
1 |
Redirect-Message -Server SERVERNAME -Target SOMEOTHERSERVER |
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…
|
1 |
Suspend-ClusterNode SERVERNAME |
5. Move active databases (If the server has a Mailbox role, otherwise skip)
It’s time to evict any active databases still lurking around:
|
1 |
Set-MailboxServer SERVERNAME -DatabaseCopyActivationDisabledAndMoveNow $True |
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):
|
1 |
Set-MailboxServer SERVERNAME -DatabaseCopyAutoActivationPolicy Blocked |
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:
|
1 |
Set-ServerComponentState SERVERNAME -Component ServerWideOffline -State Inactive -Requester Maintenance |
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:
|
1 2 3 4 5 6 7 8 |
# Check the components. They should be all Inactive Get-ServerComponentState SERVERNAME | ft Component,State -Autosize # Check the databases. should be all Blocked and True Get-MailboxServer SERVERNAME | ft DatabaseCopy* -Autosize # Should be paused Get-ClusterNode SERVERNAME | fl # Check if queues are drained (should have 0 messages): Get-Queue -Server SERVERNAME |
So now you can finally make your adjustments. Restoring the server to a full working order is a matter of reversing the process:
|
1 2 3 4 5 6 7 8 9 10 11 |
Set-ServerComponentState SERVERNAME -Component ServerWideOffline -State Active -Requester Maintenance Set-ServerComponentState SERVERNAME -Component UMCallRouter -State Active -Requester Maintenance Resume-ClusterNode SERVERNAME Set-MailboxServer SERVERNAME -DatabaseCopyActivationDisabledAndMoveNow $False Set-MailboxServer SERVERNAME -DatabaseCopyAutoActivationPolicy Unrestricted Set-ServerComponentState SERVERNAME -Component HubTransport -State Active -Requester Maintenance |
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