Learn Exchange the Guru way !!!


Exchange 2013 Server Component State

Exchange 2013 introduced Server component State, which will provides a granular control of Exchange components.

This is useful when performing the database maintenance, updating any CUs where in server will be out of operation but services will be running.

There are 3 possible states of the server components as below:

  • Active
  • Inactive
  • Draining

Active and Inactive is applicable for all components but Draining is applicable for only Frontend Transport and Hub Transport components, when significant component is being set to inactive, on the other hand messages in the current queue needs to process.

Whenever the state of the component needs to be changed, it can be accomplished by ‘Requester’. There are 5 requesters available as below:

  • HealthAPI
  • Maintenance
  • Sidelined
  • Functional
  • Deployment

Requester is the label. Administrators can use these requesters to track the reason for why the component state is inactive and used to change the state. Each requester maintains its logs in both Active directory and server’s local registry and treated separately. While using the requester, we need to select the appropriate option. EX: when we need to set “ServerWideOffline” to “Inactive” for maintenance purposes, then we need to use Maintenance as requester.

NOTE: When there is any conflict between 2 or more requester “Inactive” takes a higher priority than “Active”.

How to Bring the Server Component State Active:

Exchange 2013 server is kept under maintenance mode for updating the patches and once done we have removed from maintenance mode. Even after removed from the maintenance mode, still we can see few of the components are in inactive mode as below:

Get-ServerComponentState –Identity Exchange13

Get-ExchangeServer | where {$_.AdminDisplayVersion -like “*15*”} | Get-ServerComponentState | where {$_.State -eq “Inactive”} | Ft ServerFQDN, Component, State


In order to bring all components active run the below command and check the status:

Set-ServerComponentState Exchange13 -Component ServerWideOffline -State Active -Requester Maintenance

Get-ServerComponentState –Identity Exchange13

We can use multiple shell commands as per the requirement and situation. Few are as below:

As already mentioned, Information of “Server Components“, “Requesters” and “States” are stored in two different places: Active Directory and the server’s Registry. Storage in the Active Directory facilitates by running Set-ServerComponentState against remote server.

Active Directory: Stored under
“msExchComponentStates” attribute of the Exchange Server object in the Configuration-namespace

Servers Registry: stored under HKEY_LOCAL_MACHINESOFTWAREMicrosoftExchangeServerv15ServerComponentStates:

We can also use the Get-ServerComponentState commands to retrieve the settings with time strap as below:

FrontendTransport and HubTransport Components

FrontendTransport (mapped to the “Microsoft Exchange Frontend Transport” service on CAS Servers) and “HubTransport” (mapped to “Microsoft Exchange Transport” on Mailbox Servers) components will not pick up the changes until next restart. This might cause confusion about their actual state. For example, they might be displayed as “Inactive” in Get-ServerComponentState but functionally still be active since they haven’t been restarted since their state has changed.

We can get the correct state of these components from Application Event Logs. The event ids 7011 for MSExchangeTransport and 7012 for MSExchangeFrontEndTransport as below provides the current state of these components:

Once the conflicts have been cleared, Event id 7009 from Source “MSExchangeTransport” (or “MSExchangeFrontendTransport”) and Category “Components” are logged, which show the current state of the components as below:

When the state of these components are set to “Inactive”, every connection to the SMTP service on the server (on TCP port 25) triggers a response “421 4.3.2 Service not active” (for FrontendTransport component) and “451 4.7.0 Temporary Server error” (for HubTransport component) and corresponding entries are written to the individual SmtpReceive Protocol Logs.

Ratish Nair

Microsoft MVP | Exchange Server

Team @MSExchangeGuru

4 Responses to “Exchange 2013 Server Component State”

  1. NeWay Technologies – Weekly Newsletter #124 – December 4, 2014 | NeWay Says:

    […] Exchange 2013 Server Component State – […]

  2. NeWay Technologies – Weekly Newsletter #124 – December 5, 2014 | NeWay Says:

    […] Exchange 2013 Server Component State – […]

  3. Aparna Says:

    Good read! Thank you for the detailed information!
    I suppose this is carried over to 2016 too?
    Also, would like to know if there are any inbuilt maintenance scripts(scripts found in $exscripts folder on every server with exchange 2016 installed) that has this cmdlet embedded in it?

  4. Aparna Says:

    Found it.. Its in the StartDAGMaintenancescript tahts extensively used during maintenance activities.
    You may ignore my query.
    Thank you!!

Leave a Reply

migrate exchange to office 365