Ran into this issue in my lab which started some point AFTER installing CU2. Things were working after installing CU2, but as of today the “Microsoft Exchange Transport” and “Microsoft Exchange Mailbox Transport Submission” server would not start.
On startup the error would below would occur in the Application log.
To resolve this error I did the following
- Opened the Exchange 2013 EAC
- Goto Servers\<server>
- Clicked DNS lookups
- External & Internal lookups were set to “All network adapters”
- Change this to “Microsoft Hyper-V Network Adapter #2” (Choose the one that Exchange is using for external\internal network traffic (NOT iSCSI or DAG one)
- Repeat on both External & Internal
- Restart the “Microsoft Exchange Transport” and “Microsoft Exchange Mailbox Transport Submission” services
Log Name: Application
Source: Application Error
Date: 11/21/2013 12:46:29 PM
Event ID: 1000
Task Category: (100)
Faulting application name: MSExchangeSubmission.exe, version: 15.0.620.20, time stamp: 0x512192de
Faulting module name: Microsoft.Exchange.Net.ni.dll, version: 15.0.620.18, time stamp: 0x511c5c25
Exception code: 0xc00000fd
Fault offset: 0x00000000006670c7
Faulting process id: <varies>
Faulting application start time: <varies>
Faulting application path: C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeSubmission.exe
Faulting module path: C:\Windows\assembly\NativeImages_v4.0.30319_64\Microsoft.E91f4adf5#\77f4457dccc969eb2fafad3d690e9f50\Microsoft.Exchange.Net.ni.dll
Report Id: 9cf3cbec-52e5-11e3-941f-00155d024403
Faulting package full name:
Faulting package-relative application ID:
This post saved me from a possible hours of nightmare. It definitely fixed the issue for me.
Thank you so much!
You are the master, saved my reputation. I had the same issue. i had faced transport issues in previous exchange versions, but this one was different, best Regards.
After migrating our Exchange server from Hyper-V to QEMU/KVM it took over an hour to boot the server because it was constantly starting and failing in the background. With patience and your DNS fix everything worked out. Thanks!
Thank you very much indeed. You saved me!
I was about to reinstall everything because of this issue.
Thank you for this. It’s the only clue I found regarding why our TransportConifguration component was taking so long to activate at startup. Previously, this one component was taking 42 seconds to activate/load. With DNS Lookups limited to just the one network interface, it is now down to 14 seconds. Unfortunately that is still too long and its causing timeouts. Anything else to reduce the load time of that one component? Or to run diagnostics/logging against that component to see what the root cause might be? I notice in most environments it hardly takes 1 second.