Exchange 2013 Server Component State Inactive

I came across a problem recently with an Exchange 2013 server component showing as inactive which had me puzzled for a while, but in the end was an easy fix.

Problem

The Exchange 2013 server OWAProxy component showing as inactive.  Further, running the Set-ServerComponentState to change the component state to active had no affect

ServerComponentState-1

ServerComponentState-2

Cause

In my case, the issue was due to the interaction between States & Requesters as described in this blog

The process to bring a component back active is to run the following command

Set-servercomponent –COMPONENT OwaProxy –IDENTITY servername –REQUESTER maintenance –STATE Active

I’m my case I used the “maintenance” requester in my command as I suspected the server in question had been put into maintence recently.  However, this was not working for me.

After a bit of digging around, I came across this blog  from The Exhange Team which described how a server component must be made active using the same “requester” that was used to make it inactive.

I had no idea which requester was used in my case.  However, as there are only 5:

  • HealthAPI
  • Maintenance
  • Sidelined
  • Functional
  • Deployment

I ran the set-servercomponent command using each until I discovered that it was the HealthAPI requester that was used in my case.

Solution

Ran set-servercomponent using the HealthAPI requester

Set-servercomponent –COMPONENT OwaProxy –IDENTITY servername –REQUESTER HealthAPI –STATE Active

ServerComponentState-3

ServerComponentState-4

Advertisements

4 thoughts on “Exchange 2013 Server Component State Inactive

  1. You just saved my bacon. That was an awesome discovery. Strange that I set them all Inactive using the same Maintenance requester but had to use HealthAPI to set the OwaProxy to Active. Ah well, thanks again!

    Like

  2. You said you ran the componentstate against each possible requester, but isn’t that saved in the registry and in AD? Next time you exit maintenance, you’ll have four requesters with an inactive state and one with an active state. While inactive has higher priority, you have to manually activate the component, right?
    I have this same problem since 2013 CU13 with a third of the components, looking for a way to totally reset these requesters. Thought cleaning up ADSI and registry did the trick, but that’s not the case. Meanwhile I added the lines to active the components in our maintenance exit script.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s