Articles in the "Reboot script for Exchange environment" series
- Patch and reboot script for an entire Exchange environment, Part 1 [This article]
- Patch and reboot script for an entire Exchange environment, Part 2
- Patch and reboot script for an entire Exchange environment, Part 3
- Patch and reboot script for an entire Exchange environment, Part 4
- Patch and reboot script updated to version 2.1
- Patch and reboot script updated to v2.4
Back in July, I posted a script that uses Microsoft Update to download and install hotfixes. That script is part of a bigger process that I use to patch all of my Exchange servers. I mentioned that the script for that process was forthcoming. It is a big script, and I have yet to post it because I am always tweaking it. But if I wait for it to be code complete, I will never post it. So this is the first post of what will be several to document what it does. This post will only cover the environment in which I am working and what the script requirements are.
First is the environment. It is wholly Exchange 2010 (as of this writing, all servers are SP1 RU6) on Windows 2008 SP2. There are over 8000 mailboxes, of which 1500 or so are shared. There are no public folders. Server and database infrastructure:
- Two data centers, one for production and one effectively for DR
- Primary data center:
- 2 HT/CAS servers behind a hardware load balancer (HLB)
- 2 UM servers
- 3 active MB servers
- 1 lag MB server
- Secondary data center (DR):
- 2 HT/CAS servers behind an HLB
- 1 UM server
- 2 MB servers
- DAG properties
- Single DAG that spans both sites
- 22 databases
- 2 copies of each database across the 3 mailbox servers in the primary data center, e.g., DB1 is on server 1 and 2, DB2 is on server 2 and 3, etc.
- All databases have a copy on the lag server
- Each mailbox server in the secondary data center has a copy of every database
- Each database has 5 copies total (including lag)
At my company, patch management is done by an application that has no awareness of Exchange, and reboots are simply staggered. This is not an acceptable solution for patching an Exchange environment that has high availability, needs databases to be balanced after patching, and ideally best practices are followed for suspending DB replication before rebooting, etc. As a result, these are the requirements for automated patching and rebooting of my Exchange environment:
- Process each server serially so that any problem that arises never affects more than one server, maintaining HA
- Move active copies of databases to other servers so there is zero impact to clients
- Suspend and resume replication of passive copies before and after reboots
- Balance active databases when all mailbox servers are complete
- Put servers in maintenance mode
- Send status notifications to mobile device
- Send detailed log when complete
- Gracefully exit if any timeouts are reached (patching, rebooting, service starting, etc.)
- Verify required services are started before moving on
My script, currently at 445 lines, meets all of these requirements. There are other things I intend to add to it, but I will go into detail after I have deconstructed the script for you in future posts. Part 2 of this series, which will cover the overall script structure and its first section (variables), will be published soon.
Download the complete script:
Reboot-ExchangeServers.zip (7.5 KiB)
No comments:
Post a Comment