asked on

RPC over https will not work

We have recently deployed a front end\back end exchange 2003 SP2 system. Email works fine, OWA works fine. I have followed MS KB articles to set up RPC over HTTPS and have not had any luck. I have also searched a million tech articles to no avail. I can reach my server via https://servername.domain.com/rpc and /rpcproxy.dll. I beleive the problem is the communication from FE to BE. I have tried to use rpcdump with no success. We have a Thawte certificate, so I do not beleive that that is the problem. I accidentally set rpc ports manually the FE, BE and DC's. If I deselect this is a front end server, restart and re-enable it, will that reset the ports in the registry? Also, can I do the same for the back end server? How else can I test this configuration?

top_rung

are you using forms based authentication or are you using a separate virtual server for any non-forms based authentication traffic?

jgarciajr

ASKER

I am not using forms based authentication. I have the smpt virtual server and the http virtual server set up.

top_rung

Rpcdumpt failing implies server connection issues but so many minor things improperly configured on the client side can be a culprit also. But assuming it is not client issues, try the following tools to test the server connectivity,

rpcping

http://support.microsoft.com/default.aspx?kbid=831051

or try rpcdiag
http://www.amset.info/exchange/rpc-http-diag.asp

ASKER CERTIFIED SOLUTION

Sembee

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

top_rung

Well if the problem is on the client-side, which has not been ruled out, FBA would be an issue if there are multiple Virtual Servers and Basic Authentication issues exist. Just getting that question out of the way.

So, if the problem is isolated to be between FE/BE servers (the tools listed should help you determine that), then Sembee is correct, FBA has nothing to do with it.

YOu can also check your firewall logs to see if the Outlook on the client side is trying to connect via HTTPS and if so to help rule out the client config.

Sembee

I don't think I have ever had FBA cause a problem with RPC over HTTPS - in fact I wouldn't have even asked the question as it has nothing to do with the feature. The only common thing that they have is that they both use a web service.

The only valid part of the question would be whether the default web site is being used or not - as the /rpc virtual directory only exists on the default web site by default.

Simon.

top_rung

What I know to be fact is that enabling forms based authentication on a virtual server effectively disables Basic Authentication on that virtual server which in turn breaks OMA, EAS, and RPC-HTTPS access. To fix this, you must create a second virtual server and configure it properly. I have been down that road and had to correct it .

Sembee

Really?
FBA will break OMA and EAS, but not RPC over HTTPS. I have done many many deployments and not run in to that issue.

The issue of FBA breaking OMA and EAS can also be worked around without having to create another virtual server as well, despite what Microsoft may say. On my home Exchange server I have RPC over HTTPS, EAS, OMA, OWA, FBA all running on the same machine with an SSL certificate.

Simon.

jgarciajr

ASKER

Well, the problem must of been the Validports that I fat fingered in the registry. I set both FE\BE servers to not be part of the rpc http topology, then turned those features back on. Connected to the site via VPN, set up rpc over http in outlok, disconnected the vpn and now I am able to send\receive email through https. THanks

top_rung

Awesome, it didn't take too much tinkering. Glad it worked out.

Thanks for posting the resolution.

top_rung

Sembee,

is it a requirement to use basic authentication?

Sembee

Basic authentication where?

Simon.

top_rung

Simon.

I opened a new question for this..

https://www.experts-exchange.com/questions/21805590/RPC-HTTPS-basic-NTLM.html

thanks,