Using the RPC Filter to Publish Microsoft Exchange

By Thomas W Shinder MD

 

I’ve done a few article on publishing mail servers, but one area that I haven’t touched upon is how to take advantage of the RPC application filter that allows you to use Outlook MAPI clients on the Internet to access an Exchange Server on your internal network. Exchange RPC publishing is very easy to do, and provides an excellent method for your external MAPI to connect to their Exchange message store.

 

Why Use Exchange RPC Publishing?

 

Why would you want to use an Exchange RPC Server Publishing Rule? Here are some advantages:

 

 

There is a general impression that RPC connections are not secure. This is not the case when you use the Exchange RPC filter to publish Exchange Servers. The RPC filter handles the connections between the Internet Outlook client and the internal Exchange Server and creates dynamic packet filters that can only be used by specific Outlook clients.

 

You can configure the Outlook client to encrypt data over the connection. If you do a Network Monitor trace, you’ll find that even when the data isn’t encrypted, there is nothing interesting that you can find in the decode. When you add data encryption to the mix, you are assured of a very high level of security for your data transferred between the Outlook client and the internal Exchange Server

 

Exchange RPC publishing is easy! A single Server Publishing Rule allows your Internet MAPI clients to access the internal Exchange Server. It just doesn’t get much easier than that!

 

If you don’t use Exchange RPC Server Publishing, the only other way you can connect your MAPI clients to an internal network Exchange Server is to allow these clients to establish a VPN link into the internal network. While this option is a viable one for your network administrators and other trusted accounts, you do not necessarily wants all your users (which might include contractors and temps), to have free reign over the corporate network from remote locations. Exchange RPC Server Publishing gets around this problem by allowing users access only to the Exchange Server and nothing more.

 

Users tend to balk when they have to switch applications to get the same job done. This is especially the case with mail client software. If you have standardized your users on Outlook 2000/XP, those users will want to continue to use Outlook while at home or on the road. Exchange RPC publishing gives them the ability to use the same familiar interface they use at work while at home or on the road.

 

How Exchange RPC Publishing Works

 

The typical “on the road” Outlook client first establishes a connection to the Internet via a local ISP. The Outlook client might also be on a remote network and connects to the Exchange Server via a NAT server on the remote network. The user than opens the Outlook client. When Outlook is opened, the following communications take place:

 

  1. Outlook establishes a connection to TCP 135 on the external interface of the ISA Server.
  2. The ISA Server’s Exchange RPC filter intercepts the request and forwards the request to the internal network Exchange Server. The internal network Exchange Server responds to the request by sending a port number on which the Outlook client can sends its messages to. The Exchange RPC filter on the ISA Server intercepts this response and opens a dynamic packet filter on its external interface. The dynamic packet filter assigns a port on the external interface of the ISA Server on which only the Outlook client can communicate on. Any other Internet host will not be able to use that port for inbound access, and the ISA Server dedicates that port to communicate with the Internet Outlook client. The ISA Server maps this port on its external interface to the port number the Exchange Server expects to receive messages from the Internet Outlook client. In addition, when the Outlook client logs on, it registers a port on which is can receive new mail notification messages from the Exchange Server. The ISA Server RPC filter also registers this port number, creates a dynamic packet filter, and passes the new mail notification messages from the Exchange Server to the Internet located Outlook client.
  3. The ISA Server forwards the response from the Exchange Server. The Outlook client receives the port number on the external interface of the ISA Server to which it can send its messages to the Exchange Server.
  4. The Outlook client establishes a connection to the mapped port on the external interface of the ISA Server and through that port connects to the internal network Exchange Server.

 

Check out the diagram below to see the sequence of events.

 

 

 

Preparing the Infrastructure for Exchange RPC Publishing

 

You need to take care of a few things before your RPC Server Publishing Rule can work correctly. These things include:

 

 

Creating the Supporting DNS Infrastructure

DNS issues crop up constantly on the ISAserver.org message boards and mailing list. If your DNS infrastructure isn’t in place, things just won’t work properly. If your DNS infrastructure is already setup and working, great! If its not, you need to come to terms with it and get your shop in shape.

 

The ideal DNS configuration is which is referred to as a “split DNS”. In the split DNS configuration, you maintain two separate zones, one for internal network clients to use and one for external network clients to use. These two zones will service that same domains, but the resources records on the internal DNS server will have the private IP addresses for your network clients and the external DNS server will have the public IP address for your published network resources.

 

For example, a common compliant I hear is that users on the internal network can access their published Web server, www.domain.com from external network hosts but they can’t access them from internal network clients. The reason for this is related to the fact that the internal network clients are probably trying to connect to the published server via the external interface of the ISA Server because they are using the same host records as the external network clients. When you create an internal DNS server that the internal network clients can use, the internal network clients will receive the private IP address of the published server and therefore will connect directly to the server.

 

Now, in regards to our Exchange RPC publishing situation, you need to make sure the host name of the internal network Exchange Server is the same the host name of the server that is accessible on the Internet. For example, if the server name is exchange.domain.com on the internal network, you need to make sure that exchange.domain.com is also accessible from external network hosts. You can accomplish this with your split DNS configuration by creating a Host (A) record on your external DNS server for exchange.domain.com to point to the external interface address on the ISA Server that you are using in the Exchange RPC publishing rule.

 

The reason why you must configure the Host (A) record is that the name of the Exchange Server is returned to the Outlook client. The Outlook client needs to be able to communicate with the name received from the Exchange Server. Note that only the Host name portion of the FQDN will appear in the client configuration dialog box after the name is resolved.

 

Note:

It is a best practice to use the same name for both the computer DNS host name and NetBIOS name. I have not tested the configuration with a disjoint NetBIOS and DNS host name configuration so I cannot guarantee that it will work if you have a disjoint NetBIOS/DNS host namespace. If you have knowledge in this area, please write to me at tshinder@isaserver.org and I’ll update this article.

 

Creating the DNS and SMTP Protocol Rules

 

The Exchange Server is going to need to forward mail it receives from the Outlook client to SMTP servers on the Internet. There you will need to create two Protocol Rules:

 

 

The DNS Query and Zone Transfer Protocol Rule allows the Exchange IIS SMTP service to resolve the MX domain name records for the outgoing mail. You can configure the Protocol Rule to allow only the Exchange Server access to it, or you can configure it to allow all machines on the network to use it. Access control on the DNS Protocol Rule depends on which machine is resolving the MX domain names. You might want to forward the queries to an internal DNS server and let the DNS server on your internal network take care of name resolution.

 

The SMTP Protocol Rule is required to allow the Exchange Server to send out mail to external network domains. Access controls on the SMTP Protocol Rule depend on what machine actually sends the mail to the external SMTP servers. If the Exchange Server is sending the mail directly to the Internet SMTP servers, allow only the Exchange Server access to the SMTP Protocol Rule. If you are using a mail relay for outbound mail, allow the relay access to the Protocol Rule. If you are using a mail relay, make sure the SMTP relay server has access to the DNS Protocol Rule as well.

 

Configuring the Authentication method

 

When the Outlook client logs into the to the Exchange Server, the Exchange Server instructs the Outlook client to authenticate to an Active Directory domain controller. If you’ve been following my antics here at www.isaserver.org/shinder, you know that its not a no-brainer to get authentication requests and other intradomain communications through the ISA Server. To get around this problem, you can configure the Exchange Server to perform authentication on the behalf of the Outlook client and forward the authentication traffic through the RPC connection to the Outlook client.

 

To configure the Exchange Server to proxy authentication requests navigate to the following registry key:

 

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

 

Add the following:

 

Value: No RFR Service

Type: REG_DWORD

Data: 1

 

Note the value does have spaces in it. At first I thought this might have been a typo in the Microsoft White Paper I got this from, but I confirmed that this value indeed is correct and the spaces should be included between the words. After adding the value, restart the Exchange Server

 

Clients behind NAT Servers/ISA Servers

 

If the Outlook client is behind a NAT server or an ISA Server, it will not be able to receive new mail notification requests. The reason for this is that these new mail notification requests are not affiliated with the existing RPC connection that has already been established to allow communications between the Outlook client and the Exchange Server. Because the new mail notification message is seen as an unsolicited inbound request, the NAT server and ISA Server will drop the packet.

 

This doesn’t mean that you won’t even get any new mail. If you send mail to the Exchange Server, a new mail notification message can be sent through the existing RPC channel between the Outlook client and the Exchange Server. However, RPC wasn’t designed for a lossy network like the Internet. If there is an error in any of the RPC packets the new mail notification, the notification message will not go through. You can get around this by forcing a synchronization with the F9 key in Outlook 2000 or setup the Exchange account to carry out an automatic send/receive every few minutes in Outlook 2002.

 

The good news is that everything else works fine when the Outlook client is behind the NAT server. If you are using the Windows 2000 RRAS NAT, no further configuration is required on the NAT server component. If you there is an ISA Server in front of the Outlook client, you will need to configure an RPC Protocol Definition and then configure the client to be a Firewall client. The reason the Outlook client must be configured as a Firewall client is that SecureNAT clients do not support secondary connections.

 

From what I can tell, you need to create the following Protocol Definition:

 

 

Primary connection: TCP 135 Outbound

Secondary connections: TCP 1025-65534 Outbound

 

My reasoning here is that the initial connection takes place on TCP 135. The remote ISA Server (the one publishing the Exchange Server) sends back to the local ISA Server (the one in front of the Outlook client) the port number on which the Outlook client needs to communicate. Since this new outgoing connection is part of the original RPC conversation, a secondary connection to an ephemeral (high number) port is required outbound from the local ISA Server to the remote ISA Server.

 

Note:

I had a hell of a time testing this protocol definition out. I did use Network Monitor on all the participants in the conversation (Outlook client, local and remote ISA Server, and Exchange Server) and it appears that the Protocol Definition is correct. If you have problems with it or find that it does not work, please let me know by writing to tshinder@isaserver.org) 

 

Creating the Exchange RPC Server Publishing Rule

 

The Exchange RPC Server Publishing Rule uses a Protocol Definition provided by the RPC Application filter. If you disable the Application Filter, you lose the Protocol Definition, so make sure the filter is enabled! Do the following to create the Server Publishing Rule:

 

  1. In the ISA Management Console, expand your server or array name and then expand the Publishing node.
  2. Right click on the Server Publishing Rules node, point to New and then click on Rule.
  3. On the Welcome page, type in a name for the rule and click Next.
  4. On the Address Mapping page, type in the IP address of the internal Exchange Server and the IP address on the external interface you want external network clients to use to access the Exchange Server. Click Next.
  5. ON the Protocol Settings page, select the Exchange RPC Server rule and click Next.
  6. On the Client Type page, select Any Request and click Next. (its unlikely that you’ll be able to identify a client address set to assign the external Outlook clients).
  7. On the final page of the Wizard, click Finish.

 

The rule should take effect soon after you click Finish. If you want the rule to apply right away, restart the Firewall service.

 

Configuring the Outlook Clients

 

Configuring the Outlook client can be an interesting experience. I’ve only used Outlook 2000 to connect to Exchange Servers via RPC over the Internet. Similar procedures should apply to Outlook 2002, but I have not worked through the details of the Outlook 2002 (XP) client.

 

The user can use the same Outlook Profile configuration settings that they use when connecting to the Exchange Server on the Internet network, provided that you have configure your DNS infrastructure correctly.

 

An interesting finding is that if you want to receive new email from the Exchange Server, you must configure the Outlook client to use offline folders. To access this configuration setting, perform the following steps:

 

  1. Right click the Outlook icon on the desktop and click Properties.
  2. Click the Show Profiles button.

 

 

  1. Select a Profile and click Properties.
  2. In the Profile Properties dialog box, select Microsoft Exchange Server and click Properties.

 

 

  1. In the Microsoft Exchange Server dialog box, place a checkmark in the Enable offline use checkbox. You should also enable encryption for on the network and dial-up networking to secure the data. Click Apply and click OK.

 

 

  1. Click OK in the Profile Properties dialog box.
  2. Now start up the Outlook client and log onto the Exchange Server. Right click on the Inbox folder and click on the Synchronization tab. Notice that the folder is available for online and offline use. You want this option to be available to all folders you want to synchronize with the F9 key.

 

If found it interesting that you needed to set up the Outlook client for Offline folders in order to get the F9 key to work. If you use the F5 key, nothing will happen. If you use the F9 key, and you do not configure the Outlook client for offline use, you will see an error that tells you that you haven’t configured the client for offline use. Once Outlook is configured for offline use, everything works great! But under no circumstances does the F5 key appear to do anything.

 

 

Summary

 

Exchange RPC publishing allows your Outlook client users to access the Exchange Server over the Internet in the same way it accesses the Exchange Server over the internal network. If you configure things correctly, the change between internal and external network access to the Exchange Server will be virtually transparent to your remote users. The only exception to this is new mail notification for clients behind a NAT Server or Firewall.

 

I hope you found this article helpful or at least interesting! I would like to thank Steve Riley from Microsoft Consulting Services for inspiring this article. Steve has a presentation on Exchange Server publishing that is very interesting and entertaining. If you get a chance to see him live, tell him I said “hi!” If you have any questions on what I covered in this article, send me a note at tshinder@isaserver.org and we’ll see what can be done to get you fixed up. Thanks! --Tom