Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Tom Jones: Thank you. I’m really glad to be here. The subject of today’s presentation is a subject that I’m really passionate about, and I’ve been looking forward to talking about this for a number of months. So let’s dive right into the presentation.

On slide 2, you will see the presentation outline. First, we’ll review the transport core. Then, we’ll talk a little bit about message flow. Understanding how the transport engine is designed and how mail moves through the Exchange 2000 transport engine is fundamental knowledge. It’s required knowledge so that you can effectively and intelligently troubleshoot problems with message flow. So we’re going to review that material first.

Then, we’ll dive into troubleshooting. In the troubleshooting section, I’ll propose a method of troubleshooting that I find is very successful in finding solutions quickly. Also, we’ll take a look at some of the tools. We’ll take a look at some of the diagnostics and other things that we use to help us here at Microsoft. Finally, we’ll end with a little bit of question and answer.

On slide 3, I’d like to start out at a really high level and try to make this as simple as possible. When we’re looking at the Exchange 2000 transport from the highest level, there are basically three phases: there’s a submission phase; there’s a processing phase, which is the message moving around inside the transport core; then, there’s a delivery phase.

We have only three submission queues. One of them is the SMTP. Another one is the local store, meaning the local information store on that particular Exchange server. The other submission queue or the other submission method is legacy MTA, which means it’s coming from the Exchange 5.5 MTA, which we include in Exchange 2000. Now, technically, when something is coming from the legacy MTA, it’s really going through the store, but when we talk about it at this level, we’re going to say there are three submission queues.

Messages go into the transport core. They do their thing in there. Then, they’re delivered out in much the same way that they were delivered in, through SMTP, or to the local store, or to the local MTA.

Going a little bit deeper now, in slide 4, we want to take a look at the transport core. I’m not at the deepest level yet. We have four major components.

The transport core is managed almost entirely by the advanced queuing engine. Throughout this presentation, I’ll refer to this as advanced queuing or the advanced queuing engine, or sometimes I’ll call this the AQ. The categorizer is also a major component of transport, and we’ll get into that in just a second to describe in detail what that does. Then, there’s also the routing engine, which I’ve listed here as routing, which uses the link state algorithm. This is a fairly new method of determining routes that we use in Exchange 2000, different from what we did in Exchange 5.5. Then, we also have what I am calling remote delivery. Now, this section here is a little bit more complex than just remote delivery, as we’ll see in the next slide.

This is a fairly detailed slide (slide 5). I hope it doesn’t look too busy. In addition to showing you the detailed components within each of these major components, I’ve also tried to show you how mail flows or moves through or between these components.

When a message is submitted to the transport core, it goes first to the advanced queuing engine. The advanced queuing engine then dispatches, or subcontracts, work out to other processes, such as the categorizer or the routing engine, or finally off to the remote delivery component.

Let’s take a look first at the categorizer component. I’ve split it up into three separate components or three subcomponents. The first one is the PreCategorizer. The final one is the PostCategorizer. The one in the middle is what we call the PhatCat.

PhatCat is the name that sometimes shows up in the event description. You can call it the categorizer proper if you please. That’s where an awful lot of the work that goes on inside the transport engine occurs.

We validate the recipients. Whether we know them or not, we check those recipients to see whether they have the proper attributes. After we’ve determined what kind of user they are and if we know about them, we check to see what restrictions we have. We’ll also do distribution list expansion. We’ll also decide, within the categorizer, whether the message is bound for local delivery, meaning delivery to the local information store, or remote delivery, meaning any place that’s not local. In fact, the function is local, which returns only two possible answers: it’s a true or it’s a false.

Next, the mail moves back to the advanced queuing engine, after it has been determined that the message is local or remote. If the message is going to be remote, then the advanced queuing engine asks for a route from the routing engine. The routing engine uses its link state algorithm to decide the state of the various links throughout the entire organization and which is going to be the most effective and efficient method, link, or route to follow to get the message delivered.

After we return the route from the routing engine to the advanced queuing engine, AQ then submits it to the remote delivery components.

The first remote delivery component is what I have labeled DMT. That stands for domain mapping table. Within the domain mapping table, we set a priority or determine with the messages what they’re going to be queued into based on priority, based on domain and based on delivery time — whether we’re delivering it instantly or whether we’re going to delay delivery.

After we have created the queues, the Connection Manager creates the connection, manages the connections to the remote system, and then also tears the connections down. What I’ve listed here as queues, three different queues (just hypothetically), is actually the SMTP core, if you want to call it — the SMTP service, as I'll call it in the rest of the show. So that’s a pretty detailed look at how the transport core operates.

Before we go into talking about message flow in greater detail, I just want to highlight some of the components that go into making the mail move or flow throughout the Exchange system (slide 6).

Mail messages are submitted by clients, such as Outlook^®, Outlook Express, and Outlook Web Access.

It goes to the information store. The information store passes the message to the Exchange transport engine. So we work with the information store to store the message and sometimes even to route mail to other systems.

Within the transport core, the SMTP server, the routing engine, and the message transfer agent or the MTA stacks services are all part of and fundamental to the transport core in Exchange 2000.

Those services all ride on top of the IIS admin service. So if the IIS admin service is not functioning or if it’s stopped, then those services are stopped as well.

DNS is very important within the Exchange message flow. If DNS is not functioning properly, guaranteed, there are going to be mail flow problems.

Also, the Active Directory^® — if the Windows 2000 Active Directory has hiccups, or if some of the components, some of the objects within the Active Directory are missing required attributes, then transport is not going to work correctly.

Also, I’ve shown over here the Queue folder, which is a folder on an NTFS volume. That queue folder is going to be under the \Exchsrvr\Mailroot\Vsi1\Queue. That's a mistake in the slide. It should be the Vsi1\Queue, unless of course you have several other SMTP virtual servers. This is based on virtual servers. If you have three virtual servers, it might be Vsi2 or Vsi3, but it’s the Queue folder where we persist inbound messages — messages that are being received from a remote system before they get transferred into the transport core.

Let’s talk about message flow in greater detail. In the next several slides, probably about 20 slides, I’m going to describe message flow first in text format and then in a diagram format. So if the text puts you to sleep, just bear with me for a couple of minutes until I get to the graphical image that represents the text.

The first scenario I’d like to describe is outbound message flow to the Internet (slide 7).

When we’re sending mail out to the Internet, it begins with a client, such as Outlook 2000 or Outlook 2002, submitting a message to the information store. The information store submits the message to the advanced queuing engine. In all cases, regardless of whether the message is bound for a local client or not, all mail messages are submitted to advanced queuing by the information store.

Now, the AQ then submits the message to the categorizer. It’s the categorizer then that resolves and validates all the recipients. Is this a recipient that we know about? Are they in the Active Directory? If they’re not, then we flag them as an unknown or a remote recipient, a remote e-mail system.

If we know about them, if it’s a mailbox-enabled user, we determine if they have the proper attributes. We have a certain set of attributes that we require and expect of an Exchange 2000 mailbox. Those are talked about further in the slide show.

We then determine limits and restrictions for all of the recipients. These limits and restrictions are based on settings configured within connectors, within information store, and within the Internet message formats, in various areas of the Exchange System Manager. Limits and restrictions can be applied to various user groups.

Then, based on all of that information, we’ll expand distribution lists. And if necessary, we’ll split out messages, take a single message and create several instances of that message, depending on if it’s going to a different domain or if it’s going to a set of users that don’t have the same limits as another set of users.

Finally, the categorizer determines if the message is bound for local or remote delivery. If the message is determined to be for remote delivery, as it is in this case, it’s going to be delivered to the remote system. Then the categorizer returns the message to the advanced queuing. Continuing on in the next slide (slide 8), the advanced queuing then requests a route. What’s the route to get to the remote system, within the Exchange system? Now, the routing engine doesn’t do directory lookups or DNS lookups for external systems. Instead, what it’s looking for is, how can I get this mail message to a connector that will actually deliver this message to its final system. Or within Exchange 2000, how can I get to this Exchange 2000 server within the organization?

After the route is found, the advanced queuing engine submits the message to the remote delivery queues. Remote delivery consists of the following, as I briefly mentioned before: the domain mapping table, which sorts messages out by priority, by domain and delivery time; there’s the connection manager, which establishes and manages connections with remote hosts; and then, there’s SMTP, which actually transfers the message.

Now, here is a very busy slide (slide 9). I promise that not all of the slides are going to be this busy, but I just wanted to show how the different components interact.

As you see with number 1, the client submits the message to the information store. The second step is it submits to the advanced queuing engine, and in the third step, the third arrow points to the categorizer. As mentioned before, the categorizer does its thing and passes the message back to advanced queuing. Advanced queuing, at this point, knows that the message is bound for remote delivery. So it requests a route. As you see, steps 5and 6 point down to the routing engine and back to the advanced queuing engine, where the advanced queuing engine now has a route to get the message out of the system. It passes it, with arrow number 7, down to the remote delivery queues. SMTP eventually then does its process, transfers the message out to the Internet to the remote system, and it’s done.

Now, those smaller arrows that I’ve drawn are arrows that are going to DNS and to the Active Directory. I’m showing you that there’s an awful lot of interaction with the categorizer and the DNS system and Active Directory lookups. The routing engine depends very heavily on DNS. It also does directory lookups. Then, the SMTP component within the remote delivery system also leans very heavily on DNS. So once again, as mentioned before, the DNS needs to be functioning properly. It needs to be configured correctly for this whole system of message flow to work properly.

In the next set of slides, I’m going to talk about inbound message flow, which is just the reverse, but it doesn’t follow exactly the reverse path.

A remote SMTP host will connect to our Exchange SMTP service (slide 10). Our SMTP service receives the message. Then, it writes it to the Queue folder. As I’ve listed, that’s usually in the \Program Files\Exchsrvr\, and that should be \Mailroot\Vsi1 folder, and then the \Queue folder. So that’s a little bit of a mistype there {Note: The slides have been corrected.}.

Then SMTP, after it has persisted the message or saved it to the Queue folder, will submit the message to advanced queuing. After the message gets into the transport core, the advanced queuing almost always follows the same path. Advanced queuing submits to the categorizer. The categorizer does its thing. In this case, the categorizer determines that the message is bound for local delivery. If it was determined that the message was not going to go to the local information store, then the advanced queuing would request a route of the routing engine.

Finally, it would then submit the message to remote delivery system for delivery to another Exchange 2000 server within the system. Then the information store receives the message from advanced queuing for local delivery. Now again, in this example, advanced queuing is submitting the message to the information store, and the information store delivers the message to the user’s mailbox.

Let’s take a look and see what that looks like graphically (slide 11). As you can see, I haven’t numbered the arrows here, but it starts at the Internet.

It goes to a component that I call the SMTP client. Now, that may seem a little bit funny, that SMTP client, when that’s actually an SMTP service and it’s acting in a server capacity. The reason why it’s called an SMTP client is because the component, when we look at diagrams within internal documents, that process is actually called SMTPCLI, which is SMTP client .dll. So just bear with that name.

The SMTP client receives the message, persists it to the Queue folder, as you can see there on the right, then transmits it or submits it to advanced queuing.

Advanced queuing goes to the categorizer. The categorizer passes it back to advanced queuing, which then delivers it to the information store.

Once again, you see the smaller arrow emphasizing the fact that we depend very heavily on DNS and Active Directory.

The third scenario that I’d like to talk about is message flow between two Exchange 2000 servers (slide 12). On the local Exchange 2000 server, as before, the client submits to the information store. The information store submits to the advanced queuing engine. The advanced queuing engine manages the following operations, which we’ve already gone over twice or at least three times now: it submits to the categorizer; the categorizer determines that it’s for a remote user; the categorizer returns the message to advanced queuing; the advanced queuing requests a route of the routing engine; after that route is returned, advanced queuing then submits the message to the remote delivery queues, the remote delivery system. Eventually, the SMTP service on the local server transmits the message to the remote Exchange 2000 server.

Now in the next slide, on slide 13, we see what happens on the remote Exchange 2000 server. On the remote Exchange 2000 server, SMTP receives the message from the first Exchange 2000 server and persists the message in the queue folder. All messages received inbound from the SMTP service on an Exchange 2000 server are saved to the Queue folder. SMTP then submits that message to advanced queuing. Advanced queuing does its thing. Eventually, the message is delivered to the user on the information store.

On the next slide (slide 14), we see a graphical representation of all of this. What I’ve tried to do is separate these as Server1 and Server2, so that you get a clear understanding of the systems. They’re virtually identical components between the two systems. Of course, the DNS and the Active Directory are probably shared between these two. They’re both going to the same DNS server. They’re both going to the same Active Directory, usually.

Now, moving on to the fourth scenario, slide number 15, Exchange 2000 to Exchange 5.5: A lot of customers are migrating their systems from Exchange 5.5 to Exchange 2000. During that migration, they have to coexist. So how does mail get from an Exchange 2000 system, which has a radically different transport system, to an Exchange 5.5 server?

In slide 15, it starts with the Exchange 2000 server going through the process that we’ve already been through a half dozen times now. The client submits to the store. The store submits to advanced queuing. Advanced queuing submits to categorizer, which determines that the message is bound for a legacy e-mail system or an Exchange 5.5 e-mail system, and it returns the message to the advanced queuing. Now, this is the equivalent of saying it’s bound for local delivery, because the advanced queuing engine then returns the message to the information store. The information store then passes the message to the MTA.

At some point in here, either the advanced queuing engine or the information store is requesting a route, using the same routing engine to do its lookup of how to get a message from this MTA to the next MTA within the Exchange system. The MTA, in Exchange 2000, is kind of a dumb MTA. It doesn’t perform any of the distribution list expansion. It doesn’t use routing logic. All it does is transfer the message from point A to point B. So in step E, the Exchange 2000 MTA sends the message to Exchange 5.5.

Now on slide 16, we see what happens on an Exchange 5.5. Server. For you experienced administrators, this is old hat. The MTA receives the message from another MTA. The MTA does a lookup on the recipient within the Exchange 5.5 directory and finds that that user is on the local information store. Then, the MTA passes the message to the local information store, which delivers the message to the final mailbox.

On slide 17, we see a graphical representation of this. The mail moves very smoothly from the client in the Exchange 2000 system over to the Exchange 5.5 system, provided of course everything is configured and functioning correctly. Notice that between the two MTAs, the protocol being used is the X.400 protocol. I may not have emphasized this before in previous slides, but all communication between Exchange 2000 servers is SMTP — always. Exchange 2000-to-Exchange 2000 is always SMTP, regardless if it’s between two routing groups. If you’re connecting with a routing group connector, it’s going to be SMTP. When you’re connecting Exchange 2000 server to Exchange 5.5 server, it’s going to use an X.400 protocol for transferring that message, within the same site. The exception might be if you were connecting to systems in an Exchange 2000 routing group with an Exchange 5.5 site, using, for example, an Internet Mail service as the connector. That might be the exception to the normal rule.

Let’s go to the next slide (slide 18). This is the final message flow example. Thank you for bearing with me, and we’ll finish this and move on to the troubleshooting.

In the final scenario, Exchange 2000 submitted a message to the foreign e-mail system. It follows the same path as a message moving from Exchange 2000 to Exchange 5.5, up to the point that the advanced queuing engine returns the message to the information store.

Then, when the message is returned to the information store, the information store moves the message to the MTS-OUT folder of the foreign connector’s mailbox. If you have a foreign connector, such as the Lotus Notes connector or the GroupWise connector, you know that there is a hidden mailbox that gets created within the local information on the Exchange server. Within that hidden mailbox are several folders. One of those folders is the MTS-OUT. There’s also an MTS-IN. There’s also a RDY-OUT and a RDY-IN folder. So the MTS-OUT folder is where the information store first receives the message from the local message transfer system.

The message is converted by the connector and moved to the RDY-OUT folder within that mailbox. Then the foreign connector makes its connection to the foreign e-mail system and transmits the message. Then the foreign system does its thing to deliver the message.

I have intentionally not gone into great detail on this slide, as to how mail moves through the foreign system, because that could be whole other presentation.

So here’s the graphical representation (slide 19), in very generic form, of how mail moves from an Exchange 2000 system to a foreign e-mail system. Between the foreign connector and the foreign e-mail system, I haven’t listed a protocol, because the protocol depends on the connector. With the GroupWise connector, it’s more of a file-level protocol, copying it from one folder to another folder. With the Lotus Notes connector, it’s using the Lotus Notes proprietary protocol for moving messages from the client to the server.

Now, let’s talk about troubleshooting (slide 20). The purpose of this whole slide show is to talk about troubleshooting. Troubleshooting, in general, is a methodical approach to identifying and solving a problem. It’s a really pretty basic concept. I have a problem. I need to understand the problem as narrowly as I can. I need to formulate a theory of what the root of the problem is, and then I need to fix the root of the problem.

So here, I’ve listed a more practical list of that approach. Define the problem as narrowly as possible. Get basic details. After you’ve gathered basic details, check to see if it’s a known issue. That’s really a very efficient approach. Check to see if this is something that’s already known about and that can be solved quickly. If it’s not known, then move to the phase of gathering additional details, much more detail, and do a little bit of research in the Knowledge Base, TechNet, and online resources. Consult with your peers.

In the first phase of troubleshooting (slide 21), you need to define the problem. As the Tech Lead, I get the opportunity to work with a lot of my co-workers that on the phones troubleshooting the problems that you call in with. When they come to me, I force them to start out by saying, "The problem is …," because often the customers and the engineers will start describing the whole big picture of the system. They’ll say, "Well, they’ve got this server over here, and they’ve got that server there. They did this, and they did that." This whole time, I’m wondering, "But, what is the problem?" So start out, even in your own mind, thinking, "What is the problem? The problem is (fill in the blank)," whatever it is.

With most message flow problems, they start out with the mail not being delivered. If it’s not being delivered, it might be queuing up someplace, and not moving. It might be vanishing. Mail might be misrouted. Mail is being returned as undeliverable. Those are the most common scenarios of how mail flow problems start out. That’s the problem description.

After we have a basic problem description, we get a little bit more detail, and we want to try to clarify and describe that problem as narrowly as possible. So here are some of the questions (slide 22) that I ask to cut to the chase and determine what the problem is as narrowly as I can.

What do you mean when you say mail isn’t being delivered? Do you mean it’s being returned undeliverable? Do you mean that it’s going to a certain queue and it’s backing up there? Do you mean that it’s just vanishing? Where is the mail going? Is this a problem with inbound mail flow or with outbound mail flow? Or is it a problem with all mail flow? Is it creating a problem between Exchange servers? What about users on the same Exchange server? What about between Exchange 2000 and Exchange 5.5?

If the customer tells me that there is an NDR that they’re receiving, I’ll say, "What exactly does the NDR say?" The NDR is very revealing in helping me solve the problem. I ask them to send me a copy of the NDR.

If they tell me that messages are queuing up at a particular queue, I’ll say, "Great. What queue is it queuing up in?" because that’s important to know. And, "What’s the status of that particular queue? What’s the state of that queue? Can you send me a screen shot?" Further in the slide show, I’ll give you an example of what some of those screen shots look like.

After we have the detailed description of the problem, I move into the configuration stage (slide 23), gathering details about the system.

Every single time somebody comes and asks me a question, and starts describing a problem, I want to know what version of Exchange we are talking about, Exchange 5.5 or Exchange 2000. What service packs are applied? Is there a foreign e-mail system involved? What version of the foreign e-mail system? Versions matter. Versions make a big difference. Understanding the service packs and understanding the hotfixes that have been applied, that helps us a great deal, knowing where we are, because there may be a problem that we know about that’s fixed with a hotfix or that’s fixed in the service pack.

What type of server is it? That’s a very important question for me, because it helps me understand what we can do and sometimes the criticality, the urgency of solving the problem. If it’s a mailbox server, we try to get that up as quickly we can without damaging any mail that might be queued up. We are very protective of the information store. If it’s a bridgehead server, sometimes, as part of our troubleshooting, we might move out an information store, because we might suspect that a message in the information store is causing the problem. That’s not ever considered a solution, but it is a valid troubleshooting step when we’re trying to identify the root of a problem.

Then, I gather details about the Windows system. Is this a domain controller? How many domain controllers? Are any of them global catalogs? How many global catalogs do you have within the Active Directory site? How many Active Directory sites do you have? Any DNS servers? How many? Where are they? How is DNS configured on Exchange 2000? Are the Exchange 2000 TCP/IP properties pointing to one or multiple DNS servers? Are those servers internal DNS servers? In the SMTP virtual server on the Exchange 2000 system, have we configured any external DNS servers that it’s pointing to? What type of Exchange server are we talking about: a member, or is this a domain controller within the Active Directory system? You can see how I can go on for a very long time gathering details.

Now, let me digress for just a second. With Exchange 5.5, troubleshooting nearly all the problems, we could focus on one server and pay attention to just what’s going on with that one server, or just the Exchange system, to resolve the problem. We didn’t have to be too aware of what else was configured in the customer’s enterprise.

Because Exchange 2000 is so integrated with the Active Directory, so dependent on DNS, because it’s so dependent on the rest of the Windows 2000 system, we no longer have that luxury. When there’s a problem with message flow and Exchange 2000, the problem could be an Active Directory replication problem that started in an Active Directory site halfway around the world. We have to know what the configuration of the enterprise is sometimes. So if you, the customer, call in and are asking questions, or we’re asking questions about your enterprise, be patient with us, answer those questions, and help us know what your system is configured as. Understanding the enterprise helps us to identify the problem a little bit faster and know what possible scenarios there might be that we’re working with.

In the next slide, slide number 24 now, I move from the configuration settings to talking a little bit about the scope of the problem. When we get that slide up, you’ll see what I’m talking about.

When I talk about scope, I’m talking about things like, "How broadly is this problem affecting the system?" "When did the problem begin?" is a great scope question. "Has this ever worked?" That’s another really important one. "When did it stop working?" is usually the follow-up to "Has this ever worked?" "If it has worked, when did it stop?"

Sometimes, we’ll ask the question, "What changed?" Now, it’s been my experience, with a decade of doing technical support for many different products, the automatic answer to "what changed" is nothing, even if something has. Now, either somebody is lying, or somebody’s forgotten that a change took place, or somebody is ignorant that a change took place. But very often, there is a change. Something changed between the time that it was working and the time that it stopped working correctly. Understanding what that change was is what troubleshooting is all about, but it’s a useless question to ask them, "what changed?"

How many users is this affecting? Is it affecting all users, or is it affecting some users? Is it just users on one server? Is it just one user? Is it a couple of users on a particular server? Can this be reproduced with a new user?

Can this be reproduced with different client software? Sometimes, the problem depends or requires that a certain client software component be used, such as it can only be reproduced when using Outlook Express, or the problem can only be reproduced when using Outlook 2000. If that’s the case, we turn our attention more to the client than to the transport engine. Can this be reproduced from a different Exchange server? Is it happening with only inbound or only outbound?

All of these questions are questions that help me narrow the scope of the problem, they help me determine just exactly the nature of the problem.

Moving on to the next slide (slide 25), I mentioned before that NDRs can be extremely useful. In Exchange 2000 non-delivery reports, or the NDRs, follow the Internet standard RFC 1893. This is covered in Knowledge Base articles Q256321 and Q284204. The code itself is very revealing.

So let’s take a look at the example that I’ve given there. Here is JoeUser@Domain.tld. The message was being sent to that particular user.

It says, "There was an SMTP communication problem with the recipient’s email server. Please contact your system administrator." Now, the thing that’s important to me is, it tells me the server that generated this error. The server that generated this non-delivery report is Exchange1.YourDomain.tld. It’s not Joe’s domain, Domain.tld.

Another thing that this tells me is the error code was 5.5.0. That’s actually a pretty generic NDR. A very revealing NDR that leads me to solve problems very quickly is 5.7.1 That NDR message tells me automatically that the message was returned undeliverable because it couldn’t be relayed. There are some very common, known scenarios of why mail might be returned undeliverable with a 5.7.1 NDR code. 550 unknown user, that itself can be also very useful knowledge. If I was searching the Knowledge Base and I had this non-delivery, I would enter, in quotes, "Exchange 2000," and then I would say, "5.5.0." It would probably pull up just a small set of KB articles, which could lead me to a solution.

Moving on to the next slide (slide 26), we gather a few more details using the Event Viewer and the Queue Viewer, and sometimes by doing some research in the Knowledge Base and TechNet.

Now, the point I’m trying to emphasize here with the Event Viewer and the Queue Viewer, with Exchange 2000, is that most of the transport, most of the message flow, is done through the transport engine. The transport engine doesn’t log events very well, unless you crank logging up very high. The problem is, you can’t do it through the Exchange System Manager. The only way you can set logging high enough for us to get any significant detail is, you have to go into the registry.

So if you want to get more detail about what’s happening, what problems are going on with message flow, you need to go into the registry on the Exchange server. You need to navigate down to that particular key, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange TransportDiagnostics, and set all categories to 7. In the Exchange System Manager, if you were to set it to maximum or high, it changes that value to 5. So 7 is beyond the ability of the Exchange System Manager to set. Set that to 7, and as soon as you save that, that takes effect immediately. There’s no need to restart any of the services.

Where is the message going? We use the Queue Viewer and message tracking. When the customer is not sure where the messages are going, the first thing I’ll have them do is take a look at the queues on your Exchange server. We look at the SMTP virtual server queues or the X.400 queues.

Also, we can take a look at message tracking. Message tracking may have to be enabled. If it’s enabled, that usually means having to restart some services, but the way we track messages is using the message ID. After tracking the message, it will usually show exactly where the message moved. It went to this server. It went to this component. It went to this component. It went back to this component, et cetera. We’ll see some examples of both the Queue Viewer and message tracking later on in the slide show.

Finally, with the NDR codes, with the event IDs, and with the exact details within the events or the status of queues, we can start looking in the Knowledge Base or in TechNet to find KB articles that will help us solve the problem. Sometimes, depending on the queue that it’s in, and understanding the component that corresponds to that queue, we might be able to do some other searches, such as advanced queuing: AQ, or CAT, categorizer, SMTP service, or SMTP SVC and those kinds of things will help us to also narrow down our searches within the Knowledge Base.

Moving to the next slide now (slide 27), common issues. Now that we’ve gathered a fair amount of detail, we’ll begin to try to decide whether this is something we already know about. Now, in the next several slides, I'll talk about some very common scenarios that we see in Exchange support, and the solutions or the possible solutions to these scenarios.

If a customer calls in and reports that they can’t send to the Internet, but inbound message flow, meaning inbound from the Internet, is working just fine, and users on the same Exchange server are able to send messages back and forth to each other just fine, then the following are some of the things that we check.

We check the recipient policies to see that they’re configured correctly. You can look at recipient policies within the Exchange System Manager, or you can use LDP or LDIFDE, which are utilities for looking at the raw Active Directory. These tools come with the Windows 2000 Support Tools on the Windows 2000 installation CD. You can use those to look at the recipient policies.

What are you looking for? Make sure that the SMTP address is valid for the external domain. So when you pull up the recipient policy and you go to the "e-mail addresses" tab, take a look at the SMTP address. Is the SMTP address YourDomain.local? Something.local is not a valid Internet address. It’s something that is often used within a customer’s system to identify their local or their internal Active Directory, but that’s not their external address. The address that should be there is the address that you want your users to be known as externally. Your company name is Tailspin Toys, and your domain name is tailspintoys.com. You would have that address, instead of being tailspintoys.local, you would want to change it tailspintoys. That would then update all of your users, so that their primary SMTP address would be their user name@smtptailspintoys.com.

Internet message formats: within the Exchange System Manager, the Internet may possibly be misconfigured. Something that we saw a lot of when the product first shipped was that the default entry was being deleted or it was being changed. There should be a "Default" entry and the domain for the "Default" entry should be just asterisk (*).

Within the Internet message formats, check to see if there are any restrictions. Are there any message size restrictions? Are there user restrictions that prevent messages from being delivered?

Another reason why mail might not be moving out to the Internet is there might be an SMTP connector that has an incorrect address space. If you have an SMTP connector, and an SMTP connector is not required for mail flow out to the Internet, the address space should be just an asterisk (*), which means anything that’s SMTP, send it this way. Of course, that doesn’t mean local or Internal Mail delivery, but anything that’s not local or internal to the system, that’s an SMTP address, send it to me, and I can deliver it.

What customers often would do, when the product first shipped (and we still see this a little bit) was enter their local domain for the address space. Going back to my previous example, instead of putting an asterisk, they might create an address space that’s tailspintoys.com. Mail will never flow out. In a scenario like that, it will just sit in the SMTP connector queue, or it will be returned undeliverable, because there’s no way for mail to get out of the system. It doesn’t know how to get out of the system, because there’s an SMTP connector, and the SMTP connector has the wrong address space.

Other reasons why mail might not move out, there might be a problem with the router. There might be a firewall or a proxy misconfiguration. Port 25 might be blocked.

Cisco PIX firewalls are not an uncommon problem for us. Customers have the MailGuard feature enabled on their Cisco PIX firewalls. MailGuard can affect outbound and inbound mail flow for Exchange 2000. I believe even Cisco has recommended, if you’re using Exchange 2000, that you disable the MailGuard feature on the Cisco PIX firewall.

There may also be DNS misconfigurations. DNS misconfigurations mean your DNS server is pointing to a DNS server that doesn’t know how to look up example.com. It means that you’re getting invalid results. Maybe your particular domain you’re sending to, you’re trying to send to example.com and mail is not being delivered. So there’s a whole bunch of mail backing up in the example.com queue in the Queue Viewer. The state of that queue says, Retry. Use Nslookup and try and do an MX record lookup on example.com. See if they’ve got an MX record. Maybe they are the problem. Maybe they don’t have an MX record, or their MX record is pointing to an invalid host. So that’s another possibility, is a DNS misconfiguration. Not just on your side, but on the other customer’s side.

Another one that I haven’t listed here that I want to mention is, sometimes outbound and inbound mail flow can be affected by other software that might be installed on the Exchange server, such as virus scanning gateways. That’s a very common one, actually. It’s becoming increasingly common in this insecure world of ours. Virus scanning gateways can sit between the Exchange server and the Internet, and they should sit between the Exchange server and the Internet, but there may be some communication problems. It may be tweaking with the format of the message, or it might be binding to a port and thinking that it needs to send a communication to another port that Exchange isn’t expecting. So be aware of virus scanning software as a possible reason why mail is not moving.

Moving to the next slide (slide 28), here’s another common scenario, inbound message flow from the Internet. Inbound message flow problems usually start out as "Can’t receive from the Internet." A customer will call up and say, "I can’t get mail from the Internet." I’ll ask some questions to narrow the description of the problem and find out that outbound is working fine, and I'll find out that mail between users on the same Exchange server is working fine, but inbound is not working fine.

The first thing to check is make sure that the customer has a valid MX record. Is your MX record pointing to your Exchange server or to the server that receives mail for you? Use Nslookup to troubleshoot and figure that one out.

Again, as mentioned before, is there some type of an anti-virus gateway? Is there a smart host that sits between your Exchange server and the Internet that’s possibly intercepting the mail and then not routing it to you or not sending it to you properly?

As with outbound message flow, recipient policies can be a problem. If you’re not receiving mail, it might be because your users are tailspintoys.local instead of tailspintoys.com.

We might also have some problems with access or relay settings on the SMTP virtual servers. This is one of those that turns up within the NDR. Somebody else in another company may call you up and say, "Hey, Joe, system administrator, I just got an NDR trying to send to one of your users. It says 5.7.1. Why can’t I send to your user? I know the address is correct." You look at your recipient policies. It’s proper. You look at your MX record. It’s proper. You don’t have a firewall, a proxy server, or a router that could be sitting between the Exchange server. What you find out, when you go into the SMTP virtual server configuration, and you go to the Access tab to look at the authentication methods, is that maybe one of the authentication methods, usually the Anonymous authentication method, has been unchecked or disabled.

Now, by enabling all three of those methods of authentication, you’re not making your server more open to hacking. You’re just saying that these are the methods of authentications that I allow or will require. The Exchange 2000 server, SMTP virtual server, is secure by default. We don’t allow ourselves to be an open relay when we first come up. That’s become an increasingly big problem in the Internet now, is open relay servers. So when you first start up your Exchange 2000 server, there is no need for you to go in and muck around with the relay settings, unless you have a special configuration you’re trying to enable. Because the Exchange server is not going to be an open relay. The authentication methods don’t need to be changed. So check to see what those settings are.

Moving to the next slide now (slide 29), common issues between Exchange 2000 and Exchange 5.5. The issue that I’ll hear is they can’t send mail from Exchange 5.5 to Exchange 2000, or vice versa, they can’t send mail from Exchange 2000 to Exchange 5.5, but mail flow between users on the same system is fine.

I have found that this boils down to one of the three things. I’ve listed five things here, but they really boil down to three possible issues.

The recipient connection agreement is misconfigured or malfunctioning. Make sure that it’s functioning correctly.

The recipient policy is misconfigured, or the recipient update service is not stamping user objects with correct attributes. I consider those two almost the same.

Now, that begs the question, what should those attributes be? I’ve listed a KB article here, Q281761, that tells you what the required attributes for a mailbox-enabled user within the Active Directory and Exchange 2000 are. Pull up your user, the user that they’re trying to send to, and verify that they’ve got those attributes. Pull up the Exchange 5.5 user and make sure that the Exchange 5.5 user has those attributes. Now, if you’re coexisting between Exchange 2000 and Exchange 5.5, your Exchange 5.5 users should still have a user object when you have recipient connection agreements synchronizing things over. And they should still have some attributes, such as the legacyExchangeDN on their user. Make sure that those attributes are there as well.

Another gotcha, this one’s not too common, but it happens frequently enough that I check for it all the time. If mail is not being delivered one way or the other, I’ll check to see whether the user object has an attribute called TargetAddress. If you see TargetAddress on a user object, delete it. TargetAddress is an attribute for a mail-enabled contact. It should not be an attribute for a user object.

Then, the third possible reason why there may be mail flow problems between Exchange 5.5 and Exchange 2000 is, very often, the default public folder value on the mailbox store properties points to an invalid or an unavailable public folder store. When you take a look at the mailbox properties for your mailbox store in the Exchange System Manager, every mailbox store in Exchange 2000 has a default public folder store. This is not uncommon in Exchange 5.5 migrations. Customers are removing Exchange 5.5 servers that once were the servers that housed all the public folders. If you’re not careful about moving those public folders off and making sure that those settings are updated properly and changed within the mailbox properties, then Exchange tries to send a message to Exchange 5.5. Even though it doesn’t need to go to a public folder server, if that attribute is not there, the mail will camp out in the categorizer queue. It will camp out in the "awaiting directory lookup" queue. We’ll talk more about that particular queue in a moment. So check to make sure that your mailbox store properties have public folder stores that are all correct.

And make sure that those stores are mounted, not just that they’re correct servers or correct public folder stores, but make sure that the public folder store is actually mounted.

A fourth reason, this is one that most customers pick up on their own, but check nonetheless, is the MTA may not be started, or possibly MTA-to-MTA communication is not working. You can turn up the X.400 service and interface diagnostic logging on both sides, on Exchange 5.5 and Exchange 2000. Set those to maximum and look for events, warnings, or errors that the MTA service is reporting. There may possibly be some name resolution issues there. I’ve listed a KB article that talks about a problem that was fairly common pre-SP1, but that we don’t see too much anymore.

Moving on to the next slide (slide 30), we have two more slides talking about common issues. This is the scenario where customers are unable to send to users on an adjacent Exchange 2000 server. In fact, they may not be able to send to users on the same Exchange 2000 server. If you track the message, using message tracking, the message may seem to stall in the "Messages awaiting directory lookup" queue.

This is the scenario that I was describing before, where mail seems to camp out in that particular queue. It’s sitting in the categorizer. If we could open up the transport engine and look at that queue, it’s sitting in the categorizer component. So try to remember what the categorizer does, as mentioned before. There are a couple of KB articles that describe what the categorizer does.

Common issues, reasons why the categorizer is not moving mail or taking care of it, include the public folder store value is incorrect.

The recipient policies are misconfigured or user values, the proper values are not being stamped.

Domain controller or global catalog replication problems can be an issue. If it’s unable to communicate with the Active Directory, there are going to be some problems.

I’ve also mentioned here an issue that’s not necessarily related to categorizer. Sometimes mail flow between two Exchange 2000 servers is related to issues with routers, firewalls or proxy servers again. You use Telnet to troubleshoot that issue.

If you can’t move mail from one Exchange 2000 server to another Exchange 2000 server, but you can send mail between users on the same server, start Telnet up on one of the servers, connect to the other one, and try to send a message using Telnet and the appropriate ESMTP verbs. Pay especially close attention to the ESMTP verbs when you issue the EHLO command.

Q290290 gives a good description of a scenario where a customer will apply an IIS hotfix or an IIS service pack and that will overwrite the Exchange 2000 SMTP service extensions that we’ve created. That describes how you could detect that problem, and how you can fix that particular problem.

Moving on to the next slide (slide 31), this is the final issue. I’m just going to breeze through it really quickly, because I don’t think that most of you will be encountering this issue. You can’t send to or from a foreign e-mail system to Exchange. Often, mail flow is working within the system, or maybe it was working at one time, but now it’s stopped.

Common issues are the connectivity components, or the component that talks to the foreign e-mail system may not be functioning properly. Check that, and make the permissions are not the issue. Permissions tends to be a really big issue in this kind of a scenario.

Make sure the MTA transport stacks is started.

One mail message sometimes, within a queue, may block the entire queue. So check to see if there’s one message that’s conspicuous. Maybe it has a gigantic attachment size that’s blocking the entire queue. So check for those kinds of things.

My recommendation, when you run into an issue with mail flow between an Exchange 2000 server and a foreign e-mail system, is turn up diagnostic logging and get as much detail as you can. With the Lotus Notes connector, try installing a different version of the Lotus Notes client. With a GroupWise connector, verify the permissions on the client that you’re using to connect to the NetWare server. Finally, gather as much detail as you can and call PSS. These issues can sometimes be really difficult and troublesome. That’s the reason why we have some highly trained engineers to work on them.

Moving to the next slide (slide 32), these two slides might be the two slides that you print off and pin up on your wall. I hope that they’re helpful. I spent a lot of time working on them to make sure that they would be useful. When you take a look at this table, it lists the name of the queue that you see in the Queue Viewer, its corresponding component within the Exchange transport engine, which we talked about in the earliest part of the slide show, and then it also gives you some troubleshooting suggestions. So if you see mail in this particular queue, what should you do?

The PreSubmissionQueue matches up with the PreCategorizer. The PreCategorizer normally has nothing going on with it, except if some third-party application has been installed, like an anti-virus gateway. If you see mail queued up in the PreSubmissionQueue, the first thing to check for is if you have a third-party application like an anti-virus gateway. See how it’s configured. Try stopping that service and then resubmitting your messages.

Here’s the big one, "Messages awaiting directory lookup." If they’re sitting in the Messages awaiting directory lookup queue, that’s the Categorizer. As I’ve mentioned before, there are a lot of things to check. Check to make sure DNS problems aren’t there. Make sure Active Directory is healthy and that you have the proper attributes for users. Check limits and restrictions within the Internet message formats and on the connectors. Check recipient policies to make sure that the e-mail addresses are configured correctly. Check distribution group properties just to make sure the DL expansion should function correctly. Check permissions of objects within Active Directory. This is an obscure one: checking permissions of objects in Active Directory. Sometimes, in their attempt to try to lock down their Active Directory, customers will go and change the default permissions of individual objects or containers within the Active Directory. In doing so, they cause problems for message flow within the Exchange 2000 system. So check permissions using any one of a dozen different utilities that will verify and test permissions on the Active Directory. Also, check to make sure the public folder store value in the mailbox store properties is set correctly.

On the next slide and continuing this particular table, we see Messages waiting to be routed. If it’s sitting in the Waiting to be routed queue, that means it’s in the PostCategorizer. This usually means that we’re waiting for the routing engine to return us a route. We’ve decided that it needs to go to a remote system, but we don’t have a route yet. Make sure the routing engine is started. Make sure your address spaces are configured correctly. A great way to troubleshoot this is to use the Winroute utility, which comes on the Exchange 2000 server CD, to get a report of your link state table. Then, take a very close look at the address spaces, using that utility. Pay attention to the little red check boxes. If you see a red check mark next to anything within the Winroute, use that to lead you to solving the problem.

Next, we have local delivery queues. It will say, "Local delivery" and then "Your server name." That’s the store driver. That means it’s waiting to be moved out to the information store. Make sure the information store is started. Make sure that the mailbox and public folder stores are mounted.

Finally, remote queues. The remote queue name depends on the remote system that the message is being delivered to, or the connector. This is the SMTP service. Make sure that DNS lookups are working. Make sure that SMTP service is started. Check for network problems. Use Network Monitor. Check for problems with firewalls and proxies. We’ve talked about these a lot.

In the next slide (slide 34), here’s an example of what the Queue Viewer looks like. We’ve just talked about the queues, what they mean. Now, here’s a view of what the Queue Viewer looks like.

What you should see, at the very top, is the local delivery queue. The local delivery, for this system, is ken-wood.net. That’s the local domain and the local delivery queue for that particular server. Here’s the PreSubmissionQueue, messages pending submission. This is, remember, the PreCategorizer queue. There shouldn’t normally be anything in the PreSubmissionQueue. "Messages awaiting directory lookup," as mentioned before, that’s the categorizer. "Messages waiting to be routed," that’s PostCategorizer or routing engine issues. Then, we have a connector, the Snickers – Martin RGC is a routing group connector. Then, we have some other connectors, Martin SMTP connector, and it includes some remote domains that it’s trying to deliver to, bb1.imustplay.com, for example. These are remote delivery queues.

Now, take a look over there on the connection state on some of these. Notice that some of them say Ready. That means there’s nothing in there. I don’t have anything to do. Some others say Active. That means they’ve got something in the queue, and they’re sending it right now, and it’s working. Then also, there are some that say Retry. It tells you, in the next column, when was the last time it tried. If a connector is in a retry state, that’s one of those scenarios, as I mentioned before, where you need to pay close attention to DNS. Make sure that you can actually do a valid DNS lookup on that particular domain.

In the next slide (slide 35), I have two examples of message tracking. At the top, it’s an example of a message being delivered to a remote system, to snickers.ken-wood.com. At the bottom, I have an example of a local delivery system, a message being delivered to the local store.

Just quickly looking over the top one, the remote delivery queue, you see Message Submitted to Advanced Queuing. You remember I said every single message going to the transport goes to advanced queuing; Message has started submission to Advanced Queue; Message Submitted to Categorizer — remember the advanced queuing always send the mail first to the categorizer. Then, it says Started Outbound Transfer of Message. That’s a cue to me. That flags to me that this is going to a remote system. Message transferred to the particular domain that it’s being sent to through SMTP, and that was the final delivery of that one.

At the bottom, we see just the reverse; the message first is Submitted to Advanced Queueing. Advanced queuing submits to the categorizer, there in the third line. In the fourth line, it says Message Delivered Locally to, and then it tells you the mailbox. Then, SMTP store driver: message delivered locally to the store; and it gives you that user again.

These are examples of successful message flow. If message flow is not working, you’ll see it end up in a particular queue, like it will end up in the Message Submitted to Categorizer, and then that’s it. Message tracking or properly delivered messages do not end at the categorizer.

Moving on to the next slide (slide 36), we’re getting almost down to the end. Just a few more slides to go. If you get to this point, the Queue Viewer, message tracking, and event logs, they haven’t helped you solve the problem.

Make sure that, in the diagnostic logging, the transport components are cranked up to level 7. If you’re troubleshooting a problem between Exchange 5.5 and Exchange 2000, make sure the X.400 Service and interface are set up to maximum. You can set those up through the Exchange System Manager, or the ESM.

For additional logging, to get additional details, we also have some transport event sinks such as the protocol logging transport event sink, which is called Protolog.dll. This can be obtained from PSS. The message archival sink is the equivalent of message archival in the Exchange 5.5 Internet Mail service. That now ships with the Exchange 2000 SP2.

On the next slide (slide 37), we have just a brief description of some really cool utilities for getting detailed configuration about the network configuration and how the server is communicating with the Active Directory. We use Netdiag a lot. For Ipconfig /all, pipe it to a text file, if needed, so that you can take a look at that in the future. Take a look at DCDiag. Run that appropriately to see how the domain controllers are communicating.

On the next slide (slide 38) is what I’ve titled "Dumps." Dumps are getting a file copy of certain attributes or whole objects within the Active Directory. Sometimes, I’ll request that the customer send me a dump of the entire configuration naming context. If it’s a big organization, that can be many megabytes, because you’re dumping a huge chunk of the Active Directory, but it helps us to search for certain values that we might be missing.

You can use LDP to get dumps of single objects. It’s great for browsing. I highly recommend you get comfortable in using LDP. I think that’s called the Active Directory administrator utility, when you go through the menus. It will let you look at user objects and contact objects. These are some of the objects you can look at when you’re having message flow problems: SMTP virtual server, recipient policies, and the mailbox store.

We can also get admin dumps from Exchange 5.5. In Exchange 5.5, the way to get an admin dump is to go into the Exchange 5.5 administrator in raw mode, hold the CTRL key down while you select an object, and click on Raw Properties. So File, Raw Properties, and hold the CTRL key down. After it has displayed the raw properties, let go of the CTRL key. It will write a file called Admindmp.txt to the Exchange server Bin directory. The objects that I recommend dumping are site addressing and connectors. You could dump users and compare the users. You can dump the MTA object.

Finally, you could also dump the output or just copy the output from various tests, such as using Telnet, Nslookup, and Adsutil.vbs, which is a utility that we use for troubleshooting the metabase. There is an example right there of dumping the smtpsvc node within the metabase. The metabase, as you’ll recall, is the component that stores, kind of like the registry, all of the IIS components and their settings, such as the SMTP service or NNTP. Even the routing engine stores some of its information there. We synchronize our configuration from the Active Directory into the metabase.

In the next slide (slide 39), I’ve called this "Traces." Now, this is really advanced. For most of this stuff, the customers will collect the data and send it to us for analysis.

If you’re stouthearted, you might enjoy using Network Monitor or Sniffer to capture traffic on network. If you’re having problems delivering mail, you can use Network Monitor sometimes to identify what the problem is.

Winroute ships with the Exchange 2000 server CD. So does Regtrace.

Winroute will present you with the report. It will give you the data, and you can go through and take a look. You can look for the red Xs, or you can look at the address spaces and that kind of thing.

Regtrace, on the other hand, lets you capture the data. It stores it in a trace file, but you have to send that to PSS. That’s debug-level information, and we have to use a special viewer to view that.

So, we’re coming down to the final couple slides. This is just a summary. I spoke before of troubleshooting in general. This is transport troubleshooting logic in specifics (slide 40). This is the heart of troubleshooting a problem in Exchange 2000 message flow.

The first thing to ask is, "Did the message return undeliverable? If it did, what’s the NDR?" The second thing, if it didn’t, "Where’s the message? If the message didn’t return undeliverable, where did it go? Is it in a queue, or did it just vanish? If it’s in a queue, what’s the status of that queue?" The third thing, track the message, "Where does it end up? Does it end up in the categorizer? Does it get submitted to pre-submission? Where does it end up that it’s not going?" That can help you when it comes time to do some of the advanced diagnostic logging. Turn up diagnostic logging in the registry, "What are the events that show up? What are the descriptions in those events?" Then finally, I’ve listed some troubleshooting guides. There are three troubleshooting guides that we’ve created here in PSS to help you troubleshoot these particular problems: {Q281800, "Troubleshooting Message Failures in Exchange 2000" (http://support.microsoft.com/support/misc/kblookup.asp?ID=281800); Q257265, "General Troubleshooting for Exchange 2000 Transport Issues" (http://support.microsoft.com/support/misc/kblookup.asp?ID=257265); and "Troubleshooting Message Flow in Microsoft Exchange 2000: A Step-by-Step Approach" (http://www.micrtosoft.com/exchange/techinfo/administration/2000/messageflow.asp)}.

The next slide (slide 41), the final slide before question and answer, is just a summary of the tools that I’ve mentioned here within this slide show. By now, you should be comfortable and familiar with all of them.

So, we are now to the question-and-answer phase.

Jason Bennet: Thank you for the presentation, Tom. Just a couple of quick notes before we move on to the Q&A portion of this Support WebCast: To access information on all upcoming Support WebCasts and the archived content from all past WebCasts, an easy-to-remember URL is http://support.microsoft.com/webcasts/.

Again a reminder that the Q&A portion of this Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of these Support WebCasts. If you do need technical assistance, you should submit an incident on the Web, or call Microsoft Product Support Services and speak to a Support Professional. We only take questions during the live WebCast.

We did get a few questions, and I want to thank the people who have been sending in questions.

Tom: Yes, there is. There are a couple of different places to go. The first place I would go is http://www.microsoft.com/exchange/. On the menu bar on the left, click Technical Resources. There are many articles that talk about deploying, installing, configuring, administering, and managing Exchange, and all those different kinds of things. Very often, that will also link you over to the Support Web site, which is http://support.microsoft.com/. From there, you can pull up the Exchange site that gives detailed information about Exchange 2000. Recently, we’ve done a really good job of linking most of the really good support documents to the product group's Web site, which is http://www.microsoft.com/exchange/.

Jason: When you have a mixture of remote sites, some Exchange 5.5 native and others an Exchange 5.5/Exchange 2000 mix, do you recommend upgrading your backbone to Exchange 2000 to take advantage of the enhanced features, or leave it as Exchange 5.5 until all the sites have the Exchange 2000 bridgehead servers?

Tom: By backbone, if you mean bridgehead servers, yes, upgrade your bridgehead servers to Exchange 2000. Get your Exchange 2000 servers, the backbone, all talking SMTP back and forth to each other. It's far less problematic than the MTA-to-MTA communication between Exchange 5.5 and Exchange 2000. It's more reliable, in my experience.

Jason: So instead of the messages to the MTA, the message from the client goes to the message store first, then to transport core? Does that mean that the message is committed to the store before it’s sent?

Tom: Yes. If you want to get detailed, what happens is the message is submitted to the information store. An object is created, and it’s placed in a table called the Temp table, within the information store, which is where it sits. The actual message, the entire message sits in the Temp table, while only the header portion, the Imail.msg portion, gets submitted to the transport core. The transport core then, if it decides it needs to be delivered locally, will pass that information back to the store. The store will then move it from the Temp table into the user mailbox.

Jason: Where are outbound SMTP messages persisted? Are they also found in the VsIx directory?

Tom: No. They’re saved in the information store. Specifically, they stay in the MAPI information store, the .edb information store, and not the streaming database, the Web store. When we’re going to be sending remotely, we do have a place where we copy the header information to the Web store, but the outbound messages remain in the Private EDB. Actually, let me correct that. They stay in the private EDB until such time as we realize that we’re going to be sending it out to an external Exchange 2000 system. At which point, we copy it and transfer or convert it into a MIME format, and move that into the STM file, into the streaming database. So there is now a MIME-encoded message blob, if you please, sitting in the Web store. After we’ve connected to the remote system, we transfer it. Outbound messages are not stored in the Queue folder.

Jason: All of our mail servers are Exchange 2000, and we’re in the process of replacing Exchange 5.5 IMCs for outbound SMTP, but not inbound yet. Unfortunately, with Exchange 2000, SMTP connector cost is low. The Exchange 5.5 IMCs use the Exchange 2000 SMTP connector to send its own NDRs. Is there a way to have the Exchange 5.5 IMCs use themselves for the SMTP address space and the Exchange 2000 servers use the SMTP connector as their SMTP address space?

Tom: If they’re in separate routing groups, you can scope the address space. You can change the scope of the address space to be local routing group or local site only. Other than that, I don’t know of a way, right off the top of my head. That would be one of those where we would want to do a little bit of research. Call in to PSS, and we could do some research and look it up. But I don’t know of a way, off the top of my head.

Jason: Will Microsoft ever convert 8-bit MIME messages to 7-bit MIME messages? Right now, the messages accepted with body = 8-bit MIME are NDR’d if the receiving server does not accept 8-bit MIME messages.

Tom: Yes, we are capable of downgrading that. I believe there’s a setting on the SMTP connector that will do that. There’s also a KB article. There are a couple of KB articles that talk about what to do if the remote system won’t accept 8-bit MIME messages. It’s not uncommon. I wouldn’t say it’s really common, but it’s not uncommon for customers to call in with that exact question. There is a change that can be made in the SMTP connector that can affect that.

Jason: Where can I get a list of possible queues and what each one is used for?

Tom: If you mean by queues, the queues within the Exchange 2000 system, such as the SMTP virtual server queues, the list of the queues is in the table that I had in slide 32 and 33. I built that list, that table, for exactly that reason. In other words, if you see it in this queue, it means this. So I would use that particular table. Do we have a KB article that describes that? I don’t think so. I haven’t seen one yet, but I’m making a mental note to myself. I need to go back and do such a thing, get a KB article out there, so we can refer customers to that.

Jason: What are some advantages and disadvantages of setting external DNS in the SMTP virtual server?

Tom: The reason why customers might set an external DNS server in the SMTP virtual server is because they want to specify a different external DNS server than is pointed to as the forwarder for the internal DNS server. The configuration that we’ve found to be the most reliable and the most effective is that you have your Exchange 2000 servers, the TCP/IP properties, point to an internal DNS server. Then, have your internal DNS servers managing the local domain of course, and have them configured to point to forwarders. The forwarders then point to their ISP’s DNS servers. That tends to be the most reliable way. And do not configure external DNS servers in the SMTP virtual server. Now, there are some specific reasons why customers need to have a different external DNS server in that list. That’s the reason why we provided that functionality. But in general, unless you need to have that, I do not recommend that you configure the external DNS servers’ property within the SMTP virtual server.

Jason: The only section I did not fully grasp was the Exchange 2000 to Exchange 5.5 and how the MTA interacts with the Exchange 5.5 server. Does it work the same way when it is Exchange 2000 to Exchange 2000? And where does it sit in context to the routing engine?

Tom: The MTA service hangs off of the store. It pulls the message off of the store. Actually, the way it was described to me is that the messages that are being sent to Exchange 5.5 have an MTS-IN and an MTS-OUT folder, just like foreign connectors did in Exchange 5.5. The routing logic is all in the routing engine, which is transport core. So MTA is really not considered transport core. It’s external, and all that the MTA does in Exchange 2000 is transfer messages.

As far as communication is concerned, transferring the message from an Exchange 2000 MTA to an Exchange 5.5 MTA is exactly the same as it was in Exchange 5.5, exactly the same. In fact, from the perspective of the Exchange 5.5 server, it’s another Exchange 5.5 MTA. The same protocol is being used, the same methods, the same steps to setting up and managing the connection and tearing it down, same format of messages, et cetera.

Between Exchange 2000 servers in the same routing group, it’s always SMTP. Between Exchange 2000 servers in another routing group, where you’re using a routing group connector to connect them, it’s always SMTP. We never use the MTA in a pure Exchange 2000 environment. In fact, if you’re running pure Exchange 2000, you could turn off the MTA transport stacks, and you should still be able to deliver all messages.

Jason: If Exchange 2000 fails to connect to smart host, what intervals does it retry?

Tom: Those intervals can be set within the SMTP virtual server, I believe. So it’s configurable.

Jason: How does SMTP load balance between SMTP connectors, if both have equal cost?

Tom: It depends on the domain and retry state and how active the link state algorithm and the routing engine are aware of how many messages are queued up to a particular domain. We try to load balance. It’s fairly sophisticated.

Jason: Should the crash of a single global catalog in a site with four global catalogs mess up your Exchange services?

Tom: In a perfect world, no. In reality, it can, because when the Exchange services start up, DSAccess pulls that information. It builds a list of the global catalogs, DCs and ConfigDCs. Then usually, it connects to one particular global catalogs and stays with that one global catalog. That information is cached within the Exchange transport, and we don’t look for it again. We don’t check to see it again. So if that’s the global catalog that we were connecting to and looking for all of our requests for, I would expect that if it went down, the transport engine would probably be the first thing to stop working. Other components continue to use DSAccess, and DSAccess may continue to update that information. But the transport engine caches what DSAccess gives us. Then, we never talk to DSAccess again.

Jason: Can Exchange 2000 SMTP server be configured to run on a different port and still be able to talk to other Exchange 2000 servers?

Tom: The SMTP service, when it makes a connection to the remote server, is expecting to talk on port 25. I want to say yes, it should be possible to do that, but I think it would be very difficult. I would probably want to know more about why somebody would want to do such a thing. Perhaps there’s a better, alternative approach to achieving their desired objective.

Jason: How do you set up the link monitoring type monitoring in Exchange 2000?

Tom: I don’t know, right off the top of my head.

Jason: Okay.

Tom: I could find out, but it would take a long time. So I can’t answer that one right now. If you’d like, I can get back with you.

{Follow-up answer: In Exchange 2000, link monitoring is implemented in two server monitors: SMTP Queue Growth monitor and X.400 Queue Growth monitor. These can be configured in the Exchange System Manager, under the Monitoring tab of a given server's properties. The process requires two steps:

1. Select the items you wish to monitor and define the warning and critical states.
2. Create notifications (e-mail or script) to respond to warning or critical states for those items being monitored.

It is admittedly a little obscure, but I found all of the answers to this question in the Exchange 2000 online Help and after doing a little bit of testing.}

Jason: Okay, great. Small Business Server 2000 occasionally has the IMS (or IMC?) service display as failed and must be restarted. In this single-server network, can the IMS or, I guess they’re not sure if it’s IMS or IMC, be disabled?

Tom: If we’re talking about Exchange 2000, you do not have to have an Internet Mail service. An Internet Mail service is like the name. If you upgraded it from Exchange 5.5 to Exchange 2000, Internet Mail service or Internet Mail Connector is just a name. It’s become an SMTP connector. You don’t have to have an SMTP connector for Exchange 2000 to communicate with the Internet. So you could remove that SMTP connector.

Now, if we’re talking about Exchange 5.5, that’s a different matter, and that's beyond the scope of this presentation.

Jason: Is it possible to link a message ID from Exchange 2000 to a message ID of another e-mail system? I’d like to be able to track the message in and out from Exchange 2000 to SmartHost. Right now, we track Exchange 2000 and then look for a message in SmartHost around the same time that it’s logged.

Tom: There may be a third-party method. I don’t know, off the top of my head. That’s another one I can do a little bit of research on, to see if we have a method of doing that. I think that that’s probably going to be a third-party solution.

{Follow-up answer: The closest thing I could find is in the Message Tracking log, field 18 Linked-MSGID. However, in practice this field turns out to be more often than not an X.400 style MTS-ID, and the MSGID field is often the Exchange 2000 SMTP style message ID. I don't see the functionality you're looking for in our product. There may be a third-party product that can do this.}

Jason: Okay. Are there any plans to use wild card in recipient policies? This is a big limitation for us.

Tom: I wish I had the program manager here, I could ask him. I don’t know if there are any plans. I haven’t heard of any plans of doing that. Again, that’s one of those that I can research and get back on. If it’s a big issue, we want to know, so that we can let the product group know and have that addressed.

{Follow-up answer: My recommendation is that you create a support incident or work with your technical account manager to clearly define what it is you're looking for. We will do research to determine there isn't an acceptable alternative, and then as needed, we can file a design change request with our development group to have this feature added.}

Jason: PIX firewalls problems, like .stuff message failures from inbound servers, is this common and repeatable? Is there a resolution?

Tom: With PIX firewalls, when we have a problem communicating inbound or outbound through a PIX firewall, and they have the MailGuard feature enabled, what I see every single time, if I connect using Telnet, is the banner is unique. The banner is clearly a PIX banner, a MailGuard banner. It’s distinct. It’s a bunch of asterisks and some other stuff there. When you issue the EHLO command, you get nothing back, because they squelch the EHLO command. Is there a way to fix that? The official solution that we’ve recommended to customers, and this is based on a KB article that Cisco put out and some discussions that we had with Cisco, is to turn off MailGuard. If that’s not an acceptable solution, I think that you’ll have to do a little bit of research between Cisco and our KB articles to try to figure that one out. That’s a tricky one.

Jason: Is the message size restriction part of routing protocol? Is there an article that explains the routing configuration options, such as message priority, message size, et cetera?

Tom: The routing restrictions, such as message size, are taken into consideration by the categorizer. The routing engine looks at link state. It looks to see, is the connection up? Is it down? What routes are available, and what’s their state? So the link state algorithm and the routing engine, they’re looking to see what routes are out there and are they active. What’s their status? If they’re not active, are they in a retry state? Are they in a questionable state, or are they down? That’s pretty much all that the link state does. Everything else, routing restrictions and a lot of the logic that was used in Exchange 5.5 routing, is now handled by the categorizer. I hope that answers that question.

Jason: I will take a moment for feedback; maybe this is your first time coming into these Support WebCasts, or maybe you’ve come in quite a few times — we’re definitely interested in your feedback regarding these WebCast programs. You can send us feedback using the e-mail alias feedback@microsoft.com. Just put "Support WebCast" in the subject line, and that gets it routed to my inbox. I go through it and pull it out for the appropriate managers. So you can talk about the presentation, the information presented, what you think of the presenter, what you think of me, the Q&A, whatever you want to comment on. If there are future topics you’d like to see covered, all of that is fair game. So we’re definitely interested in growing and evolving according to your needs. So please let us know.

Tom: I want to say the existing one is sufficient. When you have an SMTP connector, it’s not like an X.400 connector, which is usually only point-to-point. Yes, it’s multi-point capable, I guess is what I would call it. You can add another address space, if you want to add another domain that you want to specifically connect a certain way.

The reason for setting up an SMTP connector, by the way, is not because you need to have a method of talking with the Internet. The reason for doing it is because you want to configure certain types of restrictions. For example, you want to turn off EHLO, or you want to configure eturn or something like that. Those are things that are not configured in the SMTP virtual server. They’re done through a connector. So I believe you can just simply add an address space to an existing connector. You don’t have to create another connector.

Jason: Why would a message go to a Bad Mail folder? I’m not certain I’m reading that correctly.

Tom: That’s correct. Why would it go to Bad Mail? It would go to Bad Mail because it was malformed. BAD Mail is for inbound, inbound from a remote system, and malformed message. We didn’t know how to handle that message.

Jason: How can we monitor for old messages stuck in the Queue or pickup folder? We had an issue where messages were stuck in the Queue folder and were not showing up in ESM.

Tom: Messages in the Queue folder should only be there long enough for the message to be submitted to the local information store, if it’s going to be delivered locally, or transferred to the next SMTP server, the next hop within the Exchange system. But there are some occasions where those messages don’t get removed, for some reason. If we’re talking about messages or files in the Queue folder that are many weeks old, they can be deleted. Why are they piling up? I am not 100 percent sure why they are piling up. That’s one where I would recommend calling in and opening up an incident with Product Support Services. Perhaps virus scanning software is holding it open and keeping it there. That’s the best I can answer, without doing a lot of research. I would recommend opening a support incident for that one.

Jason: Can current sessions be logged?

Tom: I don’t know, and I’d like to research that one, because I would like to know the answer to that one, too. I’m tempted to say no, but I’m not going to say that too hastily. I think that maybe it can be, but I would have to do some research.

{Follow-up answer: The closest equivalent I can find is a performance log. Using either Perfmon4.exe or the System Monitor Control ActiveX^® snap-in, you can log all counters for a given object. Under SMTP Server I found several counters that were related to connections, such as Inbound Connections Current and Outbound Connections Current. This would, of course, only log raw numbers, and not specific source hosts. There may also be a way to glean this information from event logs with SMTP diagnostic logging set to maximum (level 7), through the registry. Once again, I think this is either a "partner opportunity" or a feature of another component of the network (that is, the routers or firewalls may log/audit this type of data).}

Jason: We’re heading into product support territory here, but I’m going to ask the question for the sake of commentary: Why would the store grow up to 2 GB on an SMTP connector server? There are no mailboxes or public folders on these servers?

Tom: That’s a good question. Why would it? If there are no mailboxes, it’s not going to be delivered inbound to that. If there are no mailboxes, then nothing is being created locally and being transported out. So the only things that should be there are messages that are persisted in the Queue folder. If messages have been possibly misrouted or if distribution lists were being expanded, possibly message looping. Yes, again, that’s another one that I’d have to do some research on. I would recommend, if this is problem, that they open a support incident.

Jason: Is the message tracking component programmable? We’d like to write a small app that would use its functionality.

Tom: There may be some functionality for on MSDN^®. With SP2, I know they’ve added some new hooks, some new transport sinks or SMTP events that we can write code to or custom events, custom code. So I would take a look at MSDN. Navigate through the library, down to the Messaging and Collaboration section.

Jason: If you have a Windows/Exchange server with five users accessing it using Windows 98, do you need five licenses for Windows 2000?

Tom: You’re talking to a support professional, not a sales rep. I don’t know. I have no idea. That’s a sales question. I would talk to the sales rep.

Jason: The best thing to do would be to get onto the product site {http://www.microsoft.com/exchange/}.

Tom: Yes.

Jason: They’d probably be able to get some information about licensing there.

Tom: Yes, or they can call the sales number {(800) 426-9400} and ask that kind of a question.

Jason: Okay. The next question: Are you aware of any security enhancements contained in Exchange Service Pack 1 or 2 that would create an "object not found" message when users attempt to "Send page by e-mail" from Internet Explorer?

Tom: If there was such a function added, it would be documented in the release notes. I don’t remember reading about anything like that in the SP1 or the SP2 Release Notes. The release notes also will often point to a KB article or two KB articles, in the Knowledge Base, that will give a list of all of the hotfixes, bug fixes, or enhancements that were added in a particular service pack. I would have to do research for that one. It’s not something that I’m familiar with off the top of my head, but that’s where I would look. First look at the release notes. Then look at each of the KB articles that are listed as bug fixes or enhancements to SP1 or SP2.

{Follow-up answer: I could not find such a feature or bug fix in any Exchange release. I also did a quick search of the Internet Explorer Administration Kit (IEAK) and Windows 2000 Resource Kit Group Policies documentation to see if there's a way we can disable the Send…Page by E-mail feature. You can disable nearly every other feature of Internet Explorer, but I could not find a way to disable this feature. Perhaps a more thorough review of either the IEAK or Group Policies documentation would reveal a setting for disabling this feature. As far as Exchange 2000 Server blocking these types of messages, it's not even in our sites. I would highly recommend opening a support incident to report this as a security bug so that it can be brought to our development team's awareness. This could also be considered an "application filter" in terms of firewalls and content gateways, and so you might look up that avenue.}

Jason: Considering that DNS is so vital to the appropriate functioning of Exchange 2000, what are some of the most common DNS problems you’ve seen? If you can include some of the more advanced problems, that would be great as well.

Tom: That would be a Support WebCast in itself. In fact, I’ve seriously thought about doing a Support WebCast on that. One of our internal problem control engineers, Mohammed Nadeem, has recently put together a slide show, and it’s a pretty lengthy slide show too, that talks about DNS problems that are specifically related to transport. It covers probably 90 percent of the known and common issues, as well really good coverage of the tools and utilities that we have. So I’m going to make a note here that we should perhaps do a WebCast, or if nothing else, let’s make sure that we have a KB article about that.

Jason: Right. Is there something general they could do a search on now, that would get them at least a start?

Tom: You’ll probably get quite a few hits, but not more than 100, if you type in "Exchange 2000" in quotes and then "DNS".

I’ve done that before on the internal KB, and I've received fewer than 100 hits. I’ve gone through every single one of them. I’ve pulled together a FAQ for just this kind of thing within the last six months, but I don’t remember everything off the top of my head.

I mentioned one of them: a very, very common issue is that the Exchange server’s TCP/IP properties is pointing to a DNS server that’s either not functioning or is returning invalid results.

Troubleshooting approaches that I will take are, if they have multiple DNS servers in their TCP/IP properties, I’ll remove them, one at a time, or remove all but one, and check to see that that’s okay.

Another common issue that is see, I don’t know why this is a big deal, but sometimes having an external DNS server in the SMTP virtual server could affect outbound mail flow. Removing the DNS server from the external DNS servers is something I’ll often recommend to customers as a troubleshooting step.

For an internal DNS server, I mentioned this in the slide show, the way we recommend configuring DNS is that the Exchange 2000 server should point to an internal DNS server. The internal DNS server should have forwarders configured that point to a DNS server out on the Internet.

Jason: Do you have a best practice SMTP configuration for a master Exchange server, two-node Exchange cluster scenario?

Tom: If we do have such a best practices document, it would out at the http://www.microsoft.com/exchange/ Web site that I mentioned earlier.

Jason: Okay.

Tom: In fact, when I was preparing for this, I searched for just about link I could find, at that site and at external links, even third-party sites that have Exchange as their specialty. I did not find as much information about SMTP as I wished I could have found. There is a lot of good information in the Exchange 2000 Resource Kit, although it’s scattered throughout the entire book. It’s not well organized, but there is a lot of good information there. That’s one good place to try to get more detail. There is also some really good information on MSDN. There are a couple of TechNet articles that do a really good job of talking about SMTP in general and certain deployment scenarios in specific, but that one, I don’t recall.

Jason: On our organization, we have a mixed environment of Exchange 5.5 and Exchange 2000. I have Exchange 2000 and Exchange 5.5 VH servers. Whenever the WAN link goes down, the messages bounce between Exchange 5.5 and Exchange 2000 servers. In a couple of minutes, the users will see the message bounce back, stating, "Your message is bouncing between the server." Is there any way I can queue this message until the WAN link comes back up?

Tom: I’m going to defer that one to a support incident. That’s one where I would have to gather a considerable amount of information about their environment and do some research before I could give them an accurate answer.

Jason: Okay, fair enough.

Tom: I don’t know if they have a contract or not, but I would say, for a scenario like that, it should be well worth even a credit card incident.

Jason: Okay. You can definitely call into Product Support Services. The an 800 number for that is (800) 936-3500. You can also go to http://support.microsoft.com/, and there should be a link to submit an incident right there at Contact Microsoft Online.

Tom: Is Symantex capitalized, as in the name of a company?

Jason: Yes, it’s a third party.

Tom: Okay, I’m going to defer that one to a PSS incident as well.

Jason: Okay.

Tom: I don’t know. We’re getting into very specific, specialty issues here that are beyond the scope of my experience. I’ve had a lot of experience, but not with that one.

Jason: Right. If there’s no need to change the address space, why have that option available to the user?

Tom: Now, when people talk about address space, I think connector. In the context of our discussion today, I’m thinking SMTP connector. I think I mentioned earlier that the reasons for having an SMTP connector are not the same as they were in Exchange 5.5. The reason for having an SMTP connector in Exchange 2000 include that you want to have a bridgehead. If you have multiple Exchange 2000 servers and you want only one of them to send mail out to the Internet, send and receive, that’s one reason to have an SMTP connector. Another reason to have an SMTP connector, if you only have one Exchange server, is if you want to configure a certain route, a very specific domain, to behave a certain way — all mail to example.com, disable the EHLO functionality, for example, or disable certain other functionality — you can do that with a connector and that can’t be done with an SMTP virtual server. There’s a KB article that talks about when to use an SMTP connector and when not to use an SMTP connector in Exchange 2000. I’d highly recommend searching that one out.

Jason: The next question is probably going to be the last one we manage to get to before the end of the WebCast, but this is a follow-up, and I did want to get to it. The original question was concerning messages to MTA and the message client goes from the client to the message store first and to the transfer core. The follow-up question is: If that is the case, and I’m not sure what you answered there, then you can only scan for viruses with a AVAPI anti-virus client?

Tom: That’s not true. There are two different types of anti-virus scanning software. One type is the type that hooks into the information store, and it scans every message that goes into the information store. That uses the AVAPI that’s being referred to. The second type of anti-virus software is what I’m going to call an anti-virus gateway. The anti-virus gateway rides on top of the IIS admin service. It hooks into the PreSubmissionQueue or the PostSubmissionQueue that I was referring to earlier, the pre-cat or the post-cat, and does its scanning at that point. So most anti-virus gateways connect to the pre-cat queue, and before the message is even passed into our categorizer, it goes through virus scanning. Then, the virus scanning software turns the message back over to categorizer, it does its thing, and then goes back into the advanced queuing, the way we’ve talked about before. So look at the pre-cat object as kind of a way for third-party vendors to hook in their software to do something.

If you go to MSDN, there are examples of how you can create certain types of transport event sinks. For example, with a transport event sink, you can write one that will tack on a specific disclaimer at the end of every single e-mail message that goes out of your company. That would be something where you would, on PostCategorizer, probably use the SMTP event. I hope that answers that question.

Jason: That is all the time that we have for today’s WebCast. I want to thank everybody for joining us. What we’ll do on the rest of the questions, I’m going to see if Tom can take a look at them, and see if we can get those answered offline. I do apologize, but we just had a limited amount of time in which we could take questions today. I want to thank everybody for coming and asking good questions.

Again, we’re very interested in your feedback regarding the WebCast program. Just send it to feedback@microsoft.com. Be sure to include "Support WebCast" in the subject line.

We hope you join us again in the near future. Thank you, and good-bye.

{Questions from after the session was closed:

Question: Can you point me to detailed information on how to set up Exchange 2000 in a dial-on-demand environment?

Tom: Dial-on-demand is a feature of Routing and Remote Access Server (RRAS), which is installed by default but disabled in every installation of Windows 2000 Server or Windows 2000 Advanced Server. There is no Exchange 2000 documentation describing how to set up demand-dial routing, but there are many resources for configuring it in Windows 2000, including the Windows 2000 online documentation, Windows 2000 Resource Kits, and books online (http://www.microsoft.com/windows2000/techinfo/reskit/default.asp), and many, many KB articles, white papers, and FAQs. If you need assistance planning and configuring your demand-dial routing tables, I would recommend opening an Advisory Services cases with our IP/RAS team in Enterprise Platforms Support (EPS).

Question: Slide 30 mentions the RUS possibly not stamping objects with correct attributes. Could you kindly repeat the scenarios that this may happen?

Tom: I entered the following string in our online knowledge base (http://support.microsoft.com/) and received 20+ hits, nearly all of which were relevant: "exchange 2000" and ("recipient update service" or rus) and (undeliverable or ndr).

Question: What are the best tools you recommend for updating Exchange 5.5 to Exchange 2000 on the same server?

Tom: Fdisk, Format, and Setup.exe. But in lieu of those tools, I would definitely use Ntbackup.exe before starting the migration. This question is way beyond the scope of this WebCast, and there are many resources for helping you plan, test, and execute an in-place upgrade. My brief recommendations are that you prepare for the worst (full backups, system state, file level, et cetera), practice the upgrade with real data in a lab environment that closely matches your production environment, and then perform the upgrade during a time that will least impact your users if something goes wrong.

Question: How do you force mail sitting in the SMTP queues to resend? is there a certain sequence I must go through with the queues? Can you also explain the "Enumerates message from the queue node" statement?

Tom: As mentioned in the WebCast, each queue represents a unique destination. Therefore, selecting Force Connection forces the SMTP service to immediately retry the connection. This will change the State for that connection from Retry to Active. There is no special sequence that I know of, unless you want to freeze all messages and then unfreeze a few at a time. As for Enumerate messages from the queue node, that is merely a message telling you that the queue view needs to be refreshed by clicking on the queue node in the left pane, and selecting Enumerate…

Question: While troubleshooting issues with message routing, I have found it difficult to find documentation on all of the Performance Monitor items for SMTP. Do you have any suggestions on were I could find complete documentation?

Tom: The only documentation that exists for performance counters is that which is available in the System Monitor or Performance Monitor itself, when you click on Explain for a given counter.

Question: I have one Exchange 5.5 server being shared by two different companies. The companies are about to split, with one company staying with the Exchange 5.5 server (can't update yet, because of budget reasons) and the second company purchasing a new Exchange 2000 server. Is it possible to migrate mailboxes from the Exchange 5.5 server to an Exchange 2000 server without destroying the Exchange 5.5 server?

Tom: This sounds like an MCP exam question! Yes, there's a way, but not it's as straightforward as you might hope. Probably the best, easiest, and safest way to accomplish this is to use Exmerge, which is a powerful utility we have for performing operations exactly like this. You can get Exmerge right off the CD (in the Support\Utils\i386 folder), but I've just been told that the very best and most up-to-date version of Exmerge can be found in Exchange 2000 Server Service Pack 2.

Question: Does the SRS in a mixed site play any function in message routing or categorization?

Tom: Only to the extent that the SRS plays a critical role in replicating configuration data from one system to the other. And because directory replication does turn out to be the root of a lot of message flow problems in mixed-mode organizations, I would say that SRS does play a big role in reliable message flow. However, SRS plays no direct role whatsoever in routing or categorization of messages. While I haven't tested this, it should be possible to shut down the SRS and send a message from one system to the other successfully, assuming that both directories were up-to-date.

Question: Will the fact that Exchange only queries for a global catalog once, and then caches it, be changed in some way in the future, as far as DSAccess is concerned?

Tom: In Exchange 2000 Server Service Pack 2, a new feature was added that allows administrators to manually configure the global catalogs, domain controllers, and Config DCs that a particular Exchange 2000 Server will look to. If you've installed Service Pack 2, you'll find that feature on the Directory Access tab of the server properties. Keep in mind that the ability to manually configure the domain controllers that will be used a) is a band-aid to a deeper problem of poor Active Directory site design and/or network problems and b) may cause other unexpected problems. According to my best sources, DSAccess does a very good job of selecting the correct domain controllers most of the time, and unless you have a specific need, you should manually configure the domain controllers that an Exchange 2000 Server will look to.}