Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 3)

If you would like to read the other parts in this article series please go to

In the first two parts of this series on how to publish Exchange 2007 Web services using the ISA Firewall, we discussed the network infrastructure and topology required to set up a secure solution and noted some of the limitations imposed by Exchange 2007 at the present time. We then went through the trials and tribulations of getting Exchange 2007 installed on the Mailbox server and Hub transport server.

In this article, which is part 3 of the series, we will return to the Mailbox and Hub Transport server and configure the SMTP “service” on the Hub Transport Server. I put “service” in quotes since there doesn’t seem to be an SMTP service as there was in Exchange 2003.

Discuss this article

Configuring the Hub Transport Server to Send and Receive SMTP Mail to and from the Internet

In the last article we used help information provided in the Exchange Management console to help us get started. That is all there is for guided support by the Exchange Server team. Now we are on our own. The first thing that occurred to me was that we needed some way to send outbound SMTP messages to the Internet. That was pretty easy with Exchange 2003 and the SMTP service, because it is intuitive to think of configuring the SMTP service as sending and receiving SMTP mail. After all, that is what it is supposed to do.

After doing some searching through the Exchange Server Help file, I quickly found out that there is no such thing as an SMTP “service” on Exchange 2007. I do not know what they call the SMTP services now, but it is not the SMTP service. I guess calling it the SMTP service would have been too easy and Exchange Team realizes that the real fun in life is not in the having, but in the wishing. In order words, the real joy comes from the chase, not the catching.

From my investigations it appears that we need to create a Send Connector. Without one of these Send Connectors you will not be able to send mail to the Internet, so we better create one. Go to the Organization Configuration\Hub Transport node in the left pane for the console. Click on the Send Connectors tab in the middle pane of the console. Right click on an empty area in the middle pane and click New Send Connector.


Figure 1

On the New SMTP Send Connector page, put a name for the connector in the Name text box. In this example we will name it Internet bound Mail. From the Select the intended use for this Send connector drop down list, select Internet. Click Next.


Figure 2

On the Address Space page, click the Add button. In the Add Address Space dialog box, put an asterisk in the Domain text box. I put a checkmark in the Include all subdomains checkbox, although I do not know if this is required, since the wildcard tells the Exchange Server to send all mail to any domain through this SMTP connector (except for those domains that the Exchange Server is authoritative for) . Click OK in the Add Address Space dialog box.


Figure 3

You now see the wildcard domain listed and the type is smtp. Click Next.


Figure 4

We have several options to select from on the Network settings page. The default setting is to Use domain name system (DNS) “MX” records to route mail automatically. When this setting is enabled, it becomes the responsibility of the Exchange Server to look up the MX records for the destination domain and resolve those to an IP address.

Another option is to offload this responsibility to another SMTP server. When you offload the MX domain name resolution to another SMTP server, that other SMTP server is acting as a Smart Host. It is not uncommon to use the ISP’s SMTP server as a Smart Host. One of the advantages of this is that it is likely that there is a reverse DNS record for your ISP’s SMTP server, so you do not have to worry about reverse lookups at the destination DNS server. That is because the destination DNS server only looks at the name resolution for the last hop, not each hop the SMTP message may take on the way to its destination.

Another option on this page is to Use the External DNS Lookup settings on the transport server. By default, the Exchange Server will use the DNS server configured on its NIC to resolve the MX domain names. However, you might run an environment where you do not want internal machines to resolve Internet domain names (for example, you want the ISA Firewall to perform external name resolution, which forces clients to be Web proxy and/or Firewall clients). This is in general a more secure configuration and something recommended by world class security experts such as Tim Mullen (Thor).

When you select the Use the External DNS Lookup settings on the transport server option, you have the option to configure the SMTP “service” to use an alternate DNS server that can resolve Internet host names. In this way, you enable the SMTP “service” to resolve Internet MX domain names while preventing all other applications and services on the machine from resolving any Internet host name.

In this example, we will use the default setting, Use domain name system (DNS) “MX” records to route mail automatically. Click Next.


Figure 5

On the Source Server page, you will see that our Transport Server is already added to the list. Since we only have one, we do not need to add any more. Click Next.


Figure 6

Review the settings on the New Connector page and click the New button.


Figure 7

Click Finish on the Completion page.


Figure 8

Discuss this article

Double click the Internet Bound Mail Send Connector that you created. This opens the Internet Bound Mail Properties dialog box. On the General tab, you need to make an entry in the Specify the FQDN this connector will provide in response to HELO or EHLO. This is an important setting if you are not using a Smart Host because the public IP address where outbound mail exits your organization must reverse resolve to the name you put here. If you are using a Smart Host this probably will not matter.


Figure 9

Click on the Server Configuration\Hub Transport node in the left pane of the Exchange console. Double click on the EXCH2007MB entry in the middle pane of the console.

In the EXHC2007 Properties dialog box, click on the External DNS Lookups tab. Here you have two options:

  • Use network card DNS settings This option allows you to use the DNS settings on the NIC installed on the Exchange Server. If you have multiple NICs on the Exchange Server, then you can choose the NIC from the drop down list. When you do so, you will see the DNS server address in the This adapter contains the following DNS server entries list.
  • Use these DNS servers – Choose this option when you want to use a DNS server that is not listed on any of the NICs installed on the Exchange Server.

In this example, we will use the DNS server address bound to the NIC, which is the IP address of the DNS server installed on the domain controller for this network.


Figure 10

There is one more thing we need to do to allow anonymous inbound connections to the Default receive connector on this Hub Transport Server. In general, you should not do this since you are allowing anonymous inbound connections to an Internet facing host located on the same security zone at the domain controller and mailbox server (in this example, the mailbox server is collocated on the Hub Transport Server). In a secure environment, you would use an inbound SMTP relay on an anonymous access DMZ. This could be an IIS SMTP server, or an Exchange Edge Server.

Double click on the Default EXCH2007MB Receive Connector in the middle pane on the Exchange Management console. On the Default EXCH2007MB Properties dialog box, click the Permission Groups tab. Put a checkmark in the Anonymous users checkbox and click OK.


Figure 11

Now that our send and receive connectors are in place, it might be a good idea to see if they work. We are not yet in a position to test our send connector, since we do not have any clients setup to send mail through the Hub Transport Server, but we can test the receive connector by establishing a telnet connection to TCP 25 on the Hub Transport server. When I tried to establish the telnet connection to TCP port 25 on the Hub Transport Server I saw what appears in the figure below.


Figure 12

Turning off “Back Pressure” Service Disablement

Insufficient system resources? What’s up with that? Maybe the SMTP “service” or something like that did not start. Since there is no SMTP “service” in Exchange 2007, it was not clear what service I should be looking for. Since the SMTP “service” is something that should be started automatically, I tried to identify an Exchange service that was set to automatic but failed to start. Unfortunately, I did not find such services.

The next place to check is the Event Viewer. An event seen in the figure below indicated that “resource pressure” was “high”. Maybe that was the problem, but I still did not have a clue.


Figure 13

I blogged about this problem and Marc Grote came to my rescue. He pointed me to a page on microsoft.com that explained that this is likely to be a “back pressure” problem.

Back pressure is a system resource monitoring feature of the Microsoft Exchange Transport service that exists on computers that are running Microsoft Exchange Server 2007 that have the Hub Transport server role or Edge Transport server role installed. Important system resources, such as available hard disk drive space and available memory, are monitored. If utilization of a system resource exceeds the specified limit, the Exchange server stops accepting new connections and messages. This prevents the system resources from being completely overwhelmed and enables the Exchange server to deliver the existing messages. When utilization of the system resource returns to a normal level, the Exchange server accepts new connections and messages.

The following system resources are monitored as part of the back pressure feature:

  • Free space on the hard disk drive that stores the message queue database.
  • Free space on the hard disk drive that stores the message queue database transaction logs.
  • The number of uncommitted message queue database transactions that exist in memory.
  • The memory that is used by the EdgeTransport.exe process.
  • The memory that is used by all processes.

For each monitored system resource on a Hub Transport server or Edge Transport server, the following three levels of resource utilization are applied:

  • Normal   The resource is not overused. The server accepts new connections and messages.
  • Medium   The resource is slightly overused. Back pressure is applied to the server in a limited manner. Mail from senders in the authoritative domain can flow. However, the server rejects new connections and messages from other sources.
  • High   The resource is severely overused. Full back pressure is applied. All message flow stops, and the server rejects all new connections and messages

You can find everything you need to know about back pressure at Understanding Back Pressure  Most importantly, it tells you how to turn it off. This is useful in a VM based lab environment, but it is probably not a good idea to leave it off in a production environment.

To turn off back pressure monitoring, go to C:\Program Files\Microsoft\Exchange Server\Bin and find the EdgeTransport.exe.config file and double click on it.


Figure 14

Open the file in Notepad. Find the EnableResourceMonitoring entry and change the value from true to false. Save the file and restart the server. You will not see any more back pressure related messages and you will be able to telnet to your receive connector.


Figure 15

Summary

In this article we configured the Exchange 2007 Hub Transport server’s SMTP “service”. We configured the Exchange Server to accept incoming SMTP messages and send outgoing SMTP messages. We finished up the article with instructions on how to turn off the “back pressure” monitoring features which is designed to disable the SMTP service unless certain circumstances. Next week we will continue with installing and configuring the Exchange Client Access Server. See you then! –Tom.

Discuss this article

If you would like to read the other parts in this article series please go to

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top