Exchange Server 2013 Maintenance

  • Article

It’s been a while since my last article; things have been quite hectic on the work front and I recently moved half way around the world to pursue some new and exciting challenges.

Seeing that cobwebs have been building in my little space on the Interwebs I decided that it’s time to throw something cool into the wild. 

Now that Exchange 2013 SP1 has been out I know from experience that customers are planning hard to get onto Exchange 2013, SP1 in any product is “believed” to be the “stable, what RTM should’ve been” version…..not sure I always agree with that, but everyone has their opinions, that’s what makes life so interesting.

Let’s jump right into it….Exchange 2013 maintenance.

You need to do some maintenance on your Exchange 2013 environment by setting a server into maintenance mode safely and efficiently.

First, you need to understand the supported process, there’s great content on TechNet covering maintenance here: https://technet.microsoft.com/en-us/library/dd298065(v=exchg.150).aspx#Pm

Now that you’ve gone through the process it might become obvious that you could potentially automate a whole lot of these commands that you need to run. And off course you could add some cool checks and tests and bells and whistles to make the process easier, more efficient and less error prone.

Sounds cool right, well, I’ve been working on something like this and I think it’s ready for some worldly love, attention and testing. Now many of you would say, well there are some scripts out there that do this, and I would say we have a lot of cars on the road….they all get you from point A to point B, but we all like to drive in style from point A to point B….right.

So, let’s talk about this script and most importantly the parameters it accepts.

The script is a one stop shop to add/remove your Exchange 2013 server to/from production rotation. The script will follow the procedures as outlined in the maintenance article in TechNet with a few additional checks and validations.

The process at a high level:

The following parameters are accepted by the script, depending on what you want to do and the script is able to execute everything from a central location.

  • [string]$Server:FQDN of the server you want to put into maintenance.
  • [string]$LogFolderPath: Self-explanatory (default is "C:\Temp\MaintenanceLogs").
  • [switch]$StartMaintenance: Start maintenance, remove server from production rotation.
  • [switch]$StopMaintenance: Stop maintenance, add server back into production rotation.
  • [switch]$balanceMailboxDatabases: Balance DAG databases after adding server back into production.

The only requirements for the script is Exchange Management tools.

Remove a server from production rotation:

.\E2013-Maintenance.ps1 –server ex15-02.uclabz.com –StartMaintenance –LogFolderPath c:\temp\logs

Add a server back into production rotation:

.\E2013-Maintenance.ps1 –server ex15-02.uclabz.com –StopMaintenance –LogFolderPath c:\temp\logs

Add a server back into production rotation and balance databases:

.\E2013-Maintenance.ps1 –server ex15-02.uclabz.com –StopMaintenance –balanceMailboxDatabases –LogFolderPath c:\temp\logs

Let’s take a look at some output examples.

If you follow the high level process depicted above you’ll see in the screenshot below, the script output is very verbose and the operator knows exactly what’s going on at any given moment. The output shows the steps the script follows when removing a server from production rotation and each line in code at that given point.

If any database move fails the script will bail, catching the Active Manager exception and request operator intervention. It will also test MAPI connectivity after databases have been moved to ensure they are mounted. If any databases are not mounted operator intervention is required at this stage, unless Active Manager fixes the issue automatically. 

The below shows what the script will do when adding the server back into production and the operator forgot to check if all services are started on the target machine. The test health function will essentially try to start these services. If any service is still unable to start the server will not be added back into rotation.

In the below example the script was able to start the services not running and then continued to add the server into production rotation.

The below shows an example where the logic was unable to find enough healthy copies during database pre-validation prior to moving the databases to a new target server, thus alerting the operator and then exiting.

In the final example below, the server was added back into production rotation and the balanceMailboxDatabases switch was specified which resulted in the script balancing the databases in the DAG using the built in database balancing script.

It’s important to note that if you haven’t setup your load balancing for Client Access Servers properly to be in sync with managed availability, i.e. you’re not checking for healthcheck.htm then CAFÉ roles will not be removed from the load balancing pool and client connections will still be directed to the server. Read more here: https://blogs.technet.com/b/exchange/archive/2014/03/05/load-balancing-in-exchange-2013.aspx

Now with any script that moves databases, changes component states and restart services I wouldn't advise anyone to just run this straight in production without making 100% sure it fits your needs, you understand what the output is saying, you are comfortable running it and that you've tested it in your QA/LAB/DEV or whatever environment first.

I've only had a chance to test this in my lab environment with 3 servers and 3 database copies. So if you have some larger test beds out there, please give it a bash and let me know how it goes.

Grab the script here.

Like always, I appreciate any feedback/improvements/ideas/fixes! #smileyface

Michael Hall
Service Engineer