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!

 

[AndyPeck]

Can you confirm that your Outlook 2003 client is configured to use HTTP First and Fast & Slow networks (in exchange proxy settings)and you've also selected Basic Auth

You can (crtl)right click the outlook icon in the sys tray and select connection status and watch it try setting up the comms.

I'm assuming you've dropped a PC into network B and checked it works from there...

 

[anonim1]

Andy,

I have both checkboxes checked and am using Basic Authentication, with SSL enabled on the server-side.

Actually, I cannot connect to it from a PC with Outlook 2003 in network B. I create a new profile, set up Microsoft Exchange Server as the only account on the profile, and then configure the RPC over HTTP settings. I see packets going from the PC to ports 135 and 443 of the server machine. After a while, it tells me that the connection to the Exchange server is unavailable. Why oh why does it insist on connecting to 135?

 

[anonim1]

Here is something interesting.. I ran rpcdump.exe from the Windows Resource Kit Tools to troubleshoot RPC over HTTP and got the following:

D:\Program Files\Windows Resource Kit Tools>rpcdump /P:ncacn_http
Querying Endpoint Mapper Database...
0 registered endpoints found.

rpcdump completed sucessfully after 1 seconds

D:\Program Files\Windows Resource Kit Tools>

The ncacn_http protocol is "Connection-oriented TCP/IP using Microsoft Internet Information Server as HTTP proxy."

Does this mean that the RPC over HTTP is not listening for connections? Does anyone mind running this utility on their server if they have RPC over HTTP running and let me know what the result is?

 

[AndyPeck]

If you cannot connect via rpc over https on the server segment, I suspect RPC is not setup as required.

Check out this article to make you settings are correct

http://support.microsoft.com/default.aspx?scid=kb;en-us;833401&Product=exch2003

Also checkout this one, just in case

http://support.microsoft.com/kb/826486

 

[athelu]

just wondering...

you MUST have a front-end back-end environment for RPC over http.

You have to install the RPC over HTTP service on the front end server. Then check the box inside of ESM to indicate the RPC server, then check the box on the Back-end server indicating it is a destination server.

you must then configure the RPC service inside of IIS on the front-end box.

when you configure the client computer to connect, you have to put the name of the BACK-END server in the exchange server box (not the front end). Also, make sure you have the principal name of the target machine as msstd:exchangefrontend.com.

also, you must change the drop down on the exchange proxy setting page to BASIC authentication only.

 

[anonim1]

athelu,

I have a single machine with Windows Server 2003 and Exchange 2003 on it. It is configured to function as a global catalog server, an Exchange computer, and an RPC proxy server. This is possible per the Microsoft article at

http://support.microsoft.com/default.aspx?scid=kb;en-us;833401&Product=exch2003.

So after I regained some of my patience, I fiddled around some more with the server. I removed the SSL/HTTPS requirement for the RPC virtual directory. I then configured Outlook to use RPC over HTTP (not HTTPS). When I started Outlook, it actually seemed to be communicating with the server. I was not seeing any requests to port 135 anymore, only port 80 (HTTP). Unfortunately, I still could not log in to my Exchange account because Outlook does not allow you to use Basic Authentication with HTTP.. so I had to set it to NTLM Authentication, and I believe this is the reason why it could not authenticate with the Exchange box.

However, all of the tests that I've performed to test SSL were valid, so I don't know what the problem is. Is there a way to set up RPC over HTTP over port 80 (I know this is unsafe - it is just for testing purposes)? Outlook forces me to give an HTTPS URL as soon as I select Basic Authentication.

Thanks.

 

[AndyPeck]

In response to athelu

We have several customers, who host single box Exchange solutions with us. All run RPC over HTTPS.
It ain't pretty... but is works.

anonim1

Is the SSL cert your testing with a self cert or one you've paid for from the likes of tharte & versign.
I'm interested to know, if the SSL is installed on the OWA site, whether you get a warning box up complaining about something as you browse the site.

 

[anonim1]

AndyPeck,

I've created the SSL certificate using the Certification Authority built into Server 2003. I have applied it to the OWA virtual directories, and I do get a warning box from the client's web browser saying that the certificate has been issued by a non-trusted source. However, you have the option to view the certificate and decide whether you want to accept it one time, accept it permanently, or reject it. Upon accepting it, I can view my Exchange account through OWA using 128-bit SSL. This leads me to believe that my RPC over HTTP is not really a SSL problem, but there should be a way to set it up without using SSL...

 

[DebO]

I had a similar issue at a client last week. We tried without SSL with no success and decided to obtain a certificate from Verisign. The problem with authentication still happened.

We then contacted Microsoft Product Support. We had originally installed RPC Proxy on the Front End Server, then applied SP to Exchange. Product Support had us remove the RPC Proxy service, reapply the Exchange Service pack, then reinstall RPC Proxy server. Once we did this life was GRAND! Hope this helps.

Deb Onderko
MCSE, MCT, CNE, CNI

 

[anonim1]

That is interesting.. this is the order that I performed the installation:

Format HD
Windows Server 2003
Windows Server 2003 Updates
Exchange 2003
Exchange 2003 SP1 and Updates
RPC over HTTP

So, unfortunately, your solution does not apply.. any other ideas?

 

[DrBobKnows]

I'm having this problem connecting as well.

I thought this was interesting quote from

http://www.microsoft.com/technet/pr...Dep/f09c9e31-9100-4009-81cf-a753310b2623.mspx

Install Windows Server 2003

To use RPC over HTTP, you must install Microsoft® Windows Server™ 2003 on the computers that are running Exchange Server 2003, and on the global catalog servers that your Exchange servers will access.

because I'm using a Windows 2003 server to host the exchange server and a Windows 2000 domain controller. Currently my GC is on the 2000 server. Can anyone confirm if having the GC on a 2000 server is a a problem?

The odd thing I've noticed in my case is that the listing from a netstat -n on my exchange server shows for some reason that the server is connecting to port 6004 on itself. I would expect this port would be opened to the client?!

Also the web server logs show the rpc dll running with a result code of 200 which I believe to be a good sign.

I also installed in the order that Deb indicated and followed the MS support's suggestion for a re-install however it did not help. As I'm working remotely I will try a reboot tomorrow as well to see if that helps after trying almost everything in this thread.

 

[AndyPeck]

anonmi

Don't dismiss the SSL as the issue yet,

Quote
If you receive a message that states that the certificate was issued by a company that you have not chosen to trust, your client computer is not configured to trust the root certification authority that issued the certificate. This behavior typically occurs when you do not configure the RPC proxy server to use a third-party certificate.


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

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

 

[anonim1]

Okay, I've obtained a 14-day SSL certificate from VeriSign. I've added the "VeriSign Test CA" under the Trusted Root Certificate Authority group on the client machine's Internet Explorer and Mozilla Firefox browsers. I then installed the certificate on the server machine under the IIS Manager.

I configured an Outlook MAPI-based profile to access the Exchange server, and it works.

I then went back and configured the same profile to use RPC over HTTPS. It tries to connect, but I repeatedly get a dialog box asking me for my username/password even though I am entering the correct login information.

Looks like we're making a little progress... any ideas?

 

[stikman]

I am sad to say that I came to this forum to find an answer to the exact same issue.

All the same steps , even payed for a REAL SSL certificate in desperation. no improvement. Just keep getting prompted for passwords.

I have yet to fix this but need to soon as well as an MIS_5
error when attemping to contact the ActiveSyncServer via the net.

I am wondering if its a port issue but have tried both published solutions, 6001-6002 & 6004 and 6001/6004 only

I will post if I work it our,

 

[stikman]

Only a few minutes after I posted the above I had a thought.
I changed the exchange server name to the actual server name ie: server.domain.local

Previous to this I had the internet dNs name (same as what is in proxy settings ie: mail.domain.com

I then reread the ms article and noted that I had missed that bit

it worked !!! as last

 

[anonim1]

stikman,

When you say you changed the Exchange server name, what exactly do you mean? Where did you make this change? I haven't reviewed my settings for a couple of days, but I believe that all of the domain names that I have used are that of my internal FQDN, servername.domainname.local (mine is server.exchange.local). I am using DynDNS to establish the external DNS name to my IP address.

Please let me know where you made this change, thanks!

 

[DrBobKnows]

I am still having the problem many ppl are reporting here however as suggested I tried putting my Outlook 2003 Client on the same subnet as the Exchange Server. It connected instantly.

Then I moved the Outlook Client to a different subnet (one that is 2 hops or routers away via the internet) and it still worked.

I decide to try it again by deleting the exchange account and adding it back. The original problem returned.

I suspect that one or more of the following is to blame.

1. From the remote subnet there is a problem resolving the NetBIOS name (DNS) of the exchange server to get things started during the "Check Name" step.
2. Something is not correct in the gateways (routers/firewall) that is preventing the Check Name function.
3. This is a bug in windows or outlook and I am missing a patch.

I think stikman is "on to" the cause. My Exchange server name is (changed to protect the innocent) host.domain.foo.com and my proxy URL is exchange.foo.com.

I am wondering if there is DNS confusion because the 2nd and top level domain (foo.com) has public DNS records which only have records for the proxy URL and not the private Exchange server (local). Because of this perhaps the Outlook client fails to find the exchange server via the proxy.

 

[DrBobKnows]

I have just noted something interesting. If the Exchange server name you enter can be resolved to an IP address, Outlook will attempt to connect to port 135 first. I believe this is part of the original question that started this thread. Sometimes it tries SSL but not always.

i.e. netstat -n shows:

TCP 10.1.1.204:4694 <IP exchange server name>:135 SYN_SENT

If the exchange server name entered cant be resolved to an IP address then the SSL connection is brought up first and I presume the attempt to connect to the Exchange server is via the SSL connection instead.

i.e. netstat -n shows:

TCP 10.1.1.204:4694 <IP exchange proxy>:443 ESTABLISHED

 

[stikman]

My mistake was located in the "Exchange Server Name"
Tools>>Accounts>>ViewChange>>Change

Where is says: "Mirosoft Exchange Server:"

I had incorrectly entered mail.mydomain.com

The correct entry should have been

myserver.mydomain.local

Then under moresettings>>connection>>Exchange proxy settings I have the entry mail.mydomain.com

My RPC/ValidPorts entry is as follows -

ex1:593;ex1:6001-6002;ex1:6004;ex1.Domainname.local:593;ex1.Domainname.local:6001-6002;ex1.Domainname.local:6004

ex1 being the server name