Exchange, Outlook, RPC over HTTP 1

[anonim1]

Looking for some Outlook/Exchange experts out there..

I could easily type several pages to describe in detail what the problem is, but I will only state the crucial information for the sake of your time/my fingers.

I have two separate networks A and B. In network A, I have some PCs all running Windows XP with Outlook 2003. In network B, I have a server machine running Windows Server 2003 and Exchange Server 2003.

The enterprise firewall at network A blocks all incoming AND outgoing connections to port 135. Since Exchange Server by default uses port 135, the Outlook clients cannot see the server. As a solution, I've installed the Windows Server 2003 component called RPC over HTTP, which allows for wrapping RPC packets over the HTTP/HTTPS (80/443) protocol.

The only problem is that, even though both the Exchange server and the Outlook clients are configured for RPC over HTTP, Outlook reports that the Exchange server is unavailable.

To troubleshoot, I used a network analyzer program to track packets. To my surprise, I discovered outgoing packets from the Outlook machines to the Exchange Server's port 135, even though I have configured Outlook to use RPC over HTTP. So it is no surprise that the connection cannot be established.

Does anyone have any suggestions? Is there anyone out there who was able to make RPC over HTTP work with port 135 disabled? Please help, I will be grateful!

 

[jeffwadsworth]

anonim1: are you using the domain/username format for authentication?

I made my own certificate and it indeed needed to be installed by joining the domain. It will not automatically install the correct cert just by connecting to the server via https. Perhaps your set up is different. Believe me, I tried all the angles.

 

[jeffwadsworth]

anonim1: read this post about the certificate install. note what he says about being on the domain. it is true.

http://groups-beta.google.com/group..._doneTitle=Back+to+Search&&d#d62e15fc210c5ba8

 

[anonim1]

jeff,

I'm assuming that you are referring to the following text:

One word of advice since you are going to be using an Internal CA. You must install a copy of the Root CA certificate on your machines. This is done manually for you if using an Enterprise Root CA that is part of your Active Directory domain. (The root certificate is published to all domain members.) If you went a stand-alone CA, then you have to install a copy of the signing root CA certificate on every machine.

Like I said in my last post, joining a domain is not the only way to deal with the CA and certificate installation. You can do it manually by saving the certificate to disk and importing it into your Trusted Root Certificate Authority group, as the article acknowledges (standalone CA).

 

[jeffwadsworth]

Ok. Since we are having a Plato-type discussion which fails right at the beginning, I am out. Good luck with your installation. Cheers.

 

[anonim1]

Actually, I made another discovery which may help you guys make the final suggestion to get this setup working:

Currently, the server has an SSL certificate installed for the external DNS name. I deleted the Exchange profile on the client machine inside the network. Then I entered my external DNS name and set up RPC over HTTP. Connection failed.

I then installed an SSL certificate on the server for the internal DNS name. The client was able to connect through SSL(443) without ever having to go through port 135. A-HA!

So now that I've proved it's possible, I have to figure out why it doesn't work externally. I'm wondering if it is a DNS issue:

In this network, I have a client XP machine and the Exchange server with Windows Server 2003. Both are behind a D-Link router/firewall. The server only knows itself as server.exchange.local. For my external DNS name, I am using dyndns.org to forward a chosen DNS name to my external IP address. I don't know a whole lot about DNS, so I have to ask:

Doesn't the DNS service running on the server machine need to know anything about its external DNS name?

Here is my reasoning on why the RPC over HTTP connection only works internally:

1. Server has SSL certificate for external DNS name installed.
2. Outlook is configured to use external DNS name.
3. DynDNS forwards external DNS name to external IP address.
4. Router forwards request to server machine.
5. Certificate is for external DNS name, but server identifies itself as server.exchange.local (internal DNS name).
6. We have a certificate mistrust, and Outlook quietly hangs around and then says the connection cannot be established.

Another issue could be the fact that my router is NAT'ing IP addresses, though I can't really see why this would be a problem (NAT between internal and external IP should be seamless - server is in DMZ).

Hopefully this new information will help you guys a bit.. as always, your suggestions are appreciated.

 

[DJjEwing]

I have problems getting people from outside my network to connect to their exchange 2003 account using Outlook 2003 rpc over http. Inside my network rpc over http works fine. Its outside users that have given me a headache.

How do you prevent Outlook 2003 from using other ports, (i.e. 135 11xx.....). In my SonicWall firewall I have only ports 80 and 443 (http, https) open to my Exchange 2003 server. In the Sonicwall firewall logs, I see the firewall drops tcp connections from outside users that are using TCP ports 135 and 11xx. How do prevent outlook 2003 from using tcp ports 135, 11xx. How do you force outlook 2003 to use just tcp port 443. I can not have all my customers to ship their computers or laptops to our office in order to configure and setup their Outlook 2003 to use rpc over http. They have to do it from their remote locations.

 

[DJjEwing]

AndyPeck,

Please help us all, and teach us how to configure Outlook 2003 to connect to Excahnge 2003 server. What do need to look for and check to make sure that When outlooks connects to the excahnge server it does not use any other TCP port, except for port 443 (https). Do we have to make any Registry changes?

 

[DJjEwing]

Are we required to open additional ports in firewall, so that Outlook 2003 can connect to Exchange 2003. Besides, ports 80, and 443. what other ports are required to be open.

 

[DJjEwing]

Is it required for exchange server to also be a Global Catalog server. In my network I have two Windows 2003 Standard Edition servers.

Both Windows 2003 Standard Edition Servers are Domain Controllers. But only one of them is a Domain Controller and Global Catalog server. The Exchange 3003 Server is installed on the Windows 2003 Standard Edition server which is only a Domain Controller.

 

[AndyPeck]

Wow

This tread seems to have being going on forever.

I'm sure you've all seen this document

http://www.microsoft.com/downloads/...d-3710-49cf-9698-938e2bef39e8&displaylang=en.

The only thing I do in addition is regarding the SSL cert name and host header, and use a UPN name for the login that matches the users email address (but that's because I run hosted exchange)

I don't expect my users to remember the name of their exchange server for OWA access, so it's always webmail.company.com.

The cert common name is webmail.company.com, I setup the default site to have a host header of webmail.company.com and the MX record the same.

So the when setting up RPC I connect to webmail.company.com, regardless of it being internal or external (as the front end server lives in a DMZ).

DjEwing: With ExSP1 installed there are no Reg changes to make.
DjEwing: Our firewalls only have 25,80,433 enable for inbound traffic, however I follow

http://support.microsoft.com/default.aspx?scid=kb;en-us;555053

to redirect all the port 80 to 433 as I've change that my users will remember to type in HTTPS, it therefore save a ton of crap support calls
DjEwing: I would make my backend exchange server a GC,

 

[DJjEwing]

AndyPeck,

Thank you very much. I finnaly got rpc over http to work.
Your advice about making the backend Exchange server a GC did it for me. I owe you a big favor, so if you ever visit New York City, give me a call and I will take you out to lunch or dinner.