Owaproxy component is in Inactive State and will not successfully activate


My customer put their Exchange 2016 environment into maintenance mode so they could apply bitlocker to their drives. After applying bitlocker following the guidances outlined in the following article, they were not able to set the ServerComponentState to Active for OWA Proxy:


The customer runs the following command to see whether the state is enabled or not:

Get-ServerComponentState ServerName | ?{$_.Component -eq “OwaProxy”}

It returns the following:

Server                                  Component                               State
——                                     ———                                      —–
ServerName                      OwaProxy                                  Inactive

They then tried to set it manually, using the following command, specifying the Maintenance Requester because that is the one that is actually showing Inactive:

Set-ServerComponentState ServerName -Component OwaProxy -Requester Maintenance -State Active

We do not get an error but when we do the Get command again, it still shows inactive.


We noticed in Active Directory, that the OwaProxy.Maintenance values in msExchComponentStates had two opposing settings that looked as such:

1:OwaProxy:Maintenance :0:636264117313332389

1:OwaProxy:Maintenance :1:636272763659703237

These values will also exist in the registry of the Exchange server. Because it has competing values in there, the server will side with the most restrictive which is to keep it at Inactive.


In Active Directory Users and Computers, go to the computer object of the server that you are having the issue on, and right-click on it and select properties. Then click on the msExchComponentStates attribute. You should see the various component values. From there, delete the OwaProxy values from the attribute.

Then go to the registry on the Exchange server and delete up the OWA Proxy reg key using the following process:

Backup and delete the reg key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ServerComponentStates\OwaProxy

Allow enough time for Active Directory to replicate and then run the set command again:

Set-ServerComponentState ServerName -Component OwaProxy -Requester Maintenance -State Active

Finally, test again to see if the component is now active:

Get-ServerComponentState DENXCHMBXC1N4P -Component OwaProxy | fl

The component value should then be recreated in AD and in the registry reflecting the proper value for the active state.

Comments (5)

  1. Damir says:

    Would it be possible to solve this problem by using 2x Set-ServerComponentState with different requesters and not divnig into registry and msExchComponentsStates

    1. Gus Gallows says:

      I probably should have put this in there, but we did try to set it using the different requesters. In this case it did not work which why we went the nuclear option of wiping out the component states in AD and the registry. For whatever reason, though AD was updating with each request, the registry was not and it was winning out over AD. So the cleanest way to resolve it was to remove the settings and let Exchange/AD rebuild them. I do appreciate the response as I have seen the documentation on the web suggesting the approach you mentioned, which is why we tried it first, but again, in this case, it was not enough.

  2. turbomcp says:


Skip to main content