I am currently in the process of building out a new Exchange 2013 CU6 environment for a customer. Their last server will be placed in a DR site and will host a third copy of all of their databases. After a completing the build of this server with Exchange 2013 CU6 I performed a final check on the server, I noticed that the Transport Service would cycle between ‘Starting’ and ‘Stopping’.
First thing, I need to turn up Diagnostic Logging. For Exchange 2013, we need to run a pair of PowerShell scripts, first to check the level of the event in question and the second to set the level to what is needed. So, what one of the many Exchange Transport event logs should be set? Luckily this one is relatively easy to find. Look for MSExchangeTransport\TransportService:
To diagnose most issues in Exchange, I switch the EventLevel to 7 or Expert Level. To do this, type in the following commands:
get-eventloglevel "MSExchangeTransport\TransportService" | set-eventloglevel -level 7 get-eventloglevel "MSExchangeTransport\TransportService"
The last command verified that the EventLevel shows as “Expert”.
Once the service has restarted a few times there should be some new events in the Application log of your problematic Exchange Server. Here is what I had on my Exchange Serever:
A closer look at each event from 105, to 542, to 908, to 4999, to 1000 and 1001:
So we have a case where the mail.que file has become corrupt. In the case of my example above, the server is serving the DR site and has no active mailboxes. This means that the mail.que file should be devoid of any production emails. The mail.que file is located below:
I decided to resolve the issue we cannot just stop the service because it’s current state does not allow this. However, we can kill the process under which it runs. The file name is Microsoft.Exchange.Search.Service.exe. With no production emails at risk, we can rename the folder that holds the mail.que file which is located at (install drive):\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue. After this has been renamed, we can start up the Transport Service once more. We should now have a clean mail.que file. If we examine the Application log once more, we see the process of rebuild an reload of the Transport service.
The Transport service is now running reliably as well:
We then need to set the diagnostic level back to defaults:
get-eventloglevel "MSExchangeTransport\TransportService" | set-eventloglevel -level "lowest" get-eventloglevel "MSExchangeTransport\TransportService"
The last command verified that the EventLevel shows as "Lowest".
That’s it. Now your Transport service is fixed and email with flow.