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:

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.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Nic Ważnego

    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 🙂

  2. Geoffrey Kenny

    Hi and thanks, this post got us back online!

  3. hamza khedadji

    Hi
    it is work for me, thx a lot

  4. Bidhan

    Excellent solution.

    Thanks,

Leave a Reply