RPC over HTTP

At 11.30 at night in the UK, I am in bed (normally).

Have you made the registry change on the domain controller?
Are the correct entries for the domain controller in the registry?

Simon.

Simon

I believe I got the keys right based on your site.  The DC settings I'm sure of.  The exchange settings are where it gets fuzzy.  I went to freessl.com and got a .cer with server.domain.com.  The registry settings call for server.domain.local and mail.external.com.  When I set up a user internally, I use server.domain.com so in the registry I entered server.domain.com wherever I saw server.domain.local or mail.external.com.

Another question.  Why does everyone say you need to open port 443 for RPC if the whole idea behind RPC over HTTP is to deal with firewall issues?  If RPC is wrapped in HTTP, why the need to port forward 433?


Carl

I am going to go over your information, as well.  It looks like you have listed some testing tools I have been looking for to test individual components of the whole picture.

the technique for outlook access should be called RPC via HTTPS
RPC is wrapped inside of HTTPS
port 443 and only port 443 (for this purpose) must be opened and forwarded appropriately

OWA via https://realdomainname.domain.com/exchange MUST work prior to doing this.

damn Simon with quick fingers, sorry to overpost, or under in this case.  Please for the record you are my Hero and please do not take anything I say as a slight.

Simon do you prefer these to be using real certs from a CA or self signed?  can't beat the speed of using self signed.

Real certificates - 100%.
I never use self signed. While they are cheap and easy to get, they increase the administrative burden, are a sod to manage, look cheap, generate warnings etc.

I blogged my rant last month: http://msmvps.com/blogs/sembee/archive/2006/03/05/85588.aspx

Even using a purchased certificate, I get mine from RapidSSL and I can have the entire thing deployed in a hour.

Simon.

I got a cert from rapidSSl as well.

Can you clear this up a bit Simon

"I think you have got the registry settings wrong.
If you have got the certificate in the same name as the server is known as internally - ie server.domain.com is its name on the AD domain and on the internet (which is highly unusual - I tend to use a common name like mail.domain.com for this feature so that the certificate and configuration isn't tied to one server) then you just change everything to the same name - you don't need to use two different names."

The way I read this, I have done exactly as you stated.  The cert name is server.domain.com, my server is seen by this both internally and externally, and this is the way I set registry keys.

A little more info:  We have web access enabled on exchange.  Internally, i can access it via https://server.domain.com/exchange or http://server.domain.com/exchange.  However, externally I can only get to it via http://server.domain.com/exchange.  I didn't set up any of this but I believe they (web access and RPC) are running from the same web server on the exchange box, are they not?

Sounds like you have a split DNS configuration setup. That allows the name resolution internally to resolve to the internal IP address of the server, and the name resolution externally to resolve to the external IP address. Very common and is how I do most of my deployments as it allows the users to bounce between inside and outside without any changes.

Have you made an error above?
Do you mean to say that you are unable to use the https variant from outside of your network? The more common scenario is that http and https works internally, but https ONLY works from outside (that is certainly how I have done it in the past).

Re-reading the question, and based on what you put in your original query, this looks like the problem is with the registry settings for the domain controller, not the Exchange part.
Ensure that the domain controller being referenced in the registry settings has had the small change made to its registry.

Simon.

not to conflict with Simon-

Can you explain your firewall and port forwarding, so we can help you get  https://server.domain.com/exchange to work?

firewall is a Cisco PIX 501, ports forwarded to server.domain.com are HTTP, HTTPS and RPC.  The interface doesnt allow you to specify port numbers, only protocols

Simon

No error, internally i can use https or http -- externally i can only access via http

You need to look at your firewall configuration.
It does with work the Cisco PIX 501, I have lost count the number of times I have setup rpc over https with a PIX - it is my preferred firewall.

Simon.

ok, I checked the firewall settings last night.  I was able to get my OWA to work externally only via https://.  The orginal access rule for https was like this:

Source:  Outside/0.0.0.0
Protocol/Source Port:  HTTPS

Destination:  Inside/x.x.x.x (internal Exchange IP)
Protocol/Source Port:  HTTPS

I changed to:

Source:  Outside/0.0.0.0
Protocol/Source Port:  Any

Destination:  Inside/x.x.x.x(Internal Exchange IP)
Protocol/Source Port:  HTTPS

Changing the Outside protocol to Any allowed my OWA to be accesible via HTTPS://.

Question:  For RPC over HTTPS to work, do I have to do this?

Source:  Outside/0.0.0.0
Protocol/Source Port:  RPC

Destination:  Inside/x.x.x.x(Internal Exchange IP)
Protocol/Source Port:  RPC

Or

Source:  Outside/0.0.0.0
Protocol/Source Port:  Any

Destination:  Inside/x.x.x.x(Internal Exchange IP)
Protocol/Source Port:  RPC

Or should the RPC be HTTPS?  As I stated before, when I create rules, I dont have the option to enter port numbers, only protocols.  I actually tried using RPC for both without success.

Another question, I read somewhere that for RPC to work, you have to set up the client profile while on the LAN.  Is there any truth to this.  I actually tried to set up the profile while connected via VPN and it validated username, but once I disconnected from VPN, I couldn't connect under that profile.

Also, I still think I have something configured wrong because when I on LAN and test RPC profile using outlook /rpcdiag, I still get the following:

server.domain.com          directory          TCP/IP
server.domain.com          directory          TCP/IP
server.domain.com          mail                 HTTPS
server.domain.com          mail                 HTTPS
server.domain.com          mail                 HTTPS

Thanks again for all your guys help

The whole point of setting up RPC over HTTPS is that the traffic goes across the HTTPS protocol. No other port has to be opened other than 443. In most cases if you have OWA working correctly with an SSL certificate, then RPC over HTTPS will also work correctly - no further changes required.

As for setting up the feature - you don't have to setup the Outlook client on the LAN. It does make things easier, but can be set off the network. If you look at my web site (http://www.amset.info/exchange/rpc-http.asp) then I have instructions on how it can be set when there is no connection available to the LAN.

What I do recommend is that you get it working inside first, to avoid the firewall being the cause of any problems.

Simon.

HOLY TOLEDO....so I'm laying in bed mulling this over and a thought occured to me....I have been making the DC registry changes on the exchange box.  I've talked about this so much that I've confused myself.  My DC GC is a seperate box than my exchange server.  I had to get up and write this so I wouldn't think I was dreaming.......

I'll let you guys know how it goes.

Darren

well, I guess I was dreaming because I did have the NSPI key on the DC and not the exchange box like I was thinking I did

It wouldn't matter if you had it on your Exchange server anyway - Exchange would just ignore it.

Sometimes it comes down to simply undoing what you have done and starting again. Removing the registry entries from all machines, removing the RPC proxy and then rebooting the machine and starting from scratch.

Simon.

I think I've resigend to that solution, but before I close this topic, one more question on ssl certs.  I have created about 4 certs now from rapidssl and when I go http://exchange-server/rpc I get the warning stating that the 'name on the security certificate is invalid or does not match the name of the site'.  The other two are checked green.

My RPC vitrual directory is under the Default Web Site dir.  My Exchange virtual directory is also under this directory.  I access my OWA via http://server.domain.com/exchange.

When i create a new cert, the first option is to 'type a name for the new cert' and by default, it already entered 'Default Web Site'.  Then a couple windows later, it asks for the common name of the site.  I'm confused as to what to enter in these fields.  I've tried using server, server.domain.com and even left Default Web Site, but i get the same warning.  I know you said to use something generic like mail.domain.com, but the machine name and the exchange server are already named the same thing, server1.

I know Im probably driving you nuts, but I really appreciate all your help

Common name is the name that the server responds to.

Therefore if you want to enter https://mail.domain.com/exchange in to the URL bar, then the common name will be mail.domain.com

I usually recommend that a generic name is used, rather than the server's real name. In the event that you have to move the certificate to another server you can simply adjust the DNS.

Once you have the certificate, you have to access the server with the name on the certificate to avoid the warnings. That usually means some DNS tweaks so that the name works both internally and outside.

Simon.