Troubleshooting Exchange Management Issues

Exchange is a complex product, and the SBS implementation of Exchange makes it more so. One chapter in a book cannot begin to cover all the troubleshooting possibilities for Exchange. The remainder of this chapter instead covers some of the commonly encountered issues with Exchange related to topics covered in the chapter.

Troubleshooting Outbound Mail Delivery

Many outbound mail delivery issues can be identified with just a couple of basic toolsExchange System Manager and telnet. When you suspect outbound mail delivery problems, open the Exchange System Manager and look at the outbound SMTP queues (which can be found under Servers, your server name, Queues). When you have Exchange set to deliver mail through DNS, you see a queue for each mail domain where Exchange has recently attempted delivery. The status of the queue is listed in the State column, shown in Figure 12.13. If the status is anything other than Ready, you must identify and resolve the problem before Exchange can deliver mail.

Figure 12.13. Exchange System Manager displays the status of each outbound mail queue.

When you highlight the problem mail queue, the Additional Queue Information field gives you an indication of the problem. In Figure 12.13, the queue for delivery to aol.com is in a Retry state, meaning that Exchange will make another attempt to deliver mail to aol.com. The Additional Queue Information area indicates that the last connection attempt failed because of an SMTP protocol error. In most cases, this is likely not a protocol error, but a delivery refusal.

You can narrow down the cause in one of two ways from here. First, you can enable SMTP logging and review the information collected in the log file. Follow these instructions to enable SMTP logging:

1.	In Exchange System Manager, expand Servers, your server name, Protocols, SMTP.
2.	Right-click on the Default SMTP Virtual Server and click Properties.
3.	Turn on the Enable Logging check box; then click Properties.
4.	In the Logging Properties General tab, select the Daily radio button under New Log Schedule and note the location of the SMTP log files (C:\Windows\System32\LogFiles by default).
5.	Click the Advanced tab; then enable all the check boxes under Extended Logging Options. You can choose to omit the last three fields, as shown in Figure 12.14, because they do not apply to SMTP traffic. Figure 12.14. Enable most of the Extended Logging Options to collect useful information in the SMTP logs.
6.	Click OK twice to save changes and close the Default SMTP Virtual Server properties.
7.	Right-click on the Default SMTP Virtual Server and select Stop.
8.	When the SMTP virtual server stops (a red sign appears on the icon), right-click on the virtual server again and select Start.

Now that you have SMTP logging enabled, you can force Exchange to make another connection attempt and record the transaction in the logs. You can do this by right-clicking the connector in the Queues listing and selecting Force Connection.

Next, you can review the information in the SMTP log file. Browse to the folder where the log files are stored (C:\Windows\System32\LogFiles by default), open the SMTPSVC1 folder, and open the most recent log file. The following listing displays a typical response you might get from a refused connection:

[View full width]
year-mo-da 15:22:20 hostserverIP OutboundConnectionResponse SMTPSVC1 SBS - 25   - 554-+ (RTR:BB)++http://postmaster.info.aol.com/errors/554rtrbb.html year-mo-da 15:22:20 hostserverIP OutboundConnectionResponse SMTPSVC1 SBS - 25   -  554-+AOL+does+not+accept+e-mail+transactions+from+dynamic+or+residential 

In this example, you can see that AOL responds to the connection attempt and does not accept connections from IPs that are registered as residential or dynamic by ISPs. AOL even provides a URL in the error that gives you more information about why it refused the connection.

Note

Some mail hosts handle refusing mail in different ways. AOL refuses to accept the connection, but in such a way that no NDR is generated. The Exchange SMTP queue continues to attempt delivery to AOL until the delivery timeout is received, at which point, it generates its own NDR indicating that the message could not be delivered within the time configured on the server. Other ISPs refuse the connection in such a way that an NDR is generated immediately and tells the sender exactly why the mail has been rejected. It is easier to troubleshoot delivery failures when these NDRs are generated because they generally indicate which black list or other spam-blocking tool they used to refuse your request.

Another way to investigate mail delivery problems is to make a manual SMTP connection to see what is happening. This can be useful for those occasions when no information about the connection problem is listed in the SMTP logs. You use the telnet tool to connect to the mail server and attempt mail delivery to see how the remote system responds.

Before you can telnet to the mail server, you need to know where the mail server is. Use nslookup to find the address or name of the mail server. Follow these steps to find a remote mail server using nslookup:

1.	In a command prompt window, type nslookup and press Enter.
2.	At the nslookup prompt, type set type=mx and press Enter.
3.	Type the mail domain and press Enter.

nslookup returns the mail exchanger record(s) for the mail domain. After you have noted the name or address of the remote mail server, type exit and press Enter to quit nslookup. Now you can use telnet to attempt a manual message delivery by following these steps:

1.	At the command prompt, type telnet [name of mail server] 25 and press Enter.
2.	If you receive a 220 response from the mail server, type ehlo [your mail domain] and press Enter.
3.	If you receive a number of 250 responses, type mail from: [your return e-mail address] and press Enter.
4.	If you receive a 250 response, type rcpt to: [address of recipient] and press Enter.
5.	If you receive a 250 response here, you will be able to send a message to that user successfully, so you can type quit and then press Enter to close the telnet session.

If you get anything other than a 220 response on the initial connection or a 250 response after any of the other steps, review the SMTP server responses and continue troubleshooting from there. Some responses make it obvious what the problem is. For example, if you don't have the correct server address for a mail domain, you may get a 550 5.7.1 Unable to relay error. Other errors may not be as obvious, but you can at least look up the errors on the Internet and see what may be causing the problems.

Troubleshooting IMF

One indicator that there may be a problem with the configuration of the IMF is users reporting that they are not getting the messages they are expecting. The first place to look for trouble is the SMTP log file. The following two samples from the SMTP log file show two different mail delivery sessions:

[View full width]
year-mo-da 16:05:10 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 EHLO - - 250 0 year-mo-da 16:05:14 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 MAIL  [ic:ccc}+from:[e-mail] 250 year-mo-da 16:05:18 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 RCPT  +to :[e-mail] 250 0 0 17 0 SMTP - year-mo-da 16:05:36 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 DATA   <[e-mail]> 250 year-mo-da 16:05:41 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 QUIT - - 240 year-mo-da 16:06:11 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 EHLO - - 250 year-mo-da 16:06:21 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 MAIL  +from:[e-mail] 250 year-mo-da 16:06:31 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 RCPT  +to :[e-mail] 250 year-mo-da 16:07:32 [remoteIP] - SMTPSVC1 SBS [externalIP] 0 QUIT - - 240 

The difference between these two sessions in the log is the DATA response line in the first listing. This line indicates that the message was accepted for delivery and queued into the Exchange process. The second listing has no DATA line, which means that no message was queued for delivery in Exchange. In this example, the IMF was configured to delete messages with an SCL of 8 or higher.

If a user complains that she is not receiving messages from a particular person, you can search through the SMTP logs for that email address and see whether a connection attempt has even been made. If it has and you see the email address listed in one of the MAIL lines in the log, you will see a corresponding DATA line after the message has been queued for delivery.

One option to identify whether IMF is blocking messages that it should not be is to set the Gateway Blocking Configuration to take No Action on messages at that level. This allows those messages to pass through to the next filter, where they get dumped into the Junk Mail folder for the client.

Alternatively, you can set the Gateway Blocking Configuration to Archive. This places blocked messages into a folder (C:\Program Files\Exchsrvr\Mailroot\vsi 1\UceArchive by default) as individual .eml files. In the SMTP log, you will not see the DATA entry for messages that get moved to the Archive folder, and if you do not monitor this folder, you could run out of disk space quickly during a spam attack on your server. You can open the messages stored in this folder with Outlook Express, but it is highly recommended that you use Notepad or some other text viewer instead to prevent any malicious content that may be in the message from being executed in Outlook Express from the server.

Best Practice: Setting Appropriate SCL Values Using Outlook

Unfortunately, Microsoft did not provide many easy-to-use management tools to keep a handle on IMF after you have it installed. Though a few third-party IMF management tools are available now, they are still considered "works in progress" and should be used with care. One useful management tool for IMF settings comes included with every SBS installation in the worldOutlook.

By following the instructions posted in the "You Had Me At EHLO" blog (http://blogs.technet.com/exchange/archive/2004/05/26/142607.aspx), you can get Outlook to display the SCL value for each message in the mail display listing. Then you can review the messages that are getting dumped into the Junk Mail folder to determine whether adjustments to the IMF values are needed.

This method is recommended when first setting up IMF on a server to determine what the best value for the Gateway Blocking Configuration should be. By setting the Gateway Blocking Configuration action to No Action and setting the Store Junk E-mail Configuration value to a lower number than the Gateway Blocking Configuration, all mail that would get blocked at the gateway will be delivered into the Junk Mail folder. Over a period of time, you can review the messages that get delivered to the Junk Mail folder and their respective SCL values and determine a baseline value to use for gateway blocking. After you have developed a feel for how IMF assigns SCL values to different types of messages, you can make the adjustment to the Gateway Blocking Configuration and set it to Delete when ready. The same approach can be used to determine whether the value for Store Junk E-mail Configuration is correct.

Just remember that IMF does not have any configuration options other than setting these two values. If you want more granularity in your spam filtering, you need to investigate third-party products. Many have advanced configuration settings such as blacklists and white lists (mail domains that always get blocked or always get delivered, respectively), quarantines, and user-level configurations.

Troubleshooting POP3 Connector

Troubleshooting issues with the POP3 Connector is similar to troubleshooting outbound mail delivery. Setting up and reviewing the extended logging with the POP3 Connector and using telnet to test connectivity are your primary tools.

The logging level for the POP3 Connector is set in the Troubleshooting tab of the POP3 Connector Manager. The four levels are

• NoneNo information is placed in the event logs by the POP3 Connector service.

• MinimumOnly security audit information (successful and failed logins) and critical errors are stored in the event logs.

• MediumLogs messages from the Minimum setting plus other informational messages.

• MaximumLogs every step of the POP3 Connector process in the event logs.

When you encounter problems with the POP3 connector, set the logging level up to Maximum and restart the POP3 Connector service. Then force connection attempts by clicking the Retrieve Now button in the Scheduling tab of the POP3 Connector Manager. After the connection attempt has had time to complete, you can open the Event Viewer and go through the messages related to the POP3 Connector. Fortunately, when logging is set to Maximum for the POP3 Connector, you can view each step of the entire process to see where problems are actually occurring. Unfortunately, so much information is stored in the logs, it may take a long time to sort through the data to find the information you need.

Caution

Do not forget to set logging back to Minimum (or none) and restart the POP3 Connector service when you have finished your troubleshooting session. Otherwise, your event logs will fill up quickly and could cause other problems on the server. The logging settings will not actually change until the service has been restarted.

Alternatively, you can use telnet to verify access credentials and message availability on the remote POP3 server. Follow these steps to connect to the server and see how many messages are waiting:

1.	At a command prompt, type telnet [remote mail server] 110 and press Enter.
2.	At the +OK prompt, type user [pop3username] and press Enter.
3.	At the +OK prompt, type pass [pop3password] and press Enter.
4.	At the +OK prompt, type list and press Enter. This shows the number of messages waiting for download and the size of each message.

This process verifies several pieces of the POP3 puzzle. First, if the username and password are not correct, you get a ERR response after the password entry line. Second, you can see whether messages are waiting to be downloaded. This can be helpful if you suspect mail delivery problems at the other side. You can simply keep repeating the list command to get the current count and size of the messages and watch for changes to indicate when new messages have arrived.

Caution

You can also use Outlook Express or another POP mail client to verify the username and password on the remote server. Be sure that when you build a profile in a mail client for testing purposes that you configure the profile to leave the messages on the POP3 server when checking mail. Otherwise, those messages will be deleted from the server, and the POP3 Connector will not be able to download and deliver them.

One scenario in particular that can cause much grief for an SBS administrator is when a user has her POP3 mail account configured for use in Outlook or Outlook Express. If more than one POP3 client is pulling mail from the POP3 server, irregular mail delivery is practically guaranteed. When a new SBS server is installed in an environment where users had been relying solely on POP3 for mail delivery, you should make sure that all users remove the POP3 account configuration from their mail clients for the POP3 Connector to work correctly.

One last step to verify that a message on the POP3 server will get delivered correctly is to issue the retr command in the POP3 telnet session to view the contents of the message without deleting it from the server. Simply type retr [message#] after authenticating to the POP3 server, and the server will send the entire contents of the message. At that point, you can look through the headers for the TO: and CC: fields for a valid address for your server. If an address within your domain space is not listed in the TO: or CC: fields, the message downloads to the server but does not get delivered, unless you specify a mailbox to receive delivery of all undeliverable messages.