Exchange RDP over HTTP

[ShowMe]

As shown in http://support.microsoft.com/Default.aspx?kbid=833401 it is possible to run Outlook via http. This is not the Outlook Web client, but the ability to use the full-blown version of Outlook without the need of connecting to a VPN.

Anyone ever set this up and get it to work?

[scribble]

This step-by-step article describes how to configure remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) in Microsoft Exchange Server 2003.


You seem to think this is a guide to getting your outlook mail in a web browser, using the outlook client on another PC.

It is not.

It is a guide for getting Outlook on your PC to connect to a remote server without using the standard ports for Outlook's RPC. You still need a local copy of Outlook.

Tunneling RDP over HTTP is simple, but if you were to do so, it still wouldn't be available in a web browser. For that you would need something to translate RDP into a web page. I've never seen anything like that. It's possible, maybe, in theory, but it would be painful to use and no one would want it.

There are Java and other web-based VNC clients available. Probably RDP as well. Look into that, it WILL allow you to do what you want... but it won't be nearly as fast as using a webmail system.

-Chris

[Freakshow]

As shown in http://support.microsoft.com/Default.aspx?kbid=833401 it is possible to run Outlook via http. This is not the Outlook Web client, but the ability to use the full-blown version of Outlook without the need of connecting to a VPN.

Anyone ever set this up and get it to work?Yep. Are you looking to set up the server? Or do you have the server set up already, and are looking to configure the client?

[ShowMe]

You seem to think this is a guide to getting your outlook mail in a web browser, using the outlook client on another PC.

"This is not the Outlook Web client, but the ability to use the full-blown version of Outlook without the need of connecting to a VPN."

I suppose I could have said it tunnels RDP over http, if I wanted to be precise.
I know what it's supposed to do....just can't get the silly thing to do it.

[ShowMe]

Yep. Are you looking to set up the server? Or do you have the server set up already, and are looking to configure the client?

I have both the server and client. I have set them up exactly as specificed in the instructions, but it simply will not connect. When I run the oulook with the rpc/diag switch it never shows https: as the connect. When connected to the LAN it shows TCP/IP, when attempting to connect via the Internet I get -- in the connection area.

My guy feeling is that it has to do with the certificates. I loaded a certificate server on the system until it's working & I have a proof of concpet; if I can get this to work we'll go with a 3rd party certificate. I've tried a lot of the troubleshooting papers but they all end with "and if you've followed these instructions exactly it should work". It doesn't.

Offhand I guess some basic knowledge would push me in the right direction:

1.) Does the server version of 2003 or the Exchange version of 2003 matter? There is a Standard and Enterprise version of both. Do they need to match? Can they mix and match?

2.) Can the Exchange server itself be a member server, or does it have to be a domain controller?

(Everything I've seen leads me to believe that the particular versions don't matter, so long as I have the latest patches, and that Exchange can be a member server)

On the cert server side, everything seems to work when I test the rpc directory. I'm just not sure what else to troubleshoot.

[Freakshow]

I have both the server and client. I have set them up exactly as specificed in the instructions, but it simply will not connect. When I run the oulook with the rpc/diag switch it never shows https: as the connect. When connected to the LAN it shows TCP/IP, when attempting to connect via the Internet I get -- in the connection area.

My guy feeling is that it has to do with the certificates. I loaded a certificate server on the system until it's working & I have a proof of concpet; if I can get this to work we'll go with a 3rd party certificate. I've tried a lot of the troubleshooting papers but they all end with "and if you've followed these instructions exactly it should work". It doesn't.

Offhand I guess some basic knowledge would push me in the right direction:

1.) Does the server version of 2003 or the Exchange version of 2003 matter? There is a Standard and Enterprise version of both. Do they need to match? Can they mix and match?

2.) Can the Exchange server itself be a member server, or does it have to be a domain controller?

(Everything I've seen leads me to believe that the particular versions don't matter, so long as I have the latest patches, and that Exchange can be a member server)

On the cert server side, everything seems to work when I test the rpc directory. I'm just not sure what else to troubleshoot.If I insult your intelligence with any of the following, you'll just have to forgive me. I have no idea what your level of experience is, or what you have done thus far. :)

Let's see first if it is working at layers 3 and 4.

I assume you are using OWA, and not running this directly on Exchange? I'm not even sure if it can be run directly on an Exchange server.

Is the server listening on TCP port 443? Which IP address(es) is it listening on? "netstat -an" at the server will tell you this.

Is there anything that would prevent an inbound connection to TCP 443 on the server? Like a host-based firewall, or an IPSec policy? Or a hardware firewall? A router ACL?

When the client attempts to connect, is it resolving the correct DNS name? A sniff would from the client would be the best way to troubleshoot it, but if you don't have that, you can do the following...

Use "ipconfig /displaydns" on the client, after it attempts to connect, to see what IP it is resolving for the server. While Outlook is attempting to connect, run "netstat -an" at the client, to see if it is attempting to establish a TCP connection to port 443 on the server at that time. As I said, a sniff is better, but command-line tools will have to do if you don't have something to sniff with. If the TCP connection or attempt is listed, what state is it in?

Sorry if you've done that much before. But this will tell us about layers 3 and 4. Once we have 3 and 4 working, we can keep going up the stack.

[ShowMe]

If I insult your intelligence with any of the following, you'll just have to forgive me. I have no idea what your level of experience is, or what you have done thus far. :)

Experience is extensive with most network type items. And I'm seeking help, I'm not going to get upset towards someone that's trying to assist.

I assume you are using OWA, and not running this directly on Exchange? I'm not even sure if it can be run directly on an Exchange server.

We do utilize OWA, yes. And the RDP over HTTP can be utilized in a "single exchange server, no front-end server" configuration, which is what I'm using.

Is the server listening on TCP port 443? Which IP address(es) is it listening on? "netstat -an" at the server will tell you this.

It's listening on 0.0.0.0, along with all the other unestablished ports.

Is there anything that would prevent an inbound connection to TCP 443 on the server? Like a host-based firewall, or an IPSec policy? Or a hardware firewall? A router ACL?

443 should get through with no worries. And port 80 as well.

When the client attempts to connect, is it resolving the correct DNS name?

It is the correct name, yes. Sadly, I am unable to load Ethereal on the system since it's a remote system that I'm borrowing. Tomorrow when I go in I'll be able to sniff. But it does resolve the name to the ocrrect IP number.

If the TCP connection or attempt is listed, what state is it in?

Established.

Sorry if you've done that much before. But this will tell us about layers 3 and 4. Once we have 3 and 4 working, we can keep going up the stack.

Near as I can tell everything you listed is working as expected.

[Freakshow]

Experience is extensive with most network type items. And I'm seeking help, I'm not going to get upset towards someone that's trying to assist.



We do utilize OWA, yes. And the RDP over HTTP can be utilized in a "single exchange server, no front-end server" configuration, which is what I'm using.



It's listening on 0.0.0.0, along with all the other unestablished ports.



443 should get through with no worries. And port 80 as well.



It is the correct name, yes. Sadly, I am unable to load Ethereal on the system since it's a remote system that I'm borrowing. Tomorrow when I go in I'll be able to sniff. But it does resolve the name to the ocrrect IP number.



Established.



Near as I can tell everything you listed is working as expected.OK, cool. Next thing we have to do is look at the establishing of the SSL session, and see if that is working.

I just realized...you were talking earlier about certificates. Where did you get the certificate on the server you are using for the client to auth the SSL server? If it is not a trusted cert by the client, that could be a cause of the trouble right there. Different SSL clients can take different approaches to handling untrusted certs for SSL server auth. It is possible that Outlook's approach is to just not establish and SSL session, and not give you much info on why. It wouldn't surprise me.

I've got some more ideas, but let me know about the cert first, before I bother typing. :)

[ShowMe]

Where did you get the certificate on the server you are using for the client to auth the SSL server? If it is not a trusted cert by the client, that could be a cause of the trouble right there.

It's kind of my gut feeling as well. I had no experience with certificates before I undertook this particular project.

I'musing myown certificate, not a 3rd party. The boss says he won't spring for the 3rd party one until I can show proof-of-concept (cheap bastard, the things are $200/year from Thawte)

I loaded the Certification Authority on the server that houses Exchange. Iopened IIS & requested a certificate. This creates a cert.txt file. I opened Internet Explorer and went to http://servername/certsrv and requested a certifcate, went through the hoops, cut & pasted the stuff from cert.txt and downloaded the certificate.

I then opened IIS again and loaded the certificate on the server. WhenI cruise to it I get the "untrusted certifcate" error. I followed the instructions on Microsoft's web page (essentially creating an asp file that auto-trusts the certificate).

Not really sure how to check the certificate thing, other than cruising to https://my.server.com/rpc ; it asks me for login credentials without asking me for the certificate.

[Freakshow]

It's kind of my gut feeling as well. I had no experience with certificates before I undertook this particular project.

I'musing myown certificate, not a 3rd party. The boss says he won't spring for the 3rd party one until I can show proof-of-concept (cheap bastard, the things are $200/year from Thawte)

I loaded the Certification Authority on the server that houses Exchange. Iopened IIS & requested a certificate. This creates a cert.txt file. I opened Internet Explorer and went to http://servername/certsrv and requested a certifcate, went through the hoops, cut & pasted the stuff from cert.txt and downloaded the certificate.

I then opened IIS again and loaded the certificate on the server. WhenI cruise to it I get the "untrusted certifcate" error. I followed the instructions on Microsoft's web page (essentially creating an asp file that auto-trusts the certificate).

Not really sure how to check the certificate thing, other than cruising to https://my.server.com/rpc ; it asks me for login credentials without asking me for the certificate.The client computer needs to trust the CA that issued the cert. Different applications can handle this differently. For example, IE will tell you that the cert is not from a trusted authority, and allow you to choose whether or not you want to proceed.

The certificate on the SSL server is used to prove to the client that the SSL server really is who it claims to be.

On the client, run mmc. Go to "File", and "Add/remove snap-in", and add the certificates snap-in. It will ask you which set of certs you want to manage. It doesn't matter in this case whether you choose to manage the certs for the user account or for the computer itself. Select user, because it is less mouse-clicks. :)

In the cert snap-in, you'll see "Trusted Root Certification Authorities". If I understand your last post correctly, you have not yet imported a cert there that will tell the client to trust certs issued by your CA. Is that correct? You can import a cert here, so that your client will trust the cert that you are using on your SSL server. It has been a while since I've done any cert work (and I've never done much of it; just some stuff here-and-there as needed), but I can help you figure out which cert we need to import, if needed.

Note that I am not totally positive that this is the issue, but based on what you have told me so far, it sounds like a potential problem. As I said, I'm not totally sure what Outlook does when it tries to establish an SSL session to an SSL server that is using a certificate that it doesn't trust.

[Freakshow]

It's kind of my gut feeling as well. I had no experience with certificates before I undertook this particular project.

I'musing myown certificate, not a 3rd party. The boss says he won't spring for the 3rd party one until I can show proof-of-concept (cheap bastard, the things are $200/year from Thawte)

I loaded the Certification Authority on the server that houses Exchange. Iopened IIS & requested a certificate. This creates a cert.txt file. I opened Internet Explorer and went to http://servername/certsrv and requested a certifcate, went through the hoops, cut & pasted the stuff from cert.txt and downloaded the certificate.

I then opened IIS again and loaded the certificate on the server. WhenI cruise to it I get the "untrusted certifcate" error. I followed the instructions on Microsoft's web page (essentially creating an asp file that auto-trusts the certificate).

Not really sure how to check the certificate thing, other than cruising to https://my.server.com/rpc ; it asks me for login credentials without asking me for the certificate.One more thing...are you still getting the "Untrusted cert" error? Or are you saying you got that UNTIL you followed the instructions at MSFT's page for trusting the cert?

[ShowMe]

One more thing...are you still getting the "Untrusted cert" error? Or are you saying you got that UNTIL you followed the instructions at MSFT's page for trusting the cert?

I was getting it until I followed the instructions. Now I get the login screen with no warning about untrusted certs.

[Freakshow]

I was getting it until I followed the instructions. Now I get the login screen with no warning about untrusted certs.I take it you are doing that from a browser, just to test SSL? From which machine are you doing that?

[ShowMe]

I take it you are doing that from a browser, just to test SSL? From which machine are you doing that?

Correct, from IE.

It's from my home machine, so I'm not connected to the LAN in any way.

[Freakshow]

Correct, from IE.

It's from my home machine, so I'm not connected to the LAN in any way.So that is IE on a client machine, and not the web server itself? Meaning, for example, you aren't connecting to itself with https://[loopback IP or its own IP]/page?

Sorry to ask again, I just wasn't quite sure.

Is the server not at the location you are at now? If not, are you able to access it remotely in any way, to do some detailed logging of the SSL activity?

[ShowMe]

So that is IE on a client machine, and not the web server itself? Meaning, for example, you aren't connecting to itself with https://[loopback IP or its own IP]/page?

Sorry to ask again, I just wasn't quite sure.

Is the server not at the location you are at now? If not, are you able to access it remotely in any way, to do some detailed logging of the SSL activity?

I am using the fully qualified external name, ie https://mail.myserver.com/rpc

The client machine and the web server are two different machines, yes. Located about 15 miles apart, in fact.

I can access the server if needed. I have remote access through several means.

[Freakshow]

I am using the fully qualified external name, ie https://mail.myserver.com/rpc

The client machine and the web server are two different machines, yes. Located about 15 miles apart, in fact.

I can access the server if needed. I have remote access through several means.Cool. Next is to run detailed logging on the IIS server, and take a look at what is happening during the SSL attempt. Support.microsoft.com has info on this. I would enable the most detailed logging possible, repro the problem, and take a look at the logs.

Something else that might help out is a proxy to run locally on your client. You can run your client's session through the proxy, and see all of the SSL activity. Which you can't see in a sniff, once the encryption starts. If you want a recommendation to run one, let me know and I'll PM you a link. A friend of mine wrote a very good one, that I've used many times.

ETA: Also, check and see if Outlook can do any detailed logging. I don't know how much detail it can provide, but there might be a registry setting somewhere to log detailed info, likely into the Application log. That is another thing I would check. I would want to see the problem from both perspectives, not just the server.

[kevin]

not qualified to help here, but I have seen this done. We had a client that used this with an outsourced mail provider. It was a pain in the arse to setup, and frequently became unavailable. My boss handled the client side setup and judging by the cursing from his desk, it was frustrating.

dig around some more on Microsoft's tech net, I think they had a bunch of support documents on getting around problems.

[ShowMe]

not qualified to help here, but I have seen this done. We had a client that used this with an outsourced mail provider. It was a pain in the arse to setup, and frequently became unavailable. My boss handled the client side setup and judging by the cursing from his desk, it was frustrating.

dig around some more on Microsoft's tech net, I think they had a bunch of support documents on getting around problems.


Microsoft was pretty useless in this particular endevour.

It did, however, become a moot point when the top-level domain administrator decided to upgrade the domain controller to Windows Server 2003. Not that I said "domain controller" (singular), not "domain controllers" (plural).

He crushed the Active Directory, which of course spread its way down into our AD. So we had no access to anything; nothing was being recognized, we couldn't create anew AD because machines would not allow us to remove to old AD, etc.

It's been great fun for the past week. Out of the 144 hours in a week I think I've slept a total of 10. But everything is fixed...and the domain is under my complete control. (place evil laugh here)

Once the AD was restructured I set up the RPC over HTTP and everything works as advertised. Haven't had any problems as yet, we'll see how it scopes out.