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!

 

[anonim1]

Okay.. I appreciate all of the suggestions, unfortunately, my system is STILL not working.

Regarding stikman's post: There are no places in either the client or server configurations where I am using the external DNS name; I have server.exchange.local as the FQDN everywhere. I wish it was such an easy fix for me.

Regarding DrBobKnows's observation: This is interesting. However, I couldn't get the same results as you.

In my network, I have one PC running XP and one PC running Server 2003 and Exchange 2003. The client machine is not a member of the server domain. If I set the client machine to use the server machine as the DNS server, it resolves server.exchange.local to the server machine and attempts to connect to it on port 135. If I set the client machine to use my router as the DNS server, it comes up immediately and says that server.exchange.local cannot be found (as expected).

I can succesfully connect Outlook to the Exchange server over TCP/IP using port 135 (MAPI-based profile). If I then go back and re-configure this profile to use RPC over HTTP, it still connects over port 135. If I block port 135, it can't connect at all.

I've gone through all of the tutorials and Microsoft support pages, and I confirm that all of my settings are correct. At this point, I am almost ready to have an Exchange specialist remotely connect to my machines and help me figure this out (no idea what this would cost).

I appreciate any further comments you guys may have..

 

[DrBobKnows]

anonim1;

I gave up for now and used PPTP with a filter. What put the kibosh on my going forward at this time is the fact that if you follow the proceedure for single server configuration you need to make a registry entry on the GC server that requires a registry data type that is not supported in Windows 2000 which is where my domain controllers are and the GC.

In your case I would caution setting up Excahnge on a domain controller. Once a 2003 machine is promoted to a DC the security of the machine is increased to the point that you will have lots of problems getting things working properly. Hence my situation with the 2000 DC's. I will need to get a separate 2003 DC up and running before I proceed any further. Also I have signed up as a MS Hosted Excahnge Partner to deliver Hosted Excahange and I'm certain this will help in the learning curve.

I would like to suggest that if you are not using WINS that you install WINS on your server and configure your client PC AND your server network connections to use your WINS server. WINS is like DNS only it supplies additional network / domain information that a DNS server can not.
Note that when the SSL is connected to your server, the connection to 'server.exchange.local' is through the SSL. In my case I also went out a purchased a SSL cert for the virtual RPC (IIS) server. You must have a SSL cert. You must use Basic Authentication in the Proxy settings.

Give WINS a try and let us know.

 

[anonim1]

DrBobKnows,

Can you tell me about the registry entry you mentioned in your previous post? I may have missed over that setting.

Security is not a big issue in my case; there are no machines which are members of a domain. I have two machines in my home network: my PC (set up as a workgroup machine), and the server with Server 2003 and Exchange 2003 (set up as a DC). Both are behind the router's firewall.

I installed WINS server and added a record for my PC. I then configured TCP/IP settings on the PC to use the server machine as the WINS server. Since I am not using the DC as my DNS server, I added an entry in my HOSTS file to associate the DC's FQDN with its IP address. This way, I can ping server.exchange.local and have it resolve to its IP even though my router's DNS knows nothing about server.exchange.local. Before the HOSTS entry, server.exchange.local would not resolve.

At this point, I can still connect to the Exchange server over TCP/IP. If I enable RPC over HTTP, there is good news: I only see packets going to port 443, not to port 135 anymore. However, I keep getting the Login box over and over as if incorrect credentials are being used.

I feel like I am finally making some progress.. anymore suggestions?

 

[stikman]

Hi anonim1

Just to confirm that i have this working on both an SBS site & Server 2003 standard site.

In the proxy setting of the Outlook client it MUST be the DNS name if you are going to attempt a connection from the internet.

If you are testing within you LAN then you must ensure you have the appropriate DNS entry (if not using a .local DNS)

I have only port 443 open on the firewall for this connection.

The registry entry I posted in important.

I have a site with "Purchased" and one with "SelfGenerated" SSL certificates.

 

[anonim1]

Well, I was right about the credentials. I was not supplying the correct credentials. When I entered them as username and password, it assumed I was trying to authenticate as a user of the local machine.

I then tried entering the username as EXCHANGE_SERVER_DOMAIN_NAME\username, and voila! I was able to connect immediately with HTTPS.

Now that I have it working internally, I would like to make it work externally.

I have removed the certificate for server.exchange.local and have added a new certificate for my public internet DNS name. My public DNS name is an alias that I am using through dyndns.org, which points at my static IP address.

I've put the server machine in the DMZ for testing purposes, but I still cannot connect from outside the network. Here is what I have for HKLM\Software\Microsoft\Rpc\RpcProxy\ValidPorts:

server:6001-6002;server.exchange.local:6001-6002;server:6004;server.exchange.local:6004;

Do these also need to be changed to reflect my external DNS name, or should they stay the same? Where else do I need to change my internal DNS name to my external DNS name?

Of course, I am using the external DNS name from the Outlook client configuration.

Thanks for all the help guys, the hard part is over! Just a little more help..

 

[AndyPeck]

Q , Do these also need to be changed to reflect my external DNS name
A. No...
If you install EX2003 SP1, there is now a setting under RPC-HTTP in server properties to configure the server as RPC proxy, this will take care of the setting you are talking about

Remember if you are moving this server into the DMZ, it must still be able to contact the Domain controller.


Install the cert on the default web site, add the certs name.domain.com to in the host header section of IIS.

The article below is quite good if your interest in knowing how to have all http requests redirected to HTTPS
How to: Redirect an HTTP connection to HTTPS for Outlook Web Access (OWA) in Exchange 2003 Server

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

 

[anonim1]

Andy,

Exchange 2003 SP1 was installed immediately after installing Exchange 2003 Server. Under the RPC-HTTP tab of my server, I have it configured as a RPC-HTTP back-end server. This is the correct setting for a single server Exchange setup.

The Exchange server is also the domain controller, so no problems there with them not being able to contact one other.

I have the certificate installed on the default website. I am not sure what you mean by add the certificate name in the host header section of IIS? Can you explain?

The auto-redirect article is good, I've actually done the same thing on one of our web servers here at work.

I know that the certificate trust issue is very big when it comes to RPC over HTTP. I am worried that, even though my certificate is for name.domain.com, once the Outlook client reaches my Exchange/RPC server, the server identifies itself as name.domain.local. Is this possible? If so, there would be a certificate mistrust issue, which would explain why I cannot connect from outside the network.

I'm also wondering whether I could use the following setup:

- Install the certificate for name.domain.local
- Add an entry in the HOSTS file of all client machines to map name.domain.local to its IP address
- Configure Outlook to connect to name.domain.local rather than name.domain.com

Would this work? Any other ideas?

 

[AndyPeck]

Anonim

Are you saying your SSL is named for you internal domain name rather than your internet domain name ?

 

[anonim1]

I'm gonna assume that by saying SSL, you are referring to the server certificate.

The answer is no. It is currently named for my internet domain name. However, I cannot connect via RPC over HTTP from outside my network. Therefore, I'm wondering if I should use a certificate for my internal domain name and add an entry in the client's HOSTS file to associate the internal domain name with the external IP address. This is all assuming that the problem lies with the certificate. If not, I don't know what else it could be...

 

[jeffwadsworth]

anonim1:

I have this setup working and you apparently have a bad configuration on your RPC-HTTP tab. For a single server, you are supposed to have "not part of an exchange managed topography" selected, not the backend one. You may want to recheck this on your side.

 

[anonim1]

jeffadsworth,

Please point me to the resource where you see that the server should be configured as being "Not part of an Exchange managed RPC-HTTP topology".

Here is the Microsoft article which states that, for a single server setup, you must select the option "RPC-HTTP back-end server".

http://www.microsoft.com/technet/pr...Dep/1583ab17-f7d1-41c1-ba52-37ec276e3644.mspx

Scroll down about 3/4 of the way down the page and look for the section entitled "Configuring an Exchange Server 2003 SP1 Single-Server Installation to Use RPC over HTTP". Just like it says, this is for Exchange 2003 with Service Pack 1 installed. If you do not have SP1, then your configuration may be different.

 

[anonim1]

I think I've determined the problem. I hope I'm wrong, but somehow I doubt it. I have everything working perfectly inside my network, so I decided to do it all over again one step at a time and try to diagnose the problem.

I configured my Outlook client to connect to my external DNS name, and I blocked all outgoing connections to port 135. I started Outlook, it sent some packets to 135 (which were blocked) and 443, then came back and told me that the server was unreachable.

Next, I removed the port block rule and started Outlook again. Right away, it asked me for the username/password, which I entered. Immediately, it sent packets to 135, 443, and 88 (Kerberos), and then the Connection Status window showed me that I was connected via HTTPS.

Now having set up the profile, I enabled the port 135 block again and tried to connect. Sure enough, it connected without any issues over port 443.

So, my understanding is that for whatever reason, the connection must be made over port 135 before HTTPS will work. This seems ridiculous considering that the whole point of RPC over HTTP(S) is due to port 135 being blocked.

Can someone please prove me wrong?

 

[anonim1]

Okay, so I proved myself right. Profile MUST be created over RPC (135) before you can connect via RPC over HTTP(S).

I dug up some old articles where it was recommended to use profgen.exe to create the profiles for RPC over HTTP. Unfortunately, I am having hell of a time finding this utility. I found the link for Exchange Server All-In-One Tools Download, but it does not include the profgen.exe utility. Has it been replaced by something else? Is it no longer supported on Exchange 2003?

Anyway, I think we can put this topic to rest. It has lasted long enough.. I will let you guys know if I am able to create the profiles using profgen or another utility.. this is the only other option!

Thanks for all your help.

 

[jeffwadsworth]

hehe. Okay, first of all, you must connect and configure your email clients on your local network before trying to connect via https. It will NOT work if you do not follow this basic step. The document you are referring to is incredibly inadequate. The steps involved in getting this thing working came from no less than 5 separate documents. Do you even have your certificates configured to accept "secure email"? Tomorrow morning I will find relevant links to this setup. BTW, the setting I told you about is correct. I have SP1 for Exchange 2003. In fact, it needs to be installed for the RPC-HTTP tab to show up. Why close the thread with no resolution, no matter how long it runs? Stay tuned.

 

[anonim1]

I have no problem keeping the thread open! I'm sure that it will benefit a lot of other folks who are having similar trouble setting up RPC over HTTP with their Exchange servers.

You're right, that document does not cover all the steps required to configure RPC over HTTP. I've used a combination of articles to set it up. Here are just a few:

How to configure RPC over HTTP on a single server in Exchange Server 2003

http://support.microsoft.com/?id=833401

Exchange 2003 RPC Over HTTP Configuration

http://www.kuhnline.com/files/Exchange2003RPC-over-HTTP.zip

How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003

http://support.microsoft.com/kb/827330/en-us

I am only using one SSL certificate, and it does not have any limitations on it as to what it can be used for (webserver, email, etc.)

I think the RPC-HTTP tab under Exchange System Manager shows up as a result of installing RPC over HTTP in Windows Server 2003. I don't understand the logic of being able to use RPC over HTTP with Exchange if you configure the server as being "Not part of an Exchange managed RPC-HTTP topology".

 

[jeffwadsworth]

Okay. For starters anonim1, read this:

http://support.microsoft.com/?scid=...cedesks/webcasts/en/transcripts/wct061604.asp

In this document, the presenter explains the rpc-http tab addition and the "not part of an Exchange managed rpc-http topology" setting for a single server enviroment.

Essentially, they will make it easy to set up if you implement their front-end back-end deal...an expensive proposition. I have a single Exchange 2003 SP1 box and I can tell you that it works fine in it. Just takes a bit of hacking to get it there.

First question: Have you verified the "advanced" settings on your server issued certificate? Make sure it has "client authentication" and "secure email" checked.

 

[AndyPeck]

Jeff.

Regarding your comments on the configuration of clients requiring to be on the local LAN to be setup correctly.

I manage serveral thousand hosted mailboxes, with 95% of the connections via HTTPS over RPC. No one, but no one FedX's their pc or laptop over to me so I can plug it in the local lan for a quick config before sending it back.

You have been misinformed

 

[anonim1]

jeff,

I am using a 15-day evaluation certificate from VeriSign. On the certificate, it says the certificate is intended for the following purposes:

Ensures the identity of a remote computer
Proves your identity to a remote computer

I have the option to install and use the Certificate Authority to install my own certificate, though I can get RPC over HTTP to work just fine from inside my LAN using this certificate.

Andy,

If what you're saying is the case, why am I only able to establish the HTTPS connection after the initial configuration over RPC? Does that mean that something is not configured properly? If true, then HTTPS should not work at all right?

 

[jeffwadsworth]

Andy...the client computer must have the certificate installed. The certificate is installed by joining the domain. Are you telling me that your remote clients are not joined to your AD domain?

Anonim1: Okay, to check the settings on that certificate, open your IE 6 browser and select "Tools" -> "Internet Options" -> "Content" tab -> "Certificates" button -> "Trusted Root Certificates" tab

Look for the server named certificate and after selecting it, click the "advanced" button. Make sure everything is checked.

 

[anonim1]

jeff,

Joining the domain is not the only way to install a certificate. When the user visits the website with the certificate, if the certificate issuer is not in the client's Trusted Root Certificate Authority group, the user is asked how to proceed. From this point, the user simply has to save the certificate and then import it into their TRCA group.

Client Authentication and Secure Email were not checked under my certificate issuer's properties. I enabled them and tried the RPC over HTTP connection again, but no success.