Exchange 2010 SP1 has been released, and comes with a slew of new and exciting features. Since we are all clamoring to get this installed in our environments, we should discuss how exactly we upgrade the members of our DAG so as to provide zero downtime to our users, and get our systems patched correctly.
From a high level view, remember we should be patching servers in the following order:
- Client Access Servers
- Hub Transport Servers
- Edge Transport Servers
- Mailbox Servers
The process we discuss in this article can and should be applied to ALL updates to members of a DAG, not just major updates like service packs.
In our environment we have three total nodes:
Let’s start with BOSDAGNODE1. Step one would be to move all active databases on BOSDAGNODE1 to another server. You want to ensure that it does not have any active databases on it. We can accomplish this in two ways.
In the EMC navigate to Server Config –>Mailbox. Select the server in question and then select Switchover Server:
Then you can either automatically choose a target server, or specify one yourself:
Or, through the shell, you can run the command:
Move-ActiveMailboxDatabase –Server DKPBOSDAGNODE1
This will do the same thing as the console, and will automatically choose a target server.
Next, we want to block DKPBOSDAGNODE1 from activating it’s databases. This will prevent other servers from failing over to it.
Set-MailboxServer DKPBOSDAGNODE1 –DatabaseCopyAutoActivationPolicy:blocked
Now you can upgrade the server to Exchange 2010 SP1!
After its finished, run the following command to re-enable activation of the node:
Set-MailboxServer DKPBOSDAGNODE1 –DatabaseCopyAutoActivationPolicy:unrestricted
Now, you can proceed on the other nodes until your finished!
One caveat you need to be aware of. Exchange 2010 RTM servers can failover TO a dag node member running Exchange 2010 SP1, but a server running Exchange 2010 SP1 cannot failover to a dag node member NOT running Exchange 2010 SP1. So make sure your entire DAG is upgraded in a timely fashion!
As for your schedule, note that I chose to do Boston, which is our DR site first, because NY would still be able to fail over to it in case of a DR situation. Next, I can do one node at a time in NY. This allows me to keep my mailboxes local to my production site, while ensuring that I am covered should a DR situation arise.