Logs are nothing more than a collection of status notes a system makes about a process. They are a way to review what happened during that process to understand what worked and what didn't. Most systems have some sort of logging option. Exchange has a couple of useful logging features that you've probably heard about - Message Tracking and SMTP logging.
Enabling Message Tracking is done in the Exchange System Manager (ESM). This is done at the server level. Open the properties of the server and find the checkbox on the General tab. That configuration also defines the location of the log files and the retention period.
Enabling SMTP logging is also done in the ESM. Although this is configured per server, the configuration is found in the properties of the Default SMTP Virtual Server (expand the server, Protocols, and SMTP).
Sunday, February 21, 2010
Understanding your outbound mail flow
Before you can troubleshoot why outbound mail isn't getting to where it supposed to, you first have to understand how it's supposed to get there. One of the keys to this understanding is knowing whether or not Exchange sends messages directly to recipient systems. When an Exchange server gets a message destined for the outside world, there are two main mechanisms that it consults. The Virtual Server (VS) and Connectors.
The Virtual Server setting takes precedence, so look there first. Open the Exchange System Manager (ESM) and expand to the server in question. Further expand Protocols and SMTP. Beneath SMTP there is typically a single entry - the Default SMTP Virtual Server. Open the Properties of it, go to the Delivery tab, and click on the Advanced button. The main thing you are looking for is whether there is an entry in the Smart host field. If there is, it means that all outbound messages will be sent to that FQDN. If not, your Exchange Organization will require one or more SMTP Connectors to route outbound messages.
If the VS is not configured with a Smarthost, Exchange then looks to the Connectors for outbound routing information. The Connector structure can be simple or complex, depending upon the size of your Exchange Organization and how your enterprise wants mail to flow. For this example, let's assume the simplest configuration possible - a single Exchange server environment.
To route outbound messages, your single-server Exchange Organization requires at least one Connector (assuming you did not configure a smarthost via the VS).
Let's take a moment to review the function and difference between Exchange Administrative Groups (AG) and Exchange Routing Groups (RG). AGs allow you to easily configure administrative permissions to a group of servers, regardless of their geographic location or purpose. RGs are specifically for message routing. There is no implied correlation between any particular AG and RG.
Connectors are associated with RGs and are also referred to as SMTP Connectors.
Getting back our discussion on mail flow, in the simplest configuration you'd have a single Connector. Looking at the Properties, on the General tab there is a radio-button selection allowing you to either configure a smarthost or to use DNS.
If smarthost is selected, there should be an IP address in the field (as opposed to the FQDN format used in the VS).
If DNS is selected, it means that Exchange will attempt to send messages directly to the recipient system.
The Virtual Server setting takes precedence, so look there first. Open the Exchange System Manager (ESM) and expand to the server in question. Further expand Protocols and SMTP. Beneath SMTP there is typically a single entry - the Default SMTP Virtual Server. Open the Properties of it, go to the Delivery tab, and click on the Advanced button. The main thing you are looking for is whether there is an entry in the Smart host field. If there is, it means that all outbound messages will be sent to that FQDN. If not, your Exchange Organization will require one or more SMTP Connectors to route outbound messages.
If the VS is not configured with a Smarthost, Exchange then looks to the Connectors for outbound routing information. The Connector structure can be simple or complex, depending upon the size of your Exchange Organization and how your enterprise wants mail to flow. For this example, let's assume the simplest configuration possible - a single Exchange server environment.
To route outbound messages, your single-server Exchange Organization requires at least one Connector (assuming you did not configure a smarthost via the VS).
Let's take a moment to review the function and difference between Exchange Administrative Groups (AG) and Exchange Routing Groups (RG). AGs allow you to easily configure administrative permissions to a group of servers, regardless of their geographic location or purpose. RGs are specifically for message routing. There is no implied correlation between any particular AG and RG.
Connectors are associated with RGs and are also referred to as SMTP Connectors.
Getting back our discussion on mail flow, in the simplest configuration you'd have a single Connector. Looking at the Properties, on the General tab there is a radio-button selection allowing you to either configure a smarthost or to use DNS.
If smarthost is selected, there should be an IP address in the field (as opposed to the FQDN format used in the VS).
If DNS is selected, it means that Exchange will attempt to send messages directly to the recipient system.
Troubleshooting Outbound Messaging
A couple of years ago I wrote a series of articles on what to do when users say inbound messages aren't getting to them. I am frequently asked for help figuring out why outbound messages seemingly don't get to where they are going.
Troubleshooting outbound mail flow is relatively simple (at least to me, but then again I'm a self-professed Messaging-geek). Whenever I bring up the subject, people look at me like I'm talking about something more (dark) art than science. I think that's only true until you gain an understanding of the science. With that in mind, here's my attempt to explain some of that science and hopefully put you on the path to becoming a troubleshooting wiz.
The easiest way to think about messaging is that it is a point-to-point transmission system. It starts somewhere and wants to go somewhere else. It may require only one tranmission (hop) or several. Each transmission succeeds or fails. Sounds simple so far, right?
Let me put it another way - here's how I look at troubleshooting message flow:
First, you have to know the path a message will take to get to its destination
Second, you have to determine how far along that path it got
Third, you have to figure out why it stopped (or if it stopped)
Sounds simple enough, but as the saying goes the devil is in the details. Towards that end, here are some separate articles about narrowing the focus of your search. I'm not sure the best way to follow along. As you get used to some of these ideas you may have to go back and forth. You may want to jump to the last article in the list and see how far you can get. I'll try to link up the articles as much as possible.
Understanding your outbound mail flow
Understanding Logs
What's a Smarthost?
What's a Relay?
Understanding Message Tracking
Understanding the Queues view
Understanding the SMTP log
Understanding basic SMTP commands and responses
Using NSLookup to verify recipient system address
Using Telnet to verify SMTP connectivity
Let's Troubleshoot (putting it all together) !!
Troubleshooting outbound mail flow is relatively simple (at least to me, but then again I'm a self-professed Messaging-geek). Whenever I bring up the subject, people look at me like I'm talking about something more (dark) art than science. I think that's only true until you gain an understanding of the science. With that in mind, here's my attempt to explain some of that science and hopefully put you on the path to becoming a troubleshooting wiz.
The easiest way to think about messaging is that it is a point-to-point transmission system. It starts somewhere and wants to go somewhere else. It may require only one tranmission (hop) or several. Each transmission succeeds or fails. Sounds simple so far, right?
Let me put it another way - here's how I look at troubleshooting message flow:
First, you have to know the path a message will take to get to its destination
Second, you have to determine how far along that path it got
Third, you have to figure out why it stopped (or if it stopped)
Sounds simple enough, but as the saying goes the devil is in the details. Towards that end, here are some separate articles about narrowing the focus of your search. I'm not sure the best way to follow along. As you get used to some of these ideas you may have to go back and forth. You may want to jump to the last article in the list and see how far you can get. I'll try to link up the articles as much as possible.
Understanding your outbound mail flow
Understanding Logs
What's a Smarthost?
What's a Relay?
Understanding Message Tracking
Understanding the Queues view
Understanding the SMTP log
Understanding basic SMTP commands and responses
Using NSLookup to verify recipient system address
Using Telnet to verify SMTP connectivity
Let's Troubleshoot (putting it all together) !!
Tuesday, October 23, 2007
NDRs - Cause for concern?
Among the more common questions I get from my users concerns Non-Delivery Reports (NDRs) they receive for messages they didn't send. Some users are understandably upset because many of the subject lines would lead you to question their character.
In addition, I see lots of questions from messaging administrators concerned that their environment is an open relay because either they are receiving a lot of NDRs from outside systems, or their own queues are clogged with NDRs to other SMTP domains.
Recently I posted this response at MSExchange.org to an Exchange administrator searching for a reasonable explanation for the flood of inbound NDRs his users were receiving.
===============
Consider this scenario:
1. I am a "Secret Creator of Unwanted Messages" (a.k.a. SCUM)
2. There is an SMTP domain named company.com
3. The address no.one@company.com does not exist
4. Your SMTP domain is unsuspecting-user.com
5. You have a user with the address someone@unsuspecting-user.com
6. I send out a message addressed from someone@unsuspecting-user.com and to no.one@company.com
The message goes out from my secret lair in a nearby septic tank out to the Internet.
The message then gets delivered to the server at company.com. That server accepts the message, attempts to find a match for no.one@company.com and discovers there is no such address. Being the RFC-compliant system it is, it dutifully creates and sends out an NDR to the sender. The trouble is, it thinks the sender is someone@unsuspecting-user.com and so sends the NDR there.
===============
This isn't to say that we shouldn't watch for signs that our system has been compromised, but more on that later...
In addition, I see lots of questions from messaging administrators concerned that their environment is an open relay because either they are receiving a lot of NDRs from outside systems, or their own queues are clogged with NDRs to other SMTP domains.
Recently I posted this response at MSExchange.org to an Exchange administrator searching for a reasonable explanation for the flood of inbound NDRs his users were receiving.
===============
Consider this scenario:
1. I am a "Secret Creator of Unwanted Messages" (a.k.a. SCUM)
2. There is an SMTP domain named company.com
3. The address no.one@company.com does not exist
4. Your SMTP domain is unsuspecting-user.com
5. You have a user with the address someone@unsuspecting-user.com
6. I send out a message addressed from someone@unsuspecting-user.com and to no.one@company.com
The message goes out from my secret lair in a nearby septic tank out to the Internet.
The message then gets delivered to the server at company.com. That server accepts the message, attempts to find a match for no.one@company.com and discovers there is no such address. Being the RFC-compliant system it is, it dutifully creates and sends out an NDR to the sender. The trouble is, it thinks the sender is someone@unsuspecting-user.com and so sends the NDR there.
===============
This isn't to say that we shouldn't watch for signs that our system has been compromised, but more on that later...
Thursday, August 30, 2007
GAL vs. OAB - Why can't I see my AD changes?
When you run Outlook in non-cache mode, or connect using Outlook Web Access (OWA), you access the Global Address List (GAL) directly. Any changes made will appear as soon as your AD forest is replicated.
When you run Outlook in cache mode, you are viewing an offline copy of the GAL called an offline address book (a.k.a. offline address list). By default, Exchange rebuilds the OAB once a day. Also by default, Outlook downloads the OAB once when you launch it - thinking it doesn't need to check more often because of the rebuild schedule.
If you need to force a new entry to show up immediately, you need to do two things. First, manually rebuild the OAB. Open the System Manager (ESM) and expand Recipients then click on Offline Address Lists. In the right pane right click Default Offline Address List and select Rebuild. You should then wait anywhere from 2 to 10 minutes (depending upon how many entries are in your GAL). Second, in Outlook (running in cache mode) go to Tools-->Send/Receive and select Download Address Book. You should then see the new entry.
If you wish to view or change the rebuild schedule, open the ESM and expand Recipients. Open the properties of the particular OAB in question. On the General tab, there is a field for Update interval. By default this is set to run daily - early in the morning. If you wish to have the OAB rebuild more than once a day, you can select "Use custom schedule" and create your schedule.
When you run Outlook in cache mode, you are viewing an offline copy of the GAL called an offline address book (a.k.a. offline address list). By default, Exchange rebuilds the OAB once a day. Also by default, Outlook downloads the OAB once when you launch it - thinking it doesn't need to check more often because of the rebuild schedule.
If you need to force a new entry to show up immediately, you need to do two things. First, manually rebuild the OAB. Open the System Manager (ESM) and expand Recipients then click on Offline Address Lists. In the right pane right click Default Offline Address List and select Rebuild. You should then wait anywhere from 2 to 10 minutes (depending upon how many entries are in your GAL). Second, in Outlook (running in cache mode) go to Tools-->Send/Receive and select Download Address Book. You should then see the new entry.
If you wish to view or change the rebuild schedule, open the ESM and expand Recipients. Open the properties of the particular OAB in question. On the General tab, there is a field for Update interval. By default this is set to run daily - early in the morning. If you wish to have the OAB rebuild more than once a day, you can select "Use custom schedule" and create your schedule.
Subscribe to:
Posts (Atom)
