We ended with configuring of server side to prepare the remote access to Exchange mailbox from the outside. Now we can start configuring the client side. In other words, we need to what we should do as the users to be able to receive corporate mail while we are sitting home or traveling with our laptop on the business trip. But before we will do that I will go a little backward and say that we as admins should pay our attention to the fact how we configure our environment. In that our specific case when we should provide user with access to the network the outer network perimeter is what pays our attention. What we do usually to prevent ourselves from being attacked from the outside? As with medieval battles, we close our doors, close our windows (oopps, let leave Windows running for little more we haven’t finished with configuring its client application) and left just a pair of doors left open. For us themselves, our friends and our bodyguards. The same way we do when our medieval castle turns into our corporate network. We usually leave to ports open: the one for HTTP (that’s we ourselves as we as our friends, the users, need access to information) and the one for SSL (that’s our bodyguard that keeps our connection secure by using public key encryption). But aren’t we here to communicate with Exchange server? How will we do that if we just have HTTP(S)? We need to be able of doing remote procedure calls. But we blocked them! How should be manage to be able to use them anyway. Uh, again we should carry that weight on our own shoulders. Let’s help the RPC and let HTTP to carry it on top. That’s exactly what we do there. We use RPC over HTTP. We encapsulate RPC network filesystem commands into HTTP headers. So here’s the scheme we have:
1. We send the request from the Outlook client application via SSL
2. It then comes to the corporate firewall (such as ISA firewall)
3. As ISA sees HTTP traffic on its input it passes the flow forward
4. Now we have the Front-End Exchange server on our way. Shortly, front-end server is the component that authenticates and proxifies HTTP requests

Typically running IIS RPC over HTTP proxy service is enough. So the main thing here to get is proxy.

Note: if you are still running old Windows XP SP1 clients you should keep this and mind and prepare your system and install the hotfix specified in the article to make to Outlook work reliable.

Keep in mind that to configure the profile on the client side and begin working with RPC over HTTP you should have your RPC port (that is the 135 one) opened prior that. Here are the recommendations provided by Microsoft for building the Front-End and Back-End Topology:
“Open TCP ports on the intranet firewall for the protocols you are using:

80 for HTTP

143 for IMAP

110 for POP

25 for SMTP

691 for Link State Algorithm routing protocol

Open ports for Active Directory Communication:

TCP port 389 for LDAP to Directory Service

UDP port 389 for LDAP to Directory Service

TCP port 3268 for LDAP to Global Catalog Server

TCP port 88 for Kerberos authentication

UDP port 88 for Kerberos authentication

Open the ports required for access to the DNS server:

TCP port 53

UDP port 53

Open the appropriate ports for RPC communication:

TCP port 135 – RPC endpoint mapper

TCP ports 1024+ – random RPC service ports

(Optional) To limit RPCs across the intranet firewall, edit the registry on servers in the intranet to specify RPC traffic to a specific non random port. Then, open the appropriate ports on the internal firewall:

TCP port 135 – RPC endpoint mapper

TCP port 1600 (example) – RPC service port

If you use IPSec between the front-end and back-end, open the appropriate ports. If the policy you configure only uses AH, you do not need to allow ESP, and vice versa.

UDP port 500 – IKE

IP protocol 51 – AH

IP protocol 50 – ESP

UDP port 88 and TCP port 88 – Kerberos”

Still the great thing with Outlook 2003 is that it IS able to configure the profile even without port 135 opened! Yes, it will swear on you that you have not opened port 135 but in the end you will get the profile configured. You just need your DNS working properly.

We sorted out the underlying process and can now freely begin with setting up the client side.

1. The first step is as always to start Mail control panel applet to configure the MAPI profile. There are at least two ways to do that:
1. We can click Start\Control Panel\Mail
2. We can right-click the Outlook icon in the Start menu and select Properties from the context menu
2. In the opened Mail dialog click Add button to add or create new profile
3. Now create new mail account by selecting Add a new e-mail account in the E-mail Accounts wizard or change the existing one by selecting the View or change existing e-mail accounts
4. On the Server Type window select Microsoft Exchange Server and click Next
5. On the Exchange Server Settings window specify the Fully Qualified Domain Name for the front-end Exchange server (refer to the info shown in the IIS site certificate to get the right name) such as exchange.acme.com. Type your user account in the Username field
6 . In the Microsoft Exchange Server dialog box switch to the Advanced tab (I recommed leaving the settings specified on the General tab intact), check Use local copy of Mailbox and set the Download only headers checkbox. This is expecially useful when configuring settings for the roaming client that uses laptop
7. Switch to the Security tab and check the Encrypt information checkbox
8. Now we are ready to do what are here for. Switch to the Connection tab and set Connect to my Exchange mailbox using HTTP checkbox
9. Click the Exchange Proxy Settings… button and configure the URL (such as exchange.acme.com) used to connect to your RPC proxy by setting it in the Use this URL to connect to my proxy server for Exchange text box. Check the Mutually authenticate the session when connecting with SSL checkbox. In the Principal name for proxy server text box put the FQDN preceded with the msstd: string. So that with exchange.acme.com you should specify msstd:exchange.acme.com as the principal name for the proxy server
10.1. Check both checkboxes for the slow and fast connections
10.2 If you have the single Connect using HTTP first, then connect using my Local Area Network (LAN) checkbox only, now you know what Microsoft means under LAN…
11. Select Basic Authentication and click OK to close the Window
12. We finished the process and can now start the client application. Depending on whether you have that command in the Outlook icon in the notification area of the taskbar you willl be able to observe established connections to the server by choosing the status command.

Note: as Microsoft says Outlook (in contrast to Group Policy which is “defined by default as any rate slower than 500 kilobits per second (Kbps)“) “defines a fast connection as a connection that is faster than 128 kilobits per second (Kbps). Outlook defines a slow connection as a connection that is slower than or equal to 128 Kbps”

How to Create an Outlook Profile for Users to Use with RPC over HTTP
Target-based Automated Client Configuration with Ability to Update and Add the RPC over HTTP Functionality for the Domain User

The Group Policy Slow-Link Detection Formula

Technorati tag: