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 Inactive state, 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.
[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.
[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 ServerWideOffline component 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 Active state.
[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.
Hi, Your post saves my a** . Thank you,
I want to remark, that this server state is keept in Domain Controller if you didn’t know it already, not in the Exchange itself.
I breake make Exchange with the leatest update crash, in result destroying the configruation of IIS, with no time to fix it.
I recover bare metal of exchange server, and above metioned states was inactive, also after server restore.
Your guide turn it back online 🙂
Hi and thanks, this post got us back online!
it is work for me, thx a lot