Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Can't get RPC over HTTP to work. 1

Status
Not open for further replies.

Haleon

IS-IT--Management
Feb 2, 2004
80
US
Hey guys, wondering if somebody here might be able to offer me a suggestion.

Our company recently upgraded to Exchange 2003 in hopes of using the new RPC over HTTP protocol with our WinXP/Outlook 2003 remote employees. I upgraded our Exchange 2000 box to Exchange 2003 (with Windows 2003) and then upgraded one of our domain controllers to Windows 2003. The second domain controller is still Windows 2000. I turned off the option to make the second domain controller a global catalog (since I read that all global catalogs on the domain have to be Win2k3). So I have an Exchange 2003 box running Windows 2003 using a Windows 2003 domain controller set up to be the sole global catalog in the domain.

I went through the RPC over HTTP deployment guide, and I think I followed all the steps correctly. I set up the RPC proxy server on the Exchange 2003 box, set the registry entries as according to the deployment guide, and then opened up TCP ports 6001-6004 inbound and outbound on our company firewall. I also installed a privately issued SSL certificate on the Exchange box.

I set up my Outlook profile (behind the firewall) to connect to the Exchange server using RPC over HTTP, and all seems well. When I hold down ctrl and right click the Outlook icon in the taskbar and check the connection status, it says that all my connections are routed over HTTPS.

The problem is when external clients attempt to connect, it just doesn't work. I get the Exchange Server Unavailable message, and I can't figure out why. I was hoping somebody here might be able to offer me a pointer.

As a little aside, I don't know if this means anything, but the actual NetBIOS name for the exchange server is different from the name that is used to access the server from the internet. I don't think that makes a difference, but I thought it would be worth pointing out. Anybody with any ideas?
 
It is pretty likely to be a certificate issue, especially if the FQDN externally is different to the FQDN internally.
 
Let me clarify, the certificate issued to the Exchange server does use the FQDN of the internet address used to access the box. The certificate is issued to mail.ourcompanyname.com, and that's the address that clients use to connect to the mail server. It's just that the actual name of the server isn't mail. So I'm pretty sure the certificate is set up correctly. I mean when I go to Exchange Web Access over SSL, I can view and accept the certificate, and the SSL works properly.
 
Have you installed the root certificate on the client system?

You can't just have the cert installed on the server, it needs to be installed at the client side.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at
 
I'm not really sure. I've gone to the Outlook Web Access site using SSL and accepted the certificate there. Is there more than that I need to do? How would I go about manually installing the certificate client-side? Sorry, but I'm kind of a newb when it comes to this stuff. Learning as I go and all that... I appreciate your help.
 
Are you talking about from outside the internal network? I just tried that from outside the network and got the page can not be found message.
 
The issuing authority is a domain controller within our domain. It issued a certificate to the Exchange server.
 
Maybe I'm ignorant here, but when a client connects to the Outlook Web Access site and installs the certificate associated with our mail server, isn't it also installing the certificate for the trusted root authority that issued the certificate? Since the client trusts the certificate issued to the mail server, they also trust the authority that issued the certificate, right?
 
Mark, I just wanted to say that your advice helped solve my problem. Because the issuing CA was internal, external clients not part of the domain did not have that CA listed as a trusted root CA. I exported the certificate and had the clients import it, and as soon as I did that the connection started to go through. Thanks again for all your help.
 
I found this thread very interesting, because I am having the same problem. I have an FE in a DMZ on my firewall and the BE on the LAN. If I connect a laptop while on the LAN it works great, I can even bring that laptop home and it works great. If I try to make the initial connection form home it fails miserably.

I initially thought it was a cert issue, but i followed the instructions form Comodo to update the CA but it is still not working. (then again they are cheap ass certs)

All DCs / GCs are 2003

Can anyone think of something i may have missed?
 
Jim, Comodo doesn't show up in my list of trusted root certification authorities. Are you sure that you've imported the Comodo certificate onto each laptop that you wish to access the Exchange server externally from?
 
It is actually an intermediate cert, the root cert is GTE Cybertrust.

I downloaded the root certificate update from their site and it does list Comodo as an intermediate and GTE as a root. I have no problems at all when accessing the OWA page.
 
Problem solved!!! It was my dumbass mistake

I followed the instructions from msexchange.org because they have pretty little step by step pictures. The problem is there is a mistake. They say that when entering the name of the server in the "Exchange Server Settings" requires you to use the fqdn on the cert. In fact I need to use the internal name of my mail server.
 
Glad you got the problem solved, Jim! Yes, you are right that the Exchange server name has to be the internal netbios name of the mail server. Just remember that when you configure the Exchange over the Internet settings on the connection tab, use the FQDN (the external name) of the mail server there.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top