If you’ve performed maintenance on a database availability group member before, then you’re likely already familiar with the procedures for putting DAG members in and out of maintenance mode. If this is a new topic for you, here’s two articles describing how it’s done:
- Installing cumulative updates on Exchange Server 2016
- Installing cumulative updates and service packs on Exchange Server 2013
During that process, you set the ServerWideOffline component to an Inactivestate, using the requester of “Maintenance”. At the end of your CU install, you set the ServerWideOffline component back to an Active state, again specifying the requester of “Maintenance”.
There are multiple requesters that can be used to mark components active and inactive. We use “Maintenance” when we are doing maintenance, and there are others as well: Functional, HealthApi, Sidelined, and Deployment. If any one of the requesters has a server component marked as inactive, then the component will remain inactive.
Where this can trip you up is during maintenance, in particular two scenarios. First, let’s take a look at the ServerWideOffline component state of a healthy DAG member.
1 2 3 4 5 6 7 8 | [PS] C:\>(Get–ServerComponentState –Identity EX2016SRV1 –Component ServerWideOffline).LocalStates Requester State Timestamp Component ————– ——– ————– ————– Functional Active 15/03/2016 8:28:29 PM ServerWideOffline Maintenance Active 16/03/2016 10:07:07 AM ServerWideOffline HealthApi Active 14/03/2016 6:50:26 AM ServerWideOffline Sidelined Active 10/03/2016 6:38:09 AM ServerWideOffline |
Now here’s the first problem scenario. Let’s say you start the setup process for a cumulative update in GUI mode, and step through the first few dialogs, but don’t actually start the upgrade. For some reason you decide to cancel and do the upgrade at another time. Later, you discover your Exchange server is not working correctly. Why? Because Exchange setup has set ServerWideOffline to an Inactive state, using the requester “Functional”. It does this surprisingly early in the process too, so beware.
1 2 3 4 5 6 7 8 | [PS] C:\>(Get–ServerComponentState –Identity EX2016SRV1 –Component ServerWideOffline).LocalStates Requester State Timestamp Component ————– ——– ————– ————– Functional Inactive 17/03/2016 5:55:06 AM ServerWideOffline Maintenance Active 16/03/2016 10:07:07 AM ServerWideOffline HealthApi Active 14/03/2016 6:50:26 AM ServerWideOffline Sidelined Active 10/03/2016 6:38:09 AM ServerWideOffline |
The other scenario is an upgrade that is interrupted by a server issue. This one is rare, but I’ve seen it enough times that it’s worth mentioning. Let’s say a cumulative update is running, and at a key moment in the process the server crashes and restarts. The administrators take a look, and as far as they can see the upgrade has worked. Perhaps they check the server version number using Get-ExchangeServer, or check the Exchange services on the server are all installed and running. They complete their maintenance steps by running Set-ServerComponentState to set ServerWideOffline back to an Active state, using their requester of “Maintenance”. And then again, a short time later, they discover the server is not working correctly. Why? Same issue as above, the ServerWideOfflinecomponent is inactive, due to Exchange setup marking it so with the requester “Functional”.
In both cases the solution is the same. Run Set-ServerComponentState and use the requester “Functional” to set ServerWideOffline back to an Activestate.
1 | [PS] C:\>Set–ServerComponentState –Identity EX2016SRV1 –Component ServerWideOffline –State Active –Requester Functional |
In the case of the interrupted upgrade, you should also give the server a thorough health check and consider re-running the CU to get a clean result.
