Collection: Exchange 2007 Mail Transport Query(1)

Troubleshooting Mail Flow from Exchange Server 2007 to Exchange 2000 or Exchange 2003 in the Same Organization

This topic provides information about how to troubleshoot Microsoft Exchange Server 2007 mail flow issues between Exchange 2007 and Exchange Server 2003 and Exchange 2000 Server. After you install Exchange 2007 into your Exchange 2003 or Exchange 2000 organization, you may notice that there is no mail flow from Exchange 2007 to Exchange 2003 or Exchange 2000. However, you can send e-mail messages from Exchange 2003 or Exchange 2000 to Exchange 2007. The queue is in retry mode with the following error information:

"451 4.4.0 Primary IP address responded with: 535 5.7.3 anonymous authentication not allowed."

This issue occurs when the fully qualified domain name (FQDN) setting on the Exchange 2003 or Exchange 2000 server's Simple Mail Transfer Protocol (SMTP) virtual server does not match the internal FQDN of the server.

 Resolution

To resolve the problem, change the FQDN to the correct name.

 Before You Begin

To perform this procedure, the account you use must be delegated the following:

• Membership in the local Administrators group

Active Directory Service Interfaces (ADSI) Edit can be run from a client computer or server. The computer does not have to be a member of a domain, but the user must have the rights to view and edit the Active Directory directory service domain to which the user is connecting.

Important:

If you use ADSI Edit or any other Lightweight Directory Access Protocol (LDAP) version 3 client, and you incorrectly modify the attributes of Active Directory objects, serious problems may occur. These problems may require you to reinstall Windows Server 2003, Exchange 2007, or both Windows Server 2003 and Exchange 2007. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

 Procedure

 To use ADSI Edit to change the FQDN to the correct name

1. Install ADSI Edit.
2. Launch ADSI Edit. Click Start, click Run, type adsiedit.msc in the text box, and then click OK.
3. Locate the servicePrincipalName attribute for the Exchange 2003 or Exchange 2000 server by going to this location: CN=Computers under Domain Configuration.
4. Right-click the Exchange 2003 or Exchange 2000 server, and then click Properties.
5. Select the servicePrincipalName attribute for this Exchange 2003 or Exchange 2000 server.
6. Determine the value in the format of SMTPSVC/FQDN and make sure the FQDN is correct. If the FQDN is incorrect, change it to the correct FQDN.
7. In Exchange System Manager on the Exchange 2003 or Exchange 2000 server, click the SMTP virtual server that you want to configure.
8. On the Action menu, click Properties.
9. Click the Delivery tab, and then click Advanced.
10. In the Advanced Delivery dialog box, type the same FQDN as the one you identified in the servicePrincipalName attribute.
11. Click OK to close the virtual server properties.
12. Stop, and then restart the SMTP service.
13. Click OK, and then close ADSI Edit.

Troubleshooting Mail Flow from Exchange 2007 to Exchange 2003 When E-Mail Messages are Stuck in the Queue

This topic discusses how to troubleshoot mail flow issues between Microsoft Exchange Server 2007 and Exchange Server 2003 and between Exchange 2007 and Exchange 2000 Server. After you install Exchange 2007 in your Exchange 2003 or Exchange 2000 organization, you may observe the following issues:

• Mail does not flow from Exchange 2007 to Exchange 2003 or Exchange 2000. However, e-mail messages can be sent from Exchange 2003 or Exchange 2000 to Exchange 2007.
• When you check the queue viewer in Exchange 2007, e-mail messages are stuck in the Unreachable domain queue on the Exchange 2007 side.
• When you double-click an e-mail message to view the properties, you receive the following error message: "There is currently no route to the mailbox database."
• Outlook clients can log in, but they cannot send or receive mail. Outbound messages remain in the Outbox.
• Messages are queued in the MapiDelivery queue on an Exchange 2007 Hub server. The queue is in a Ready state but there are messages stuck in the queue. Additionally, the message status shows the following error:
  "430 4.2.0 STOREDRV; mailbox logon failure."
• Messages that are sent from an Exchange 2007 mailbox are routed to the Unreachable destination queue on an Exchange 2007 Hub server. Additionally, the message status shows the following error:
  "The mailbox recipient does not have a mailbox database."
• You cannot authenticate your credentials with the SMTP Service by using BASIC (AUTH LOGIN) or SPA (AUTH GSSAPI)

These issues may occur if one or more of the following conditions are true:

• Inheritable permissions have been removed from either the Exchange 2003 or Exchange 2000 server object or from the Exchange 2003 or Exchange 2000 mailbox store object.
• The Exchange Servers group does not have appropriate permissions on the Exchange 2003 or Exchange 2000 server object or on the Exchange 2003 or Exchange 2000 mailbox store object.
• The Folder Hierarchies container is missing under the administrative group in Exchange 2007. In this scenario, the HomeMDB value is missing for public folders.
• The Exchange Servers group is missing permissions on the Exchange server object in Active Directory. Specifically, the explicit Allow permission has been removed from or the Deny permission is inherited for the following rights on the Exchange server object:
• Store Constrained Delegation
• Store Read and Write Access
• Store Read only Access
• Store Transport Access
• On the server that hosts the mailbox of the sender, the following event is recorded in the Application log in Event Viewer:

Event ID : 1009

Category : MSExchangeMail

SubmissionSource : MSExchangeMailSubmission

Type : Warning

Machine : Server_Name

Message : The Microsoft Exchange Mail Submission service is currently unable to contact any Hub Transport servers in the local Active Directory site. The servers may be too busy to accept new connections at this time.

• When you use the Microsoft Exchange Troubleshooting Assistant on the Mailbox server to complete a trace using the Store Driver tag and the Transport tag, you receive several error messages. The error messages explain that the Store Driver code in the Transport service cannot log on to the Exchange store by using MAPI. Therefore, the Store Driver cannot pick up the Mail item to put it in the Submission queue. For example, you may see an error message that resembles the following:

StoreDriver, MailSubmissionService, PFD EMS 22427 SubmitMail for mailbox 1d53da12-6722-4986-bc19-da72890329ed at entry 536769 StoreDriver, MapiSubmit, PFD ESD 27547 Processing Rpc SubmitMessage for event Event 536769, mailbox 1d53da12-6722-4986-bc19-da72890329ed, mdb 13d716e1-9ccd-4f44-a47f-993adbf2f7b5 StoreDriver, MapiSubmit, PFD ESD 23451 Submitting event Event 536769, mailbox 1d53da12-6722-4986-bc19-da72890329ed, mdb 13d716e1-9ccd-4f44-a47f-993adbf2f7b5 StoreDriver, MapiSubmit, PFD ESD 17307 Opening mailbox 1d53da12-6722-4986-bc19-da72890329ed on 13d716e1-9ccd-4f44-a47f-993adbf2f7b5,server.contoso.com 000002E6, 2C0067006E0069, StoreDriver, ExceptionHandling, Exception occurred during message Submit : Microsoft.Mapi.MapiExceptionLogonFailed: MapiExceptionLogonFailed: Unable to make connection to the server. (hr=0x80040111, ec=1010)Diagnostic context: ...... Lid: 8600 dwParam: 0x6BA Msg: EEInfo: ProcessID: 4956 Lid: 12696 dwParam: 0x6BA Msg: EEInfo: Generation Time: 2007-02-08 10:32:23:406 Lid: 10648 dwParam: 0x6BA Msg: EEInfo: Generating component: 2 Lid: 14744 dwParam: 0x6BA Msg: EEInfo: Status: 1722 Lid: 9624 dwParam: 0x6BA Msg: EEInfo: Detection location: 390 Lid: 13720 dwParam: 0x6BA Msg: EEInfo: Flags: 0 Lid: 11672 dwParam: 0x6BA Msg: EEInfo: NumberOfParameters: 2 Lid: 8856 dwParam: 0x6BA Msg: EEInfo: prm[0]: Unicode string: server.contoso.com Lid: 8856 dwParam: 0x6BA Msg: EEInfo: prm[1]: Unicode string: MAIL2 Lid: 23065 EcDoConnectEx called [length=188] Lid: 17913 EcDoConnectEx returned [ec=0x3F2][length=56][latency=0] Lid: 23065 EcDoConnectEx called [length=188] Lid: 17913 EcDoConnectEx returned [ec=0x3F2][length=56][latency=0] Lid: 19778 Lid: 27970 StoreEc: 0x3F2 Lid: 17730 Lid: 25922 StoreEc: 0x3F2 at Microsoft.Mapi.MapiExceptionHelper.ThrowIfError(String message, Int32 hresult, Int32 ec, DiagnosticContext diagCtx) at Microsoft.Mapi.ExRpcConnection.Create(ConnectionCache connectionCache, ExRpcConnectionCreateFlag createFlags, ConnectFlag connectFlags, String serverDn, String userDn, String user, String domain, String password, String httpProxyServerName, Int32 ulConMod, Int32 lcidString, Int32 lcidSort, Int32 cpid, Int32 cReconnectIntervalInMins, Int32 cbRpcBufferSize, Int32 cbAuxBufferSize) at Microsoft.Mapi.ConnectionCache.OpenMapiStore(String mailboxDn, Guid mailboxGuid, Guid mdbGuid, ClientIdentityInfo clientIdentity, String userDnAs, OpenStoreFlag openStoreFlags, CultureInfo cultureInfo, String applicationId) at Microsoft.Mapi.ConnectionCache.OpenMailbox(String mailboxDn, Guid mailboxGuid, Guid mdbGuid, WindowsIdentity windowsIdentityAs, String userDnAs, OpenStoreFlag openStoreFlags, CultureInfo cultureInfo, String applicationId) at Microsoft.Exchange.Data.Storage.ConnectionCachePool.OpenMailbox(String serverDn, String userDn, String mailboxDn, Guid mailboxGuid, Guid mdbGuid, Object identity, ConnectFlag connectFlag, OpenStoreFlag openStoreFlag, CultureInfo cultureInfo, String clientInfoString, Boolean secondTry)

 Resolution

To resolve this issue, use one of the following methods:

• Add inheritable permissions to the appropriate mailbox store object, and make sure that the Exchange 2000 Servers group has the appropriate permissions.
• Use Active Directory Service Interfaces (ADSI) Edit to create the Folder hierarchies container under the administrative group in Exchange Server 2007.
• Grant the explicit Allow permission to the Exchange Servers permissions group on the Exchange server object in Active Directory.

   Procedure

 To add inheritable permissions to the mailbox store object

1. On the Exchange 2007 server on which the messages are queuing, obtain the latest routingconfig@<time_stamp>.xml file.
2. Open the file using Notepad, and search for the HomeMdbRouting section.
3. Verify that there is a listing for the message recipient's mailbox store. Find the appropriate Exchange 2003 server(s).
4. In the Exchange 2003 Exchange System Manager, locate the properties of the Exchange 2003 server object, open the Security tab, and then make sure the Exchange Servers group has the following permissions:
• Read
• Access Recipient Update Service
• Administrator information store
• Create name properties in the information store
• Exchange Web Services Impersonation
• Exchange Web Services Token Serialization
• Modify public folder replica list
• Open mail send queue
• Read metabase properties
• Send As
• View Information Store status
5. Click Advance, and then select the Allow inheritable permissions check box.
6. Repeat steps 4 through 5 for each mailbox store object under this Exchange 2003 server.
7. Restart the Microsoft Exchange Transport service on the Exchange 2007 server to update routing tables.

 To use ADSI Edit to create the Folder hierarchies container

1. Start ADSI Edit.
2. Expand the following container:

Configuration [<Your_Domain_Name>]/CN=Configuration, DC=<Your_Domain_Controller> ,DC=com/CN=Services/CN=Microsoft Exchange/CN=<Your_Organization_Name>,CN=Administrative Groups

3. Right-click CN=<Your_Administrative_Group_Name>, point to New, and then click Object.
4. Click msExchPublicFolderTreeContainer in the Select a class list, and then click Next.
5. In the Value box, type Folder Hierarchies, and then click Next.
6. Click Finish.
7. Determine whether the msExchPFOwningPFTree attribute on the public folder store is associated with a public folder tree. To do this follow these steps:
1. In ADSI Edit, expand the following container:
   Configuration [<Your_Domain_Name>]/CN=Configuration, DC=<Your_Domain_Controller>,DC=com/CN=Services/CN=Microsoft Exchange/CN=<Your_Organization_Name>/CN=Administrative Groups/CN=<Your_Administrative_Group_Name>/CN=Servers/CN=<Your_Server_Name>/CN=Information Store/CN=<Your_StorageGroup_Name>.
2. In the right-pane, right-click CN=Public folder store, and then click Properties.
3. In the Attributes list, locate the msExchOwningPFTree attribute. The value provides the location of the public folder tree. If the attribute does not have a value, or the value is incorrect, go to step 8.
4. Expand the container that is identified in the msExchOwningPFTree attribute value.
5. Right-click CN=Public folders, and then click Move.
6. In the Container to move object to dialog box, click Folder hierarchies, and then click OK.
8. If the public folder store is not associated with a public folder tree, create a new tree. To do this, follow these steps:
1. Right-click CN=Folder Hierarchies, point to New, and then click Object.
2. In the Select a class list, click msExchPFTree, and then click Next.
3. In the Value box, type Public Folders, and then click Next.
4. Click More Attributes.
5. In the Select a property to view list, click msExchPFTreeType, type 1 in the Edit Attribute box, and then click Set.

Important:

The value must be set to 1 to so that Exchange identifies this as a MAPI Tree.

6. Click OK, and then click Finish.
8. Populate the msExchOwningPFTreeBL attribute object of the public folder stores in the organization. To do this, follow these steps:

6. In ADSI Edit, right-click the public folder tree that you created, and then click Properties.
7. In the Attributes list, click distinguishedName, and then click View.
8. Copy the value in the Value box to the clipboard, and then click Cancel two times.
9. Expand the Storage group container that contains the public folder store for the server, right-click the server and then click Properties.
10. In the Attributes list, click msExchOwningPFTree, and then click Edit.
11. Click Clear, paste the value that you copied to the clipboard in the Value box, and then click OK.
12. Close ADSI Edit, and then restart the Information Store Service.

 Grant the explicit Allow permission to the Exchange Servers permissions group on the Exchange server object in Active Directory.

1. Start ADSI Edit.
2. Expand the Exchange server object.
• If you are running Exchange Server 2007, expand the following container:
  CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=<YourDomain>/CN=Administrative Groups\CN=Exchange Administrative Group/CN=Servers
• If you are running Exchange Server 2003, expand the following container:
  CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=Administrative Group/CN=First Administrative Group/CN=Servers
3. In the right pane, right-click the name of the server, and then click Properties.
4. On the Security tab, click Advanced.
5. On the Permissions tab, click the Name column header to sort the columns by name.
6. In the Name column, locate the security settings that start with Exchange Servers.
7. In the Permission column, locate the following permissions for the Exchange Servers security settings, and determine whether the setting in the Type column is set to Deny:
• Store Constrained Delegation
• Store Read and Write Access
• Store Read only Access
• Store Transport Access
8. If a permission is set to Deny, click the setting, click Edit, click to select the Allow check box for the permission, and then click OK.
9. After the permissions identified in step 7 are set to Allow, click OK two times, and then close ADSI Edit.

Troubleshooting Mail Flow Issues due to Mailbox Logon Failure

This topic provides information about how to troubleshoot Microsoft Exchange Server 2007 mail flow issues due to mailbox logon failure. The following symptoms are sometimes an indication of this failure:

• Inbound mail flow is stuck in the queue with the following error message:
  430 4.2.0 STOREDRV; mailbox logon failure
• When you use Microsoft Outlook to send e-mail messages to local recipients, the e-mail messages are sent and appear in the Sent Items folder, but e-mail recipients never receive your e-mail messages. You also cannot track these messages by using the Message Tracking tool.
• On an Exchange 2007 Mailbox server, you may find Event ID 1009 in the Application log:
  The Microsoft Exchange Mail Submission service is currently unable to contact any Hub Transport servers in the local Active Directory site. The servers may be too busy to accept new connections at this time.

This issue occurs when the Microsoft Exchange Transport service is configured to log on using another account, instead of the Network Service account. For example, the Microsoft Exchange Transport service is configured to log on using the Administrator account.

 Resolution

To resolve the problem, change the logon account back to the Network Service account.

   Procedure

 To configure the logon account back to the Network Service account

1. On the Exchange 2007 Hub Transport server, click Start, click Run, type Services.msc, and then click OK.
2. In the list of services, right-click Microsoft Exchange Transport, and then click Properties.
3. Click the Log On tab, and then click This account.
4. Click Browse, type Network Service, click Check Names, and then click OK.
5. Remove the password from the Password and Confirm Password edit boxes.

Note:

Microsoft Windows automatically generates a password for the Network Service account. Therefore, you do not have to specify a password for this account.

6. Click OK. Then restart the Microsoft Exchange Transport service.

Troubleshooting MSExchangeTransport Service Events

Microsoft Exchange Server 2007 introduces service resource management to detect and take action on heavily loaded Exchange servers. When a system is under heavy load, more load should not be added. Exchange 2007 servers with either the Hub Transport or Edge Transport server roles installed have several minimum resource requirements that must be maintained. Thresholds for different resources are managed by the Microsoft Exchange Transport service (MSExchangeTransport.exe).

When an Exchange 2007 Hub Transport or Edge Transport server exhausts these monitored resources, the service will stop accepting new messages until the resources reach acceptable levels. This situation is called back pressure.

When these resource requirement thresholds are exceeded, Event IDs 15001, 15002, or 15003 are logged. In addition, Microsoft Exchange Server 2007 Service Pack 1 (SP1) includes events 15004 and 15005.

For all resources, a value of Normal is within normal operating levels, Medium indicates potentially high utilization, and High means that the server is resource-constrained and will stop accepting new messages. In that case, symptoms such as the following occur:

• Messages submitted to Exchange with Microsoft Office Outlook or Outlook Web Access may stay in the Outbox if this is the only Hub Transport server.
• When attempting to connect to the server's Simple Mail Transfer Protocol (SMTP) receive connector (for example, Telnet to port 25), the following string is received: 452 4.3.1 Insufficient system resources.

The default values and troubleshooting suggestions for each resource that is being monitored are listed in the following table. In most cases, consider running the Exchange Mail Flow Analyzer tool because this tool not only provides you with these suggestions, but it also reviews the server's overall health.

Note:

CPU and network utilization are not monitored by the Microsoft Exchange Transport service.

Troubleshooting suggestions for resources monitored by the Microsoft Exchange Transport service

Resource being monitored	Description	Troubleshooting suggestions	Default High value	Default Medium value	Default Normal value
Private bytes used	The PercentagePrivateBytesUsed parameter is used to monitor the percentage of private bytes used by the EdgeTransport.exe process. The monitor is checking to make sure that the private bytes used does not exceed a default private bytes limit. For x64 computers, this limit is equal to 75% of the total physical RAM, or 1 terabyte (whichever is less).***	The EdgeTransport.exe process consumes memory as the queues fill. Check the queues to make sure that there are not any issues. If there are issues, troubleshoot the queues with the Exchange Mail Flow Analyzer (found in the Exchange Toolbox).	75%	73%	71%
Physical memory used	The PercentagePhysical MemoryUsedLimit parameter is used to monitor the total amount of memory in use by all processes.	Situations where the default High value is exceeded can be caused by queuing messages, which you probably want to troubleshoot. Often, the server attempts to reclaim memory by removing the least active messages from memory (dehydrating the queue). If this problem occurs frequently, consider removing roles from the server or re-evaluating your hardware (for example, add memory or add additional servers). Dehydrating the queue means that unnecessary elements of queued messages are removed from cached memory, but still remain in the queue.	94%	89%	84%
Database disk space used	The intent of the PercentageDatabaseDiskSpaceUsed parameter is to monitor for available space for queued messages. This is done by monitoring the amount of used space in the database and comparing it to the amount of free space in the database and on the disk. This computation also takes into consideration the total disk size. The minimum free space is always 4GB in the release to manufacturing (RTM) version of Microsoft Exchange Server 2007 and 500MB with Microsoft Exchange 2007 SP1.	To prevent data loss, there are situations where Exchange may stop accepting mail. This may be caused by insufficient free disk resources. Check the queues for messages backing up. If the partition that holds the queue is too small, consider moving it to a drive with more space. Remove unnecessary files from the drive that holds the queue. In Exchange 2007 RTM, this issue occurs most frequently when the drive has less than 4 GB available. In Exchange 2007 SP1, this issue occurs most frequently when the drive has less than 500 MB available. Requirements will be higher if the transport dumpster is enabled (if cluster continuous replication is used).	*	High value minus 2%	High value minus 4%
Amount of free hard disk drive space for message queue database transaction logs	The PercentageDatabase LoggingDiskSpaceUsed parameter monitors the amount of free space on the disk to make sure that the transaction logs always have enough room for committed transactions.	To prevent data loss, there are situations where Exchange may stop accepting mail. This may be caused by insufficient free disk resources If the queue database's transaction logs are on a different drive than the database, this issue indicates that the drive is too small.	**	High value minus 2%	High value minus 4%
Number of version buckets	Extensible Storage Engine (ESE) databases keep an in-memory list of modifications made to the database known as a Version Store. The VersionBuckets parameter keeps track of the number of different versions that are in memory because it is important that they are committed to disk. The size of allocated version buckets will fluctuate under normal conditions, but sizes can increase to unacceptable levels for various reasons, such as antivirus issues, problems with Jet integrity, large messages going through transport, and disk input/output (I/O) performance. If the size becomes too high, it could indicate that the Version Store has too many outstanding modifications that have yet to be committed.	Situations where the version buckets remain high are often transient and can generally be ignored. If the problem occurs frequently, it may be a good idea to verify that you have message size limits. If large messages are not the cause, consider monitoring the disk I/O performance counters to see if there is an underlying disk performance issue that could be causing the issue.	RTM: 100 SP1: 200	RTM: 60 SP1: 120	RTM:40 SP1: 80

*   RTM Limit = 100 X(totalNumberOfBytesOnDisk – 4 GB) ÷ totalNumberOfBytesOnDisk

     SP1 Limit = 100 X (totalNumberOfBytesOnDisk – 500 MB) ÷ totalNumberOfBytesOnDisk

**  Limit = (totalNumberOfBytesOnDisk – (CheckpointDepthMax × 25)) × 100 ÷ totalNumberOfBytesOnDisk

***   32-bit Exchange is not supported in production. However, for x86 computers using the /3GB switch, there is a limit of 1800 MB or 75% of physical RAM, whichever is less. For x86 computers without the /3GB switch, there is a limit of 800 MB or 75% of physical RAM, whichever is less.

In the following example of a warning event, the disk that the queue was located on was roughly approximately 8 GB in size. The amount of free space was approximately 3.6 GB, which was insufficient for the server to accept new messages safely. The problem was resolved by moving the queue database to a larger drive.

Event Type: Warning Event Source: MSExchangeTransport Event Category: ResourceManager Event ID: 15002 Description: The resource pressure is constant at High. Statistics: Queue database and disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que") = 54% [High] [Normal=45% MediumHigh=47% High=49%] Queue database logging disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\") = 54% [Normal] [Normal=89% MediumHigh=91% High=93%] Version buckets = 0 [Normal] [Normal=40 MediumHigh=60 High=100] Private bytes = 10% [Normal] [Normal=71% MediumHigh=73% High=75%] Physical memory load = 52% [limit is 94% to start dehydrating messages.]

Troubleshooting Outbound Mail That is Put in the Unreachable Queue on the Hub Transport Server

This topic provides information about how to troubleshoot the mail flow problem in which you cannot send messages from a Microsoft Exchange Server 2007 Hub Transport server to a remote destination. This problem occurs when you try to send e-mail to an external domain and the message is put in the Unreachable queue on the Hub Transport server. The last error for the message says "A matching connector cannot be found to route the external recipient."

The Unreachable queue is a persistent queue that contains messages that cannot be routed to their destinations. Regardless of destination, all messages that have unreachable recipients reside in this queue. The messages remain in the Unreachable queue until they expire or until the administrator resubmits the messages to the categorizer.

Unlike earlier versions of Microsoft Exchange, mail flow to and from the Internet is not enabled automatically when you install Exchange 2007. You must configure an Edge Subscription or manually configure Send connectors to enable Internet mail flow. For more information, see the "For More Information" section of this topic.

 Configuring Internet Mail Flow

To complete mail flow configuration for the Exchange organization and to send and receive e-mail to and from the Internet, you must configure Send connectors and Receive connectors that enable at least one Hub Transport server to connect to the Internet. You can configure Internet connectivity for a Hub Transport by using any of the following methods:

• You can deploy an Edge Transport server and subscribe it to the Exchange organization. This is the recommended deployment method. By default, when you create the Edge Subscription, the required Send connectors are automatically created. You do not have to modify the configuration of the default Receive connector on the Hub Transport server for this scenario.
• You can send and receive Internet e-mail by relaying through Microsoft Exchange Hosted Services or another third-party Simple Mail Transfer Protocol (SMTP) gateway server. In this scenario, you have to create a Send connector and a Receive connector between the Hub Transport server and the external SMTP servers that process and route Internet e-mail.
• You can establish Internet mail flow directly through a Hub Transport server. In this scenario, you have to create a Send connector that routes e-mail to the Internet. Also, you have to modify the configuration of the default Receive connector to accept anonymous e-mail submissions. In this scenario, the Exchange 2007 Hub Transport server can be reached directly through the Internet. We don't recommend this topology because it increases security risks by exposing to the Internet the Exchange 2007 server and all roles installed on that server. We recommend that you implement a perimeter network-based SMTP gateway, such as the Edge Transport server, instead.

Troubleshooting Mail Flow Between Exchange 2003 or Exchange 2000 Servers and an Exchange 2007 Hub Transport Server

This topic provides information about how to troubleshoot mail flow between servers that are running Microsoft Exchange Server 2003 or Exchange 2000 Server and an Exchange Server 2007 Hub Transport server. This problem occurs when you have deployed at least one Exchange 2007 Hub Transport server in an existing Exchange organization. When you try to send messages between the two mail systems, the messages are put in the Unreachable queue on the Hub Transport server or in the Messages with an unreachable destination queue on an Exchange 2003 or Exchange 2000 server.

This problem can occur when no routing group connector is created during the installation of the first Hub Transport server in an existing organization. A routing group connector is required for mail flow between Exchange 2007 and Exchange 2003 or Exchange 2000. During setup, two routing group connectors are automatically created to enable mail flow in both directions. If you use the Setup wizard, select an Exchange 2003 or Exchange 2000 bridgehead server to act as the source server for one routing group connector and as the target server for the reciprocal connector. If you use Setup.com to perform an unattended installation, you must provide the /legacyroutingserver parameter to automatically create the required routing group connectors. If you do not perform this procedure during setup of the first Hub Transport server, the two e-mail systems cannot determine a route between them. Messages that are sent from users with mailboxes located on Exchange 2003 or Exchange 2000 servers to recipients with mailboxes located on Exchange 2007 Mailbox servers are put in the Messages with an unreachable destination queue on an Exchange 2003 or Exchange 2000 server. Messages that are sent from users with mailboxes located on Exchange 2007 Mailbox servers to recipients with mailboxes located on Exchange 2003 or Exchange 2000 servers will queue in the Unreachable queue on the Exchange 2007 Hub Transport server.

The Unreachable queue is a persistent queue that contains messages that cannot be routed to their destinations. Microsoft Exchange can resolve and locate the recipient. But Microsoft Exchange can't determine how to reach the destination. The messages remain in the Unreachable queue until they expire or until the administrator resubmits the messages to the categorizer.

To resolve this problem, you must create the required routing group connectors. You can't use Exchange System Manager on the server that runs Exchange 2003 or Exchange 2000 to perform this procedure. You must use the Exchange Management Shell on the Exchange 2007 server.

 Before You Begin

To perform this procedure, the account you use must be delegated the following:

• Exchange Organization Administrator role

 Procedure

 To use the Exchange Management Shell to create routing group connectors

1. Run the following command to create a routing group connector from Exchange 2007 to Exchange 2003 or Exchange 2000 and to automatically create the reciprocal routing group connector. This command sets the routing group connector cost as 10 and enables public folder referrals between the two versions of Exchange Server:

New-RoutingGroupConnector -Name "Interop RGC" -SourceTransportServers "Ex2007Hub1.contoso.com" -TargetTransportServers "Ex2003BH1.contoso.com" -Cost 10 -Bidirectional $true -PublicFolderReferralsEnabled $true

2. Run the following command to verify that the two routing group connectors are created:

Get-RoutingGroupConnector

For detailed syntax and parameter information, see Routing Group Connector Cmdlets.

Troubleshooting Mail Queues That Are Increasing on Edge Transport Servers

This topic explains how to resolve the problem of inbound or outbound e-mail messages that are stuck in queues on a server running Microsoft Exchange Server 2007 with the Edge Transport server role installed. When this situation occurs, you will typically see the following errors in the Last Error column in the Exchange Queue Viewer:

• 451 4.4.0 DNS Query Failed
• 400 4.4.7 Message Delayed

This problem commonly occurs as a result of a mistake in the configuration of the DNS settings of the Edge Transport server. Therefore, you can resolve this problem by correcting the DNS configuation.

 Before You Begin

Confirm that any firewall between your Hub Transport servers and your Edge Transport servers allow port 53 for DNS resolution and port 25 for SMTP traffic.

To perform this procedure, the account you use must be delegated the following:

• Local Administrator
• Exchange Organization Administrator

 Procedure

 To use the Exchange Management Console to reconfigure DNS settings when inbound mail is queued on an Edge Transport server

1. Start the Exchange Management Console on the Edge Transport server.
2. Click Toolbox.
3. Select Queue Viewer under the Mail flow tools category to open the Queue Viewer tool.
4. Review the information in the Last Error column. Note whether you have an inbound message queue for an accepted domain, such as "company.com", and if there is an error similar to "451 4.4.0 DNS Query Failed".
5. Verify the DNS configuration on the Edge Transport server as follows:
1. Log on locally to the Edge Transport server.

Important:

Do not view or change these settings remotely from an administrative workstation or a server other than the Edge Transport server. You can use Remote Desktop Connection (RDC) 6.0 to access the physical server. We recommend that you use a console session by starting your RDC session using the /console switch.

2. Open the Exchange Management Console.
3. Select the Edge Transport server in the Result pane, and then select Properties.
4. Select the Internal DNS Lookups tab.
5. The default configuration is All Available. Your Edge Transport server will need to do external and internal DNS lookups. You have two options available:

2. If you have multiple NIC adapters, and one is for the internal network, select that network card in Use network card DNS settings. The IP addresses will populate the box below with the DNS server IP addresses that are specified on the internal network card. Restart the Transport service, and then repeat step 5 to confirm that the configuration is correct. If you do not see any IP addresses, the NIC card may not be configured with DNS server entries. Populate the card with DNS settings, and then repeat step 5 to ensure that the settings are correct.
3. If you have only one network card, and it is using external public DNS, you do not want to change this setting because it will break external name resolution and e-mail flow. There are two options in this scenario. You can select Use these DNS servers and then select the IP address of the internal DNS server, or you can add a host file containing the DNS server information.
6. After making changes, test your DNS servers and name resolution with NSLOOKUP
7. Next, test ping and telnet to your internal mail server. If ping or telnet connections are failing, check to see if the Windows Firewall in Control Panel/ Services has been enabled. It is typically disabled. If it is enabled, it needs to be configured on the NIC cards to allow services for mail flow, such as SMTP, LDAP, the Edge Transport server LDAP ports, and testing protocols such as ICMP. Enable only those ports that are required for the services that you are using.

 To use the Exchange Management Console to reconfigure DNS settings when outbound mail is queued on an Edge Transport server

1. Start the Exchange Management Console on the Edge Transport server.
2. Click Toolbox.
3. Select Queue Viewer under the Mail flow tools category to open the Queue Viewer tool.
4. Review the information in the Last Error column. Note whether you have an outbound message queue and if there is an error similar to "451 4.4.0 DNS Query Failed".
5. Verify the DNS configuration on the Edge Transport server as follows:
1. Log on locally to the Edge Transport server.

Important:

Do not view or change these setting remotely from an administrative workstation or a different server. You can use Remote Desktop Connection (RDC) 6.0 to access the physical server. We recommend that you use a console session by starting your RDC session using the /console switch.

2. Open the Exchange Management Console.
3. Select the Edge Transport server in the Result pane, and select Properties.
4. Select the External DNS Lookups tab.
5. The default is All Available. Your Edge Transport server will need to do external and internal DNS lookups. You have two options available:

2. If you have multiple NIC adapters, and one is for the external network, select that network card Use network card DNS settings. The IP addresses will populate the box below with the DNS server IP addresses specified on the external network card. Restart the Transport service, and then repeat step 5 to confirm that the configuration is correct. If you do not see any IP addresses, the NIC card may not be configured with DNS server entries. Populate the card with DNS settings, and then repeat step 5 to ensure that the settings are correct.
3. If you have only one network card, and it is using internal DNS, you do not want to change this setting because it will break internal name resolution and e-mail flow from the Internet to your Hub Transport servers. Select Use these DNS servers, and then select the IP address of the external public DNS server(s).
6. After making changes, test your DNS servers and name resolution with NSLOOKUP
7. Next, test ping and telnet to your internal mail server. If ping or telnet connections are failing, check to see if the Windows Firewall in Control Panel/ Services has been enabled. It is typically disabled. If it is enabled, it needs to be configured on the NIC cards to allow services for mail flow, such as SMTP, LDAP, the Edge Transport server LDAP ports, and testing protocols such as ICMP. Enable only those ports that are required for the services you are using.