Exchange Cumulative Updates: components are inactive

When you update an Exchange server with Cumulative Updates, there is always a risk that something will go wrong. Most of the times, it goes great. But when it doesn’t, you can have a lot of issues and have a lot of work to fix those issues to get Exchange back up and running.

My latest update of Exchange 2013 CU18 to CU21 didn’t go as planned. In the second step of the update (stopping the services), it went south. 1 of the services couldn’t be stopped by the Setup of CU21:

No big deal you think: enable the services (the Setup disables all the services to begin with) and restart the server. So far so good, all the services were back up and running:

 

But when testing the mailflow, none of the mails were arriving and I couldn’t send any mails either. The reason why, was found quickly: all the server component states are inactive:

Luckily, if you have a Get-ServerComponentState, you also have a Set-ServerComponentstate. But one parameter was giving me a headache: -Requester. When checking the Microsoft Documentation, you have different Requesters:

The Requester parameter specifies the system requesting this state change. Valid values are:

• HealthAPI
• Maintenance
• Sidelined

• Functional

• Deployment

https://docs.microsoft.com/en-us/powershell/module/exchange/server-health-and-performance/set-servercomponentstate?view=exchange-ps

How do you know requester was the cause for the inactive state of the components? Ofcourse, you can execute the command with every requester, but I always like to know the details of what I’m doing and why.

After a search, I found the code to see which requester need to be used, to make the components active again.

Execute following code:

$sec = Get-ServerComponentState -Identity servername -Component serverwideoffline

(It really doesn’t matter which component you pick, but serverwideoffline is the general one, which makes all the rest active/inactive).

The value we want, is hidden in an attribute of our variable $sec:

$sec.localstates

There you can see which requester is responsible for the inactive state:

In my example, it’s the Functional requester. So now we can make the components active again and get Exchange back up and running:

Set-ServerComponentState  -Identity servername -Requester Functional -Component ServerWideOffline

 

After this, Exchange was back up and running.

 

ps: the next day I tried again, but disabled the services first. This worked, no error during the step of “stopping the services”.