For the most part, these features involve interacting with legacy email systems. Even so, it is important to know what features no longer exist so you can plan an eventual Exchange Server 2007 deployment without any nasty surprises.

Deemphasized features in Exchange 2007

In Exchange Server 2007, many carryover features from Exchange 2003 have been -- in Microsoft's words -- deemphasized. While these features are fully supported in Exchange Server 2007, Microsoft is trying to discourage the use of them.

As you have probably guessed, Exchange Server public folders are at the top of the list of deemphasized features in Exchange 2007. Exchange public folders are still fully supported in Exchange 2007, but it is still unclear whether or not they -- or any of the deemphasized features -- will be included in the next version of Exchange Server (currently dubbed "Exchange 13).

Below is a full list of deemphasized features. They will all be supported until at least 2016, according to Microsoft support life-cycle policies.

• Public folders
• CDOEx
• WebDAV
• ExOLEDB
• Store events
• Streaming backups

In many cases, features are being deemphasized because better technology already exists. For example, snap shot backups are far superior to streaming backups, because they are less disruptive.

Discontinued features in Exchange 2007

Probably the most significant discontinued feature in Exchange Server 2007 is the ability to co-exist with Exchange Server 5.5. You cannot deploy Exchange Server 2007 into an Exchange organization containing Exchange 5.5 servers.

The complete list of discontinued features is as follows:

• Access to public folders via Outlook Web Aceess. IMAP or NNTP
• Active-active clustering  
• Administrative Groups
• CDO 1.2
• CDO for Workflow
• CDOEXM
• Coexistence with Exchange 5.5
• Connector and migration tools for GroupWise
• Exchange 5.5 Event Service
• Exchange Web forms
• Exchange WMI classes
• Installable File System (also known as IFS or M: )
• Outlook Mobile Access
• Outlook Web Access support for rule creation and editing
• Routing Groups
• Transport event sinks
• Workflow Designer
• X.400

In addition to the above list, Outlook Web Access will not initially support S/MIME. Rumor has it though that S/MIME support will be eventually restored when the first Exchange Server 2007 Service Pack is released.

Many of these Exchange Server features were cut because they were obsolete, unused, or redundant. Other features were removed in Exchange 2007, because they have been replaced by something better.

Some examples of obsolete features that have been discontinued include support for Exchange 5.5 and the connectors and migration tools for GroupWise. Granted, there are still organizations that use Exchange 5.5 and GroupWise, but the majority of Microsoft's customers have apparently moved on.

Outlook Mobile Access

There are enough organizations using Exchange Server that I'm sure that no feature is completely unused. But according to a friend at Microsoft, the Outlook Mobile Access feature has been discontinued in Exchange Server 2007 because few customers were using it. If you want to move to Exchange 2007, but your organization currently relies on OMA, you might want to look into using Exchange direct push technology as an alternative.

Administrative groups and routing groups

Many people I've talked to about Exchange Server 2007 have been a bit surprised that Microsoft would do away with administrative groups and routing groups. The move really makes sense though if you stop and think about it.

Routing groups are a redundant structure. Exchange Server is Active Directory-based, and Active Directory already knows about your network's topology because of site objects. There is no reason to have to duplicate this configuration information in Exchange when the server can just get its routing information from Active Directory.

Administrative groups were not a redundant or obsolete feature, but they have been removed from Exchange Server 2007 nonetheless. Administrative groups can be tricky to manage in larger deployments. Microsoft has designed Exchange Server 2007 in a way that will provide administrators with better administrative control through other mechanisms, such as the Exchange Management Console or the Exchange Management Shell. 

It's usually pretty easy to tell if your spam filter is too aggressive or if an Exchange server is configured to filter out certain types of email messages. On the other hand, if the problem is related to the SMTP virtual server configuration on an Exchange server within your organization, the problem is a lot more difficult to diagnose and treat.

Part 1: How to locate an email message in the SMTP queues

Before you can use a message's location to troubleshoot the Exchange server, you must locate the email message. The message can be located in any one of a server's many different SMTP queues.

To hunt for a message, go to Exchange System Manager -> Administrative Groups -> your administrative group -> Servers -> the problematic server -> Queues. When you select the Queues container, Exchange System Manager will display all of the server's SMTP queues in the console's details pane.

Figure A: The Queues container displays all of the selected server's SMTP queues.
(Click image for enlarged view.)

When you select the Queues container, you'll initially receive some summary information that will tell you how many email messages are in each queue, the cumulative size of all of the messages within the queue, and the date and time that the oldest message was placed into the queue.

The summary information by itself can be valuable because it can give you hints as to which SMTP queues might be having problems. For example, if you see an extremely large queue or a queue that has held email for a long time, Exchange Server may be having problems processing the messages in that queue.

In Figure A above, notice that there is only one message queued on my lab server. Obviously, an active production server will have many messages in various SMTP queues at any given time, even if the Exchange server is healthy.

This brings me to my next point. If you have a particular user complaining that email is not being received or that messages that are not being delivered, then the first thing you need to do is to figure out where the email is going.

Determining where the messages are located is simple if your server happens to be like mine and only has one message queued. But if you have dozens of messages flowing through the SMTP queues at any given time, you will have to do a little detective work to find the missing email.

The easiest way of locating these email messages is to click the Find Messages button shown in Figure A. When you do, you will see a dialog box similar to the one that's shown in Figure B.

Figure B: The Find Messages dialog box allows you to search the SMTP queues for specific messages.
(Click image for enlarged view.)

At first glance, the dialog box shown in Figure B is deceptively simple. It appears as though you can specify the sender and/or the recipient and click the Find Now button to locate the email message. While you can do this, tracking down a specific message is a little trickier than that.

In Figure B, you will notice that the title bar reads Find Messages – DSN messages pending submission. "DSN Messages pending submission" is the name of one of the SMTP queues. It's important to note that the Find Messages screen does not perform a global search; it searches each queue individually.

You might assume that you just search each SMTP queue until you find the specified message. In reality, when you search an SMTP queue and receive a result, it doesn't necessarily mean that you have found the problematic email message.

For example, imagine that a user named Fred is trying to send an email message to another user named Sue, but the message isn't being delivered for some reason. You could begin your search by looking for messages from Fred to Sue. The problem is that Fred sends email to Sue all the time. In such a case, the best approach is to check each SMTP queue and make a note of the email message's date/time and subject line. You can then get Fred to identify the exact problematic email message.

Yes, locating a specific email message within the SMTP queues can be tedious, but it is the first step in the mail-flow troubleshooting process.

Part 2: Troubleshooting the DSN Message Pending Submission queue

Exchange Server uses the DSN Message Pending Submission queue for non-delivery reports (NDRs). When Exchange Server needs to send an NDR to someone, the NDR message is placed into this SMTP queue prior to being transmitted.

Since this SMTP queue is reserved for NDR messages, you should never have an email from one user to another show up in this queue. That doesn't mean that this queue never malfunctions though. Quite often the DSN Message Pending Submission queue will clog up because NDR messages are not being transmitted.

The fact that the DSN Message Pending Submission queue fails to process messages is not the problem -- it is merely a symptom of another issue. When the DSN Message Pending Submission queue fails, it is almost always related to the message store or to the IMAIL Exchange Server store component. (IMAIL is responsible for message conversions.)

If your Exchange server's DSN Message Pending Submission queue is malfunctioning, make sure that all of the Exchange Server stores are mounted. If the stores appear to be OK, check the event logs for any store or IMAIL-related errors.

Part 3: Troubleshooting the Failed Message Retry queue

Occasionally you'll receive an email in your Inbox indicating that there has been a delay in sending a message, but that there is no need to resend the email message. This means that a message delivery failure has occurred, but this doesn't necessarily mean that there is a problem on your Exchange server.

Let's say you want to send an email to someone at another company. You send the message, but you have no idea that the other company's mail server is down. Because the server isn't working on the receiving end, your Exchange server is unable to deliver the message.

Exchange Server responds to this situation by placing the undelivered email message into the Failed Message Retry queue. Exchange then attempts to resend the message at various intervals until the message's timeout period expires.

After the email has been in this SMTP queue for a few hours, Exchange will send you a delayed delivery notification message. There is no need to resend the email message. You will only receive a message delivery failure if the message expires without being delivered.

What can cause the Failed Message Retry queue to malfunction?

It is normal to have a message sit in the Failed Message Retry queue for hours on end, but that does not necessarily mean that the queue is malfunctioning. If, however, email stays in this SMTP queue for more than two days (the default timeout period) or if an exceptionally large number of messages are deposited into the queue, this means the queue is malfunctioning.

If messages stay in the queue for more than two days, you should first check to make sure that the Exchange server isn't set to use an excessively long timeout period.

Here are the instructions to check the timeout period for messages in Exchange Server:

1. Go to Exchange System Manager -> Administrative Groups -> your administrative group -> Servers -> your server -> Protocols -> SMTP -> Default SMTP Virtual Server.

2. Right click on the Default SMTP Virtual Server -> Properties -> Delivery tab.

3. The Delivery tab controls how often Exchange Server attempts to resend messages (i.e., the timeout period).

If a message that should have timed out is still in the queue, then the email could be corrupt. Occasionally, a corrupt message may be placed into an SMTP queue. If this happens, it can hold up everything else in the queue.

To determine if a message is corrupt, look at its properties. If there are properties that are blank or that contain gibberish, it's a pretty good indication that the message is corrupt. Simply delete the corrupted message and the queue should start flowing again.

Another sign of trouble is when excessive messages pile up in the Failed Message Retry queue. This usually indicates an external problem, such as link failures (router failure, unplugged cable, bad NIC, etc.) or DNS resolution failures. In this case, make sure that the Exchange server can communicate with the rest of the network and the Internet, and that it is able to perform DNS resolutions successfully.

Part 4: Troubleshooting the Local Delivery queue

The Local Delivery queue is used as a repository for messages that are going to be delivered to local Exchange mailboxes. You don't have to worry too much about this SMTP queue malfunctioning. If email becomes stuck in the queue, it is almost always because the Exchange server cannot accept new messages.

Conditions that would prevent an Exchange server from being able to accept email messages include:

• Dismounted Exchange database
• Denial-of-service attack

More often, messages tend to get backed up in the Local Delivery queue rather than actually getting stuck there. When this SMTP queue does become backed up, it means that the Exchange server is not performing sufficiently to keep up with the current workload.

This type of performance issue is usually related to the disk subsystem. The queue becomes backed up because the disk subsystem is not able to move email from the queue to the transaction logs as quickly as messages are coming into the queue.

Part 5: Troubleshooting the Messages Awaiting Directory Lookup queue

The Messages Awaiting Directory Lookup queue is a holding facility for email sent to recipients who have not yet been resolved against Active Directory. Likewise, if a message is sent to a distribution list, it is placed into this SMTP queue while Exchange Server determines the list's membership and resolves each recipient's address to a mail-enabled Active Directory user account.

If messages accumulate in this queue it's because the SMTP categorizer component of Exchange Server's Advanced Queuing Engine is unable to determine how to route inbound messages across your Exchange organization. This occurs when Exchange Server has trouble communicating with a global catalog server. The global catalog server may be inaccessible or can't keep up with the demands of the Exchange server and the rest of the machines in the forest (even workstations communicate with a global catalog server when users log on).

There are a couple of things that you can do to correct this:

• If the global catalog server has dropped offline or if there is a link failure between the Exchange server and the global catalog server, you need to restore communications between the two servers in order to fix the problem.

• If the global catalog server is having trouble keeping up with the demands of the Exchange organization, you can designate another domain controller to act as a global catalog server. Windows only designates one domain controller to act as a global catalog server by default, but it is a good idea to have multiple domain controllers configured to act as global catalog servers -- both for fault tolerance and load balancing.

In some rare cases, problems with the SMTP categorizer might not be related to a global catalog server issue. If everything seems to be OK with your global catalog server, I recommend increasing the diagnostic logging level for the SMTP categorizer to help determine the cause of the issue.

Part 6: Troubleshooting the Messages Waiting To Be Routed queue

The Messages Waiting To Be Routed queue stores email until the message's next stop in route to its final destination can be determined. If email gets hung up in this SMTP queue, it is always related to a routing. Unfortunately, this one's tough to troubleshoot. The issue could be related to a link failure, a corrupted routing table, or a million other things.

Try to do tracert to the message's destination domain. This will help you to determine whether or not the Exchange server is able to communicate with and route packets to the destination domain.

If the tracert fails, try pinging a few other external domains. This way you can tell if the problem is specific to the destination domain or if the server is having trouble communicating with all external domains. If you are unable to ping any external domains (and firewalls are not blocking ICMP traffic), then the routing issue is occurring at either the hardware level or at the TCP/IP level.

On the other hand, if you are able to ping the destination domain and run a successful tracert, then physical connectivity exists and TCP/IP is working. Therefore, the issue is Exchange-related. In that case, I recommend increasing the Exchange server's diagnostic logging level for routing to help you to determine the cause of the problem.

Part 7: Troubleshooting the Final Destination Currently Unreachable queue

As its name implies, the Final Destination Currently Unreachable queue is used to store SMTP email messages that can not be routed to their final destination. If messages begin to appear in this SMTP queue, then obviously Exchange is having trouble routing that email to the destination domain.

First, you should check to see if all or most outbound SMTP email is ending up in this queue, or if only select messages are being placed in the queue.

If all or most of the email is being placed into the Final Destination Currently Unreachable queue, Exchange is likely having trouble communicating with external domains. This could be because of a broken or disconnected network cable, a malfunctioning router, or because your DNS server is having trouble resolving the recipient's domain names.

If only messages destined for select domains are being placed into the Final Destination Currently Unreachable queue, the problem could be DNS-related -- i.e., the DNS server might not be able to resolve that particular domain name. Another possible cause is that your router might have a corrupt routing table.

One thing to note: Fixing the SMTP queue issue may not restore mail flow. For example, if messages were accumulating in the Final Destination Currently Unreachable queue because of a broken network link and you fixed the broken link, Exchange Server will often continue to hold the messages in the queue even though the link is fixed.

To restore mail flow, Microsoft recommends restarting the SMTP virtual server that the queue services.

Part 8: Troubleshooting the Messages Pending Submission queue

Exchange Server uses the Messages Pending Submission queue to store outbound SMTP email messages that the server has not yet begun to process. For example, if a user were to send an SMTP message to an external recipient, Exchange Server would route the email through the various SMTP queues I've discussed as it resolves the recipient's IP address and transmits the message. When the Exchange server is too busy to begin processing messages, all outbound SMTP email is placed into the Messages Pending Submission queue until it can be processed.

SMTP messages normally pass through the Messages Pending Submission queue quickly. During busier parts of the day, you might see messages briefly accumulate in the queue if users are sending SMTP email faster than the Exchange server can handle it. However, individual messages should not remain in the queue for any prolonged period of time.

If messages are held in the queue for excessive lengths of time, it usually indicates an Exchange Server performance problem. Exchange's CPU may not be able to keep up with the demand being placed on the server. Likewise, the server may have insufficient memory or the server's hard disks may be too slow. The only way to really tell for sure is to use the Preformance Monitor to test for bottlenecks on the Exchange server.

Hardware performance problems are not the only possible cause of messages accumulating in the Messages Pending Submission queue. Another reason is custom or third-party event sinks.

Part 9: Troubleshooting Remote Destination queues

Occasionally, you might see a queue bearing the name of a connector, followed by the name of a server and the name of a remote domain. These SMTP queues are created dynamically for the purpose of delivering email messages to a remote domain.

If you have such queues and they have messages accumulated within them, check the status of the SMTP queue to see if it is in Retry mode or if it's just slow. If the queue is in Retry mode, check the queue's properties for more information as to why it is in the retry state. Typically, the problem will either be DNS- or link-related.

To troubleshoot the problem, manually communicate with the remote domain by using tools such as tracert, ping and telnet.

Microsoft originally introduced the concept of server roles in Exchange 2000 when it first allowed for separate Exchange front-end servers and back-end servers. In Exchange Server 2007, and in many of the other new Microsoft products coming out, server roles are much more prominent and specific though.

The benefits of Exchange 2007 server roles

Server roles simplify deployment. During the Exchange Server 2007 installation process, you're asked which roles should be assigned to the server. When you choose a server role, Exchange 2007 Setup will install everything that is necessary for the Exchange server to fulfill that role. That means you don't have to go back later and manually install a bunch of subcomponents.

Being able to pick and choose Exchange server roles also ensures that no unnecessary Exchange Server components are running on your server. Eliminating needless components typically improves Exchange Server's performance and security.

There is a law of computing that states that the larger the code base running on a machine, the greater the chance that it contains exploitable security vulnerabilities. Assigning only the necessary server roles prevents any unnecessary code from being installed on the Exchange Server, thus keeping the size of the code base to a minimum.

Another advantage to role-based architecture is that it allows your Microsoft Exchange Server organization to be modular. Small companies can assign roles in a way that allows a single Exchange Server to perform all of the necessary tasks to meet the company's Exchange Server needs. Larger organizations can distribute roles across multiple servers to avoid overburdening any individual server.

There are five pre-configured server roles in Exchange Server 2007:

The Client Access Server role

The Exchange 2007 Client Access Server role is similar to the front-end server role found in Exchange 2000 Server and Exchange Server 2003. Its job is to provide the Outlook Web Access interface and to act as a proxy between Web-based clients and back-end Exchange servers.

The Mailbox Server sole

The Exchange 2007 Mailbox Server role is fairly self-explanatory. Exchange servers running the Mailbox Server role host the databases used to store Exchange Server mailboxes. Just as in Exchange Server 2003, these databases can be clustered if necessary.

The Hub Transport Server role

The Exchange 2007 Hub Transport Server role has two responsibilities. First, it controls message routing. This is true whether an email is being routed between two mailboxes on the same Exchange server, or between multiple Exchange servers.

The Hub Transport Server role's second job is to enforce messaging policies for email being sent between recipients inside and outside the Microsoft Exchange Server organization.

The Unified Messaging Server role

Unified messaging is completely new to Exchange Server 2007. The basic idea behind the Unified Messaging Server role is that it allows Exchange Server to interface with compatible PBX systems. This allows voicemail and fax messages to be deposited into and accessed from Exchange Server mailboxes.

The Unified Messaging Server role also provides a component called Outlook Voice Access (OVA). OVA lets users access their mailboxes using a telephone. Using OVA, it is possible for users to telephonically "read" and compose email messages, and to manage their calendars.

The Edge Transport Server role

The Edge Transport Server role is the one exception to this. The reason is that servers running the Edge Transport Server role are intended to be placed in your organization's DMZ. The Edge Transport Server's job is to filter spam and viruses from inbound messages before they reach your perimeter network.