bullfrog264
asked on
MSExchangeTransport Service unable to start
So i ran into a troubling issue today. I have a single standard edition of Exchange 2010 sp2. The transport service suddenly stopped and restarted this morning. The problem is it never made it from starting to started and I couldn't restart the service. Also at the same time the CPU utilization was maxed out by the msftefd.exe process. I did some research and realize the process was related to the indexing service. I decided to temporarily disable the indexing service on my databases to try to figure out why the transport service wouldn't start. After doing so the processors returned to their normal utilization. Now I did some further research on the transport service issue. I tried this and for the life of me am not sure what i was thinking. http://technet.microsoft.com/en-us/library/bb125177
After doing so I cannot start the hub transport service. It immediately popsup an error and I see Event id 7000 and 7009 in the event logs. I have opened a case with Microsoft support and am awaiting a call back. Any suggestions in the meantime?
After doing so I cannot start the hub transport service. It immediately popsup an error and I see Event id 7000 and 7009 in the event logs. I have opened a case with Microsoft support and am awaiting a call back. Any suggestions in the meantime?
Ben Hart
Do all the other Exchange services start correctly? Were you changing the location of the queue db for a reason or in trying to resolve the service not starting?
also is the Transport service set to use the Network Service account?
ASKER
It had been previously but noticed it is on local system account. I changed it back to the network service account but it still won't finish starting. It gets to the "starting" state and never passes that.
ASKER
Yes all other exchange services start successfully. I haven't seen any other strange events in the logs but I am continuing to look.
Anything happen directly prior to this? Updates possibly?
ASKER
There were no updates applied that I am aware of. I will double check. So all of a sudden I received an ESE 489 error explaining the transport mail database couldn't open because it is in use by another process. Then the service actually started and began a event id 301 logging\recovery of that database. It completed after several minutes and gave a 302 event. Suddenly I had mailflow for about 30 seconds. Now I am back to zero mailflow even internally but all the services are running. My queues are empty according to the queue viewer and I am not receiving any NDRs nor are external sources receiving NDRs from us. I am truly stumped....
Whether you excluded exchange binaries and folders from AV scan. If not, do it first.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I verified the AV servivce wasn't blocking any of the applications and these exclusions have been set on this server for more than a year now. I verified them again and checked the access protection logs. This server was working properly this morning.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
So I took ubadmin's advice and ran the Exchange best practices analyzer. I had run this previously and saved the report for reference which I am glad I did. It turns out at some point in January the size limits for incoming and outgoing mail had been changed to unlimited. I know I didn't make that change and my previous ExBPA report from December showed they were set properly. I immediately reset the limits using powershell commands. Amazingly I had mail flowing within minutes. I was finally able to get the hub transport service started and immediately notice two emails in the queue with 2GB's of attachments on EACH one. I immediately cancelled the emails with NDRs and made a personal visit to the users desk. I politely explained they need to be careful how much data they try to send. She had made an honest mistake and was a bit embarrassed. Exchange patches were installed in early January which may have caused the change. I don't know of another explanation because there is only one other administrator with privileges in Exchange. Thank you for your help! I do believe checking the mailbox database and transport database for corruption might not be a bad idea in my next maintenance window.