Exchange 2013 components inactive

Installing a new Cumulative Update (CU) on the Exchange Server is always somehow stressful. If something goes wrong, you may be left with a corrupted/not working Exchange Server what means a financial loss to your company. To prevent this scenario from happening, make sure you always create an up-to-date backup copy before starting the CU installation process. If there are no obstacles, it is also worth trying to test the update of Exchange in a lab environment. This way you can measure and eliminate potential risk while performing the update in a production environment.

In this article, I will describe how changing Exchange 2013 components state may be helpful while implementing a new CU and how to set Inactive components Active when the installation of the Cumulative Update fails.

Before installing a Cumulative Update

Typically, before you start implementing a Cumulative Update on Exchange Server 2013, you run the server in the maintenance mode. This can be achieved with this cmdlet:

Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

This command causes the Exchange services to stop so that users cannot use Exchange while the maintenance work is underway. To check the state of services, you can use this command:

Get-ServerComponentState <ServerName> | ft Component,State –Autosize

The screenshot below shows the result of this command:

All components should be inactive except for Monitoring and RecoveryActionsEnabled.

Problem during the installation process

Now, you are ready to start the installation of CU on the Exchange Server. In my case, however, the CU installer encounters a problem and stops the installation process:

What’s even worse, executing the below command does not change the component state to Active, leaving the server non-operational:

Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

The server restart does not help either:

Get-ServerComponentState <ServerName> | ft Component,State –Autosize

As it come out, the problem is caused by the CU installer itself, which executes the following command:

Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

The installer used the –Requester Functional parameter, which, due to the installation failure, terminated the installation process and did not set the component state Active again. As it can be assumed, when performing a successful CU installation, the installer manages to set component states back to Active. In the example above, the installer failed at the very first step of installation.

The Exchange Server prioritizes the Inactive state over the Active one when two different Requesters execute the Set-SeverComponentState command. To set all component states Active, you need to run the below command for all Requesters that forced the Inactive state:

Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active

To view those Requesters, use the following cmdlet:

$Requesters = Get-ServerComponentstate –Identity <ServerName> -Component ServerWideOffline
$Requesters.LocalStates

The screenshot above shows that the Requester responsible for the Inactive state is Requester Functional. So in order to get the Exchange Server back to work, you need to use a command with Requester Functional:

Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

As soon as you run this command, all Exchange Server component states should be Active again.

If you notice that two components, Monitoring and RecoveryActionsEnabled, are still Inactive, activate them using the following commands:

Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

As you can see, updating the Exchange Server CU may be troublesome but it is always best practice to keep it up-to-date. Some time ago, sitting on Exchange 2013 CU4 caused problems for users of CodeTwo Exchange Rules Pro. One of the remedies was to update the Exchange Server version to CU5 or newer.

This KB article explains that problem in details.

Suggested reading

• Managed availability in Exchange 2013
• How to use ESEUTIL tool
• New-MailboxRepairRequest – the successor of the Isinteg tool