• Home
  • About
  • Blog
  • Training
  • Books
  • Contact
    • Email
    • Facebook
    • Twitter
    • RSS

Practical 365

  • Office 365
  • Exchange 2019
  • Exchange 2016
  • Exchange 2013
  • Hybrid
  • Certificates
  • PowerShell
  • Migration
You are here: Home / Exchange Server / Server Component States During Cumulative Update Installation

Server Component States During Cumulative Update Installation

June 9, 2016 by Paul Cunningham Leave a Comment

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.

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 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.

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.

Paul Cunningham

Paul is a Microsoft MVP for Office Apps and Services and a Pluralsight author. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server.

Exchange Server DAG, Database Availability Group, Exchange 2013, Exchange 2016, Managed Availability

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • How to configure custom branding for Office 365 Message Encryption
  • The clock is ticking on Exchange Server 2010
  • How to licence Exchange Hybrid servers
  • How to use the Azure Content Moderator in Office 365
  • Hybrid Agent & Exchange Modern Hybrid now available as a public preview
Practical 365

Training Courses

  • Configuring and Managing Office 365 Security
  • Office 365 Admin Playbook
  • Exchange 2016 Exam 70-345
  • Managing Exchange Mailboxes and Distribution Groups in PowerShell
  • More Training Courses...

Recommended Resources

  • Office 365 Security Resources
  • Office 365 Books
  • Exchange Server Books
  • Exchange Server Migrations
  • Exchange Analyzer
  • Digicert SSL Certificates

About This Site

Practical 365 is a leading site for Office 365 and Exchange Server news, tips and tutorials. Read more...
  • Email
  • Facebook
  • Twitter
  • RSS

Copyright © 2019 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland

We are an Authorized DigiCert™ SSL Partner.