bleujaegel
asked on
Trying to setup RPC over HTTP
I am attempting to setup RPC over HTTP, and have questions regarding the correct way to set this up for my scenario.
I am running a Windows Server 2003 computer as the AD/DNS server, and a Windows Server 2003 computer running Exchange 2003 with SP1. The Exchange server is running as a Backend server only (no front end). They are both using private IP's, however, DNS is setup externally (GoDaddy) to point to the internal domain. I other words, outside = mydomain.com, inside = mydomain.local. I have read this should work if you can ping the public hostname of the Exchange server from outside (for example exch.mydomain.com).
I've read that there must be a Global Catalog server available, and the AD serves that purpose.
1.) I am not sure which computer to install the RPC over HTTP proxy service. Should it be on the Exchange server or DC?
2.) I have enabled SSL on the RPC virtual directory. In addition, I set the Authentication to basic and set the default domain to mydomain.local (not sure if that's right, should it be mydomain.com?).
3.) There is a virtual directory named RPCWithCert. Is this the one that is used for SSL, or just the RPC one?
From the client computer, when I open Outlook, but before logging in, I check the connection status and see:
exch.mydomain.com Referral Https Connecting
As soon as I log in, the connection is exclusively TCP/IP. I tried closing all ports but 80 and 443, but then I couldn't connect at all. Nothing shows up in either server's event viewer logs. Basically, I've tried setting this up in several different configurations, and am having no luck. Any help would be appreciated.
I am running a Windows Server 2003 computer as the AD/DNS server, and a Windows Server 2003 computer running Exchange 2003 with SP1. The Exchange server is running as a Backend server only (no front end). They are both using private IP's, however, DNS is setup externally (GoDaddy) to point to the internal domain. I other words, outside = mydomain.com, inside = mydomain.local. I have read this should work if you can ping the public hostname of the Exchange server from outside (for example exch.mydomain.com).
I've read that there must be a Global Catalog server available, and the AD serves that purpose.
1.) I am not sure which computer to install the RPC over HTTP proxy service. Should it be on the Exchange server or DC?
2.) I have enabled SSL on the RPC virtual directory. In addition, I set the Authentication to basic and set the default domain to mydomain.local (not sure if that's right, should it be mydomain.com?).
3.) There is a virtual directory named RPCWithCert. Is this the one that is used for SSL, or just the RPC one?
From the client computer, when I open Outlook, but before logging in, I check the connection status and see:
exch.mydomain.com Referral Https Connecting
As soon as I log in, the connection is exclusively TCP/IP. I tried closing all ports but 80 and 443, but then I couldn't connect at all. Nothing shows up in either server's event viewer logs. Basically, I've tried setting this up in several different configurations, and am having no luck. Any help would be appreciated.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
And also change the default domain to /
ASKER
In my configuration (Separate Exchange and Domain Controller), is it correct to set the RPC-Http setting to back end only?
I tried the registry changes without success. I went through the client configuration, and the only thing different on my setup vs. your website is that the first screen I had 'exchang.mydomain.com' as the exchange server instead of just 'exchange'. This had no effect.
I just tried changing the RPC virtual directory default domain to \ with no change.
I can ping host no problem, but trying to connect remotely via laptop is still unsuccessful. Running outlook.exe /rpcdiag gives me:
-- Directory -- Connecting
exchange.mydomain.com Referral -- connecting
I tried the registry changes without success. I went through the client configuration, and the only thing different on my setup vs. your website is that the first screen I had 'exchang.mydomain.com' as the exchange server instead of just 'exchange'. This had no effect.
I just tried changing the RPC virtual directory default domain to \ with no change.
I can ping host no problem, but trying to connect remotely via laptop is still unsuccessful. Running outlook.exe /rpcdiag gives me:
-- Directory -- Connecting
exchange.mydomain.com Referral -- connecting
what happens when u try to browse the rpc virtual directory in IIS after unchecking the require SSL.
1. Just for a test purpose uncheck the require SSL. restart the website.
2. Rightclick the RPC VirDir and chosse browse.
1. Just for a test purpose uncheck the require SSL. restart the website.
2. Rightclick the RPC VirDir and chosse browse.
ASKER
That had no effect. The interesting thing is that I am not able to connect via TCP/IP from the LAN if I use the FQDN of exchange.mydomain.com, but if I use exchange.mydomain.local, I have no problem. I cannot get HTTP/S to work locally with this configuration. I'm not sure if this is a conflict attempting to use .com and .local for external/internal name, or I just have the server misconfigured. The client seems as though it's properly configured. It's running SP2 and Outlook 2003.
I also noticed that the DC shows up in the Connection Status window when connecting locally (.local domain). It doesn't show up at all when trying to connect remotely with the client configured to point to the .com Exchange server. Is the client supposed to show the DC name/IP when connecting remotely? Maybe this is the source of the problem.
I also noticed that the DC shows up in the Connection Status window when connecting locally (.local domain). It doesn't show up at all when trying to connect remotely with the client configured to point to the .com Exchange server. Is the client supposed to show the DC name/IP when connecting remotely? Maybe this is the source of the problem.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok, that sounds like my problem. I was thinking that if I could ping the host name externally, that should be sufficient. I'll give it a try. Thanks for the info!
ASKER
I have a question regarding split dns.
Would it be correct to say that I need one DNS server directly connected to the internet, and another connected to the LAN? I currently only have 1 DNS server using 1 private IP, so I'm guessing split brain can't work this way. I actually configured my DNS hosts on my registrar's website to point to the Exchange server. Is this a problem?
If I can ping from an external host to exchange.mydomain.com and receive the WAN ip, what could break RPC if I have port 80 & 443 forwarded to the exchange host? It seems as though the traffic should go directly to the server. I have verified the registry entries again on the DC and Exchange server.
Would it be correct to say that I need one DNS server directly connected to the internet, and another connected to the LAN? I currently only have 1 DNS server using 1 private IP, so I'm guessing split brain can't work this way. I actually configured my DNS hosts on my registrar's website to point to the Exchange server. Is this a problem?
If I can ping from an external host to exchange.mydomain.com and receive the WAN ip, what could break RPC if I have port 80 & 443 forwarded to the exchange host? It seems as though the traffic should go directly to the server. I have verified the registry entries again on the DC and Exchange server.
You need to have a DNS server connected to the internet - but it doesn't have to be yours.
What split-dns does is provide a response based on the location of the client.
When you are on the local LAN, the DNS server is your domain controller, so you can give a local response.
On the Internet, the DNS will be an internet based server, which will do the lookup, find your public DNS server (hosted by your ISP, domain name registrar etc) and then get the public IP address back.
The problem with getting the external IP address back when internal is that most firewalls/routers will not allow traffic to go back on itself. It is expecting traffic to come in, not to go out and then try and come back in on the same interface.
What you need is for exchange.domain.com to resolve to 192.168.1.5* internally and 123.456.789.123* externally (where * is your actual IP addresses).
Simon.
What split-dns does is provide a response based on the location of the client.
When you are on the local LAN, the DNS server is your domain controller, so you can give a local response.
On the Internet, the DNS will be an internet based server, which will do the lookup, find your public DNS server (hosted by your ISP, domain name registrar etc) and then get the public IP address back.
The problem with getting the external IP address back when internal is that most firewalls/routers will not allow traffic to go back on itself. It is expecting traffic to come in, not to go out and then try and come back in on the same interface.
What you need is for exchange.domain.com to resolve to 192.168.1.5* internally and 123.456.789.123* externally (where * is your actual IP addresses).
Simon.
ASKER
I think I have DNS setup properly then. I created the mydomain.com zone, and when I ping exchange.mydomain.com, I get a 192.168.1.3 reply. When I ping exchange.mydomain.com from a remote client, it goes to Godaddy to get my external IP, then should be forwarded to 192.168.1.3 on ports 80 and 443.
My host records for mydomain.com are:
exchange A 192.168.1.3
exchange A 123.456.789.123 (external)
ns1 A 192.168.1.2 (DC/DNS)
SOA & NS are both pointing to ns1.mydomain.com
I did put an MX record pointing to exch1.mydomain.com (even though you said it wasn't required on your website, I'm assuming it's still ok).
One additional point to mention. When I connect to the LAN and attempt to check the email account settings, the Exchange Server name changes to exchange.mydomain.local when I click on 'Check name'. I would think it should stay as 'exchange.mydomain.com' whether on the LAN or from the WAN so it would work consistenly without having to change settings all the time. It seems to be pulling this from the Exchange server, even after I deleted all references to Exchange from the .local zone. If I ping this address, it fails, so I verified it does not exist.
My host records for mydomain.com are:
exchange A 192.168.1.3
exchange A 123.456.789.123 (external)
ns1 A 192.168.1.2 (DC/DNS)
SOA & NS are both pointing to ns1.mydomain.com
I did put an MX record pointing to exch1.mydomain.com (even though you said it wasn't required on your website, I'm assuming it's still ok).
One additional point to mention. When I connect to the LAN and attempt to check the email account settings, the Exchange Server name changes to exchange.mydomain.local when I click on 'Check name'. I would think it should stay as 'exchange.mydomain.com' whether on the LAN or from the WAN so it would work consistenly without having to change settings all the time. It seems to be pulling this from the Exchange server, even after I deleted all references to Exchange from the .local zone. If I ping this address, it fails, so I verified it does not exist.
The changing of the name on check name is correct. It doesn't affect the operation of this feature.
What I always tell people to do is configure Outlook in the normal way and verify that it works.
Then ADD the RPC over HTTPS settings, without changing anything else. It should then continue to work. Expecting to see the external name as the Exchange server is very common.
Simon.
What I always tell people to do is configure Outlook in the normal way and verify that it works.
Then ADD the RPC over HTTPS settings, without changing anything else. It should then continue to work. Expecting to see the external name as the Exchange server is very common.
Simon.
ASKER
I have no problem on the LAN. It connects every time via TCP/IP. I have successfully setup both OWA and OMA with SSL to work via LAN and WAN, so I don't think it's necessarily a certificate issue. It was a free certificate, however the CA isn't trusted by default. I have to install a CA cert on the clients. RPC over HTTP doesn't work via HTTP or HTTPS. Locally, I only see TCP/IP mentioned. Never HTTP or HTTPS. When I connect remotely, I do see the computer attempting to connect via HTTP/S. I always get a Windows login box that at the top has 'exchange.mydomain.com' listed. No matter what I enter > mydomain\username, exchange.mydomain.com\user
I think I might try another client computer to see what happens. I am running XP SP2, with Outlook 2003 (no SP's installed). Is there a fix that you know of that's not included with either?
I think I might try another client computer to see what happens. I am running XP SP2, with Outlook 2003 (no SP's installed). Is there a fix that you know of that's not included with either?
You are leaping ahead too quickly.
You need to get it so that https works on the LAN. Until you do, you don't know if it is working or not, for example whether something is blocking the traffic.
I also have a very low success rate with self signed certificates. I do all of my production level deployments using a commercial certificate, usually one from RapidSSL.
You should also install the service packs for Office. While there are no changes that I can think of in the service packs, being two versions back on service packs is not a good idea.
Simon.
You need to get it so that https works on the LAN. Until you do, you don't know if it is working or not, for example whether something is blocking the traffic.
I also have a very low success rate with self signed certificates. I do all of my production level deployments using a commercial certificate, usually one from RapidSSL.
You should also install the service packs for Office. While there are no changes that I can think of in the service packs, being two versions back on service packs is not a good idea.
Simon.
ASKER
I purchased a Godaddy SSL certificate and installed it. Still same problem. I'm doing what you suggested, and working on ony the LAN side for now. I've verified network connectivity between all hosts. Here is the result of rpccfg on the Exchange server:
exchange 100-5000 593 6001-6002 6004
exchange.mydomain.com 593 6001-6002 6004
exchange.mydomain.local 593 6001-6002 6004
ns1 (DC) 593 6001-6002 6004
ns1.mydomain.local 593 6001-6002 6004
I've verified the single entry on the DC as well.
I downloaded the service packs for Outlook 2003, however it continues to use only TCP/IP as the protocol. I've changed every setting I can think of in multiple combinations without success. I've configured the client just as every tutorial I've read suggests... Any other ideas?
exchange 100-5000 593 6001-6002 6004
exchange.mydomain.com 593 6001-6002 6004
exchange.mydomain.local 593 6001-6002 6004
ns1 (DC) 593 6001-6002 6004
ns1.mydomain.local 593 6001-6002 6004
I've verified the single entry on the DC as well.
I downloaded the service packs for Outlook 2003, however it continues to use only TCP/IP as the protocol. I've changed every setting I can think of in multiple combinations without success. I've configured the client just as every tutorial I've read suggests... Any other ideas?
If you browse to https://servername.domain.com/rpc (where servername.domain.com is the name on the SSL certificate).
Simon.
Simon.
ASKER
I am able to browse to https://exchange.mydomain.com/rpc from a remote client. It shows the directory, which contains the rpcproxy.dll file.
I'm wondering if I should just uninstall/reinstall Exchange, and try from scratch setting up RPC/HTTP. I have a feeling it's an issue with an IIS virtual directory, since OWA and OMA seem very sensitive to any changes. I had made a change days before that for whatever reason I could not get OWA working, even though I changed the settings back to exactly what they were. Fortunately, I had backed up IIS and could revert to it.
I'm wondering if I should just uninstall/reinstall Exchange, and try from scratch setting up RPC/HTTP. I have a feeling it's an issue with an IIS virtual directory, since OWA and OMA seem very sensitive to any changes. I had made a change days before that for whatever reason I could not get OWA working, even though I changed the settings back to exactly what they were. Fortunately, I had backed up IIS and could revert to it.
ASKER
I finally got it working. I didn't do anything I hadn't tried before. I was tweaking the IIS Virtual Directory Authentication settings, and it started working. I'm stumped. It's working great locally and remotely, no problems.
I did remove the new Godaddy cert, and reverted to the StartCom.org free cert I had originally, and it worked fine. I also took a screen capture of EVERY page of the virtual directories for future reference. Now OWA, OMA, and RPC are all finally working.
Anyway, thanks to both of you for your assistance!
I did remove the new Godaddy cert, and reverted to the StartCom.org free cert I had originally, and it worked fine. I also took a screen capture of EVERY page of the virtual directories for future reference. Now OWA, OMA, and RPC are all finally working.
Anyway, thanks to both of you for your assistance!
The only sub directory that is used is /rpc - the others are not currently used.
Have you made the registry changes? You have to do these by hand.
Are you using a purchased or self signed SSL certificate?
Does it work inside? My number one rule for checking this feature is to get it to work inside first. Do not even attempt to get it to work outside until you know it works inside.
You may want to look at my web site, where I have a lot of information on setting up this feature: http://www.amset.info/exchange/rpc-http.asp
Simon.