An Exchange hub transport server failure can bring internal and external mail flow to a screeching halt. Follow...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
these steps to diagnose problems and resolve hub transport server issues as quickly as possible.
1. Verify connectivity
Before you even begin to troubleshoot Exchange, take a moment to verify basic TCP/IP connectivity. A failed network interface card (NIC) or a faulty patch cable can mimic a more serious problem. I’ve seen plenty of administrators waste time troubleshooting Exchange Server when the source of the outage was a failed network card. Always verify the hub transport server’s basic health before troubleshooting.
2. Check event logs
Although many Exchange Server admins begin the troubleshooting process in the Exchange Management Console Toolbox, I prefer to check the event logs. Tools like the Mail Flow Troubleshooter help diagnose Exchange-specific problems, but often overlook operating system-related problems. A quick glance at the System and the Application logs will usually tell you what you need to know.
However, I’ve also run into several instances where an Exchange error is logged with a generic error code. If you research these codes on TechNet, you’ll find they can refer to a dozen possible causes. Needless to say, you can waste precious time investigating each potential cause. If your event logs do not readily display the error’s cause, move on and manually troubleshoot the problem.
3. Verify necessary services are running
The next step I take when troubleshooting a hub transport server is to verify that all of the necessary services are running. As a general rule, any service with an Automatic startup should be running, but there are other services you must pay attention to as well. These include the Microsoft Exchange EdgeSync service, the Microsoft Exchange Mail Submission service and the Microsoft Exchange Transport service.
The hub transport server relies on these services; if they aren’t running, mail flow stops. Remember that the Microsoft Exchange EdgeSync service should only run if you’re synchronizing the hub transport server with an edge transport server.
4. Check the message queues
After you’ve checked the basics, look at your message queues by opening the Exchange Management Console (EMC). Then select the Toolbox and launch the Queue Viewer.
Although there are five different message queues in Exchange 2007 and Exchange Server 2010, the Queue Viewer only displays the Submission queue and the queues currently in use. Don’t panic if you only see the Submission queue. Instead, pay attention to the messages in the queues.
Messages often get stuck in queues and must be deleted for mail flow to resume. If the number of items in a queue increases and you haven’t removed the first item, you can probably get mail flowing by deleting that item.
If removing the message doesn’t help, run the Exchange Mail Flow Troubleshooter. This tool lets you select one of several pre-defined symptoms. When you do, the tool collects information about your server and determines the cause of the problem. The tool isn’t perfect, but it usually works well enough.
Hopefully, these steps helped you locate the source of your hub transport server problems. If not, there are a few more things to check. Go back and take another look at your message queues.
Pay attention to any clues that indicate that the problem is not hub transport server-specific. For example, if messages end up in the Unreachable queue, it may point to a problem with either your domain name system (DNS) server or a mailbox server.
You can also check to see if your server’s certificate has expired. The easiest way to find out is with the Get-ExchangeCertificate | FL cmdlet.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.