Configure Outlook 2003 to use RPC over HTTP/S
How can I configure Outlook 2003 to use RPC over HTTP/S?
RPC over HTTP/S is a cool method for connecting your Outlook 2003 client to the corporate Exchange Server 2003 from the Internet or WAN, without the need to establish a VPN session to the corporate LAN and/or needing to open many ports on your corporate firewall. The only ports you’ll need to open on your firewall are TCP 80 and, if using SSL, TCP 443.
The process of setting up the RPC over HTTP/S connection is outlined in the Setting up RPC over HTTP/S on a Single Server article.
Passwords Haven’t Disappeared Yet
123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?
After configuring RPC over HTTP/S you’ll need to configure your Outlook 2003 client to use the RPC over HTTP/S connection method instead of the regular TCP/IP method.
To set up a new Outlook profile that uses RPC over HTTP/S:
Open Control Panel and run the Mail applet.
In the Mail applet click on Show Profiles.
In the Mail window click on Add.
In the New Profile window type a descriptive name and click Ok.
In the E-Mail Accounts window select Add a new e-mail account and click Next.
In the E-Mail Accounts window, select Microsoft Exchange Server and click Next.
In the E-Mail Accounts window, under the Microsoft Exchange Server box, type the Internal NetBIOS name of the Exchange server. Next, in the User Name box type the logon name of the test user account, the one you’ll be connecting with.
Note: Although pressing the Check Name button will work in the LAN environment, it will NOT work on the WAN, so basically there is no point in pressing it. Next click More Settings.
Note: In this test scenario I recommend NOT to use Cached Mode. We’re working on the LAN, our network connection is steady and fast, and this is only a test account. However, in WAN scenarios where a user needs to connect to his or her mailbox from their portable computer – you should use Cached Mode.
In the Microsoft Exchange Server window, go to the Connection tab. Notice that you should have a section called "Exchange over the Internet" at the bottom of the tab. If this section does not appear, it means that you might not have met the requirements for setting up an RPC over HTTP/S connection. See the "Client Requirements" section on the Configure RPC over HTTP/S on a Single Server page.
In the Exchange over the Internet section click to select the Connect to my Exchange mailbox using HTTP, and then click on the Exchange Proxy Settings button.
In the Exchange Proxy Settings tab in the Connection Settings box, type the FQDN (Fully Qualified Domain Name) of the Exchange server.
Note: For LAN testing you CAN type the Internal FQDN of the server. For WAN connections you MUST type the External FQDN of the server. See Testing RPC over HTTP/S Connection for more on this issue. The external FQDN of the server is the fully qualified domain name that is used by the Outlook clients to connect to the server from outside the LAN, and must be resolved to the IP address of the server, or in most cases, resolved to the IP address of your Firewall (or NAT device) that is configured to transfer the requests to the internal IP address of the Exchange 2003 server.
Very important note regarding SSL: When using SSL (and I recommend you do), you must issue a Digital Certificate to your Exchange server. A Digital Certificate needs to be obtained from a CA (Certification Authority). Windows 2000/2003 has a built-in CA that can be installed and used, however, when issuing a Digital Certificate from your internal CA you MUST be 100% sure that the client computers that are going to connect to the server are properly configured to trust this CA. Most operating systems are pre-configured to trust known 3rd-party CAs such as Verisign, Thawte and others. However unless these computers are made members of the Active Directory domain where you’ve installed your CA, they will NOT automatically trust your CA, and thus your connection will fail! In such scenarios you must import the ROOT CA Digital Certificate into the client computers in order to make them trust your CA. When using 3rd-party trusted CAs in most cases you won’t be required to import anything to the client computers, however you will be required to pay a few hundred dollars for such a Digital Certificate. Search Google for cheap SSL certificates. I personally recommend using Godaddy’s SSL certificates, they are trusted by 99% of the Internet browsers and PPCs, and only cost ~ $20 per year, or less.
Further note on SSL: When you purchase/issue your Digital Certificate for the SSL-protected website, you MUST make sure that the COMMON NAME on the certificate is 100% identical to the External FQDN you’ve just typed!
Note for scenarios where the Exchange 2003 server is NOT the RPC Proxy: In cases where the RPC Proxy is installed on a different server, the FQDN typed in this box should be of the RPC Proxy server, and NOT of the Exchange server!
If you want, click to clear the checkbox near "On fast networks…", and keep the selected checkbox near the "On slow networks…" settings.
In most scenarios you’ll need to select the Basic Authentication setting in the Proxy Authentication settings drop-down list. If you do, notice that you MUST use an SSL-based connection, and you will have to configure a Digital Certificate for your Default Website. Read Configure SSL on Your Website with IIS for more on this issue.
When done, click Ok.
Back in the Microsoft Exchange Server window click Ok.
Back in the E-Mail Accounts window click Next.
Back in the Mail window, click to select Prompt for a profile to be used (unless you only have one profile, duh…), then click Ok.
Now, let’s open Outlook and try to connect to the server. See Testing RPC over HTTP/S Connection for more details.
You may find these related articles of interest to you: