Exchange Server Forums
Forums |
Register |
Login |
My Profile |
Inbox |
RSS 
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
RE: RPC over HTTPS Using Port 135 - WHY??
|
Users viewing this topic:
none
|
Logged in as: Guest
|
Login  | |
|
 Limited time MSExchange.org offer! -- 1.Sep.2008 1:00:00 PM
|
|
TechGenix and SolarWinds have partnered to provide free copies of SolarWinds Exchange Monitor to all visitors who join the MSExchange.org Forums. SolarWinds Exchange Monitor is a handy desktop dashboard that continuously monitors Microsoft Exchange to deliver real-time insight into Exchange services, mail queue sizes, and host server health. Learn more about Exchange Monitor and the free offer!
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 17.Feb.2005 6:11:00 PM
|
|
|
anonim
Posts: 34
Joined: 27.Jan.2005
From: US
Status: offline
|
Calm down. All you needed to say was that RPC over HTTP configuration has changed since you posted in 2003. I'm not here to point fingers. As you can see, I am spending a lot of time trying to find a solution to my problem, and when I find something that relates to my issue, I bring it up and look for responses.
So now I'm having to make assumptions about what is or is not possible because of the lack of actual information in your last post.
It may save us both time to just be direct:
1. Is it possible to configure an RPC over HTTP profile without first creating the profile over RPC (135)? (I think this would be a yes based on your last post).
2. Is it possible to create the RPC over HTTP profile from outside of Outlook (i.e. using profgen.exe or the Custom Installation Wizard)?
3. Is it necessary to create the RPC over HTTP profile outside of Outlook (i.e. using profgen.exe or the Custom Installation Wizard)?
If the answer to 3 is No, then I assume there is a problem with configuration on my server's end. However, RPC over HTTPS works just fine after the initial connection on port 135. Therefore, this possibility is hard for me to believe.
Now, if the answer to question 3 is Yes, I would like to see step-by-step details on how to do this, because the profile I created using the CIW was not able to connect to my Exchange server via RPC over HTTP.
Just looking for some answers..
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 17.Feb.2005 11:10:00 PM
|
|
|
Guest
|
quote:
Originally posted by Trask:
I am having the same issue. my external outlook clients want to connect on port 135 as well. ![[Frown]](/image/smiles/frown.gif)
I have 2 different lab environments. both only have 1 server that acts as IIS, DC, and Exchange server. the only difference between the 2 is that 1 is protected by ISA 2004, and the other a Linksys Router.
Now I have tried every trick that i can find. regardless of what i do, It fails to connect. then, when i check the logs, i can see a connection on port 443 and then i see the attempts on 135.
Could this issue be isolated to single server environments??
I'm having the same issues with a Linksys router. I'm wondering if its the router that's causing the problem . . .
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 18.Feb.2005 12:54:00 AM
|
|
|
anonim
Posts: 34
Joined: 27.Jan.2005
From: US
Status: offline
|
Okay, another breakthrough (kind of).
Currently, the server has an SSL certificate installed for the external DNS name. I deleted the Exchange profile on the client machine inside the network. Then I entered my external DNS name and set up RPC over HTTP. Connection failed.
I then installed an SSL certificate on the server for the internal DNS name. The client was able to connect through SSL(443) without ever having to go through port 135. A-HA!
So now that I've proved it's possible, I have to figure out why it doesn't work externally. I'm wondering if it is a DNS issue:
In this network, I have a client XP machine and the Exchange server with Windows Server 2003. Both are behind a D-Link router/firewall. The server only knows itself as server.exchange.local. For my external DNS name, I am using dyndns.org to forward a chosen DNS name to my external IP address. I don't know a whole lot about DNS, so I have to ask:
Doesn't the DNS service running on the server machine need to know anything about its external DNS name?
Here is my reasoning on why the RPC over HTTP connection only works internally:
1. Server has SSL certificate for external DNS name installed.
2. Outlook is configured to use external DNS name.
3. DynDNS forwards external DNS name to external IP address.
4. Router forwards request to server machine.
5. Certificate is for external DNS name, but server identifies itself as server.exchange.local (internal DNS name).
6. We have a certificate mistrust, and Outlook quietly hangs around and then says the connection cannot be established.
Another issue could be the fact that my router is NAT'ing IP addresses, though I can't really see why this would be a problem (NAT between internal and external IP should be seamless - server is in DMZ).
Hopefully this new information will help you guys a bit.. as always, your suggestions are appreciated.
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 18.Feb.2005 1:59:00 AM
|
|
|
jstrohfus
Posts: 5
Joined: 18.Feb.2005
From: Minnesota
Status: offline
|
I've been trying to follow your chain because I am about to attempt RPC of HTTPS on my own environment.
From what I can tell you now have the RPC over HTTP piece working correctly. It's now more of an issue as to what network you are on. This leads me to believe that it is as you stated a DNS issue.
From the brief detail it does not appear that you have the proper DNS entries on your local DNS server. If you can in some way explain your current dns config that would be helpful. If you have any website that you need to access internally AND externally you should have run into this same issue.
Here is my attempt at how I will be setting it up for my own environment.
1) Create a public dns entry (ex. "mail.companyname.com") which has a public IP. Sounds like you have this already.
2) On your local DNS server (in your LAN..assuming that's where your DNS server is) create a new DNS zone that is the same as your external zone (ex. "companyname.com")
3) In the the internally (LAN) hosted zone create an A record for ("mail.companyname.com")...the difference here is that you will provide a private IP (ex. 192.x.x.x).
4) In your outlook client I would configure the mail server by the FQDN (public name "mail.companyname.com"). This will enable your computer whether on the internal network or external to use the same server name however it will resolve different IP's depending on where it is (LAN or WAN).
5) SSL cert will be for a public dns entry...(ex. server.companyname.com) Not sure but I think you were onto something there with the "mis-match"
You will have to ensure your routing and FW rules from both your LAN and DMZ allow HTTPS/HTTPS/DNS ports through to each other...sounds like you have that drill down well.
Hope this helps...will continue to monitor this thread.
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 18.Feb.2005 2:55:00 AM
|
|
|
Guest
|
This was it! You guys rock. I've been working on this problem for two days straight and actually flattened my box and started over. But this was the problem. The following KB article verifies as much: http://support.microsoft.com/kb/833401
"Additionally, if you use your own certification authority, when you issue a certificate to your RPC proxy server, you must make sure that the Common Name field or the Issued to field on that certificate contains the same name as the URL of the RPC proxy server that is available on the Internet. For example, the Common Name field or the Issued to field must contain a name that is similar to mail.contoso.com. The Common Name field or the Issued to field cannot contain the internal fully qualified domain name of the computer. For example, those fields cannot contain a name that is similar to mycomputer.contoso.com."
Thank you!
Paul
quote:
Originally posted by John Strohfus:
I've been trying to follow your chain because I am about to attempt RPC of HTTPS on my own environment.
From what I can tell you now have the RPC over HTTP piece working correctly. It's now more of an issue as to what network you are on. This leads me to believe that it is as you stated a DNS issue.
From the brief detail it does not appear that you have the proper DNS entries on your local DNS server. If you can in some way explain your current dns config that would be helpful. If you have any website that you need to access internally AND externally you should have run into this same issue.
Here is my attempt at how I will be setting it up for my own environment.
1) Create a public dns entry (ex. "mail.companyname.com") which has a public IP. Sounds like you have this already.
2) On your local DNS server (in your LAN..assuming that's where your DNS server is) create a new DNS zone that is the same as your external zone (ex. "companyname.com")
3) In the the internally (LAN) hosted zone create an A record for ("mail.companyname.com")...the difference here is that you will provide a private IP (ex. 192.x.x.x).
4) In your outlook client I would configure the mail server by the FQDN (public name "mail.companyname.com"). This will enable your computer whether on the internal network or external to use the same server name however it will resolve different IP's depending on where it is (LAN or WAN).
5) SSL cert will be for a public dns entry...(ex. server.companyname.com) Not sure but I think you were onto something there with the "mis-match"
You will have to ensure your routing and FW rules from both your LAN and DMZ allow HTTPS/HTTPS/DNS ports through to each other...sounds like you have that drill down well.
Hope this helps...will continue to monitor this thread.
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 18.Feb.2005 6:45:00 AM
|
|
|
anonim
Posts: 34
Joined: 27.Jan.2005
From: US
Status: offline
|
John,
I will try to summarize my DNS configuration:
I am using my router as the primary DNS server. It uses my ISP's DNS servers to resolve names. The only reason I have a DNS server on the 2003 box is because it is setup as a domain controller.
Under the DNS snap-in on the server, I have Forward and Reverse Lookup Zones. Under Forward Lookup Zones, I have the following two entries:
_msdcs.exchange.local
exchange.local
Under Reverse Lookup Zones, I have an entry for 192.168.0.x Subnet. I believe this is correct since my subnet is configured as 255.255.255.0.
However, nowhere have I created an entry for my external DNS name (let's refer to it as external.host.com). Since the SSL certificate carries this external name, it figures that I should have something for external.host.com.
The only other important setting I see is that the router's IP address is set up as a forwarder from the DNS server.
Now, do I need to set up both a forward and reverse lookup zone for external.host.com? Also, do I need to set the IP address of external.host.com to my public IP, or my private IP (since it eventually resolves to private IP anyway).
I feel that we are getting very very close!
[ February 18, 2005, 06:46 AM: Message edited by: anonim ]
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 18.Feb.2005 6:56:00 PM
|
|
|
jstrohfus
Posts: 5
Joined: 18.Feb.2005
From: Minnesota
Status: offline
|
anonim -
I hope I am not confusing matters by the DNS discussion...what I am not understanding is how your Network A and Network B are communicating.
1) Do you have a seperate domain in network A (LAN) with it's own DNS server (probably your DC)?
2) The network B (DMZ) where the Exchange server lives. Is that a seperate domain or part of the domain in network A?
Typically most LAN's will have an internal DNS that handles all internal domain servers and pc's and your DMZ would utilize public DNS (via your ISP).
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 18.Feb.2005 8:32:00 PM
|
|
|
anonim
Posts: 34
Joined: 27.Jan.2005
From: US
Status: offline
|
Let's stay with the DNS discussion because it may be the problem with my RPC over HTTP issue.
Okay so the two networks we have are a business network and a home network.
In the home network, there is the server machine and one XP machine. Both are behind a router/firewall connected to a cable modem.
In the business network, there are thousands of computers. About 10 of them will be connecting to the Exchange server in the home network over RPC over HTTP.
The server machine in the home network has a DNS server set up with the private domain name exchange.local. However, DNS server is only setup because the server is configured as a DC (with no member servers). By this, I mean that there are absolutely no computers which are sending name resolution requests to this machine. The XP machine uses the router device as its DNS server. The router forwards these requests to my ISP's DNS servers.
The server machine is currently in the DMZ in the home network while I get RPC over HTTP working. Ideally, once everything works, the server will be placed back behind the router firewall and will only have port 443 forwarded to it.
It is important to note that the authoritative server for my home network public DNS name (we'll call it external.host.com) is with the dyndns.org site. When a request is sent to resolve the IP address for external.host.com, the DNS server gets the IP from the dyndns.org site. No machines in my home network have any knowledge about the public DNS name associated with the public IP. Is this right??
The SSL certificate is issued to external.host.com, but the Exchange server only knows itself as server.exchange.local. This is where I believe a certificate mistrust occurs.
Hopefully that gives you enough of an idea to understand the two networks.. I'll be waiting anxiously to hear the next post!
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 18.Feb.2005 9:56:00 PM
|
|
|
jstrohfus
Posts: 5
Joined: 18.Feb.2005
From: Minnesota
Status: offline
|
Okay so the two networks we have are a business network and a home network.
I assume that the business network and home network are both behind the same router/fw and using the same ISP? The home network is the "DMZ" and the business network is the "LAN"?
In the home network, there is the server machine and one XP machine. Both are behind a router/firewall connected to a cable modem.
The server machine in the home network has a DNS server set up with the private domain name exchange.local. However, DNS server is only setup because the server is configured as a DC (with no member servers). By this, I mean that there are absolutely no computers which are sending name resolution requests to this machine. The XP machine uses the router device as its DNS server. The router forwards these requests to my ISP's DNS servers.
...which in-turn perform the lookup based on the dyndns.org servers. This should be fine but you say below that the XP machine "has no knowledge of the public dns IP"...the question is why doesn't that work?
It is important to note that the authoritative server for my home network public DNS name (we'll call it external.host.com) is with the dyndns.org site. When a request is sent to resolve the IP address for external.host.com, the DNS server gets the IP from the dyndns.org site. No machines in my home network have any knowledge about the public DNS name associated with the public IP. Is this right??
This is strange to me...if your XP machine in the home network is using public dns server it should resolve "external.host.com" to the public IP.
The SSL certificate is issued to external.host.com, but the Exchange server only knows itself as server.exchange.local. This is where I believe a certificate mistrust occurs.
I don't think this is an issue but I am not certain.
I might still be missing the whole picture but here is how I would set it up...
In the home network on the DNS server create a new zone that is the same as the public (ex. host.com) In that zone create an A record called "external.host.com"...use the INTERNAL (Private) IP for this entry.
On the DNS server properties put a "forwarder" entry to that of your ISP's DNS server. This tells the server for any zone that it doesn't have locally to go to the ISP DNS box for resolution. Now, you have what I would consider to be a "normal" implementation.
Then change your XP machine so that it uses exchange.local as it's primary DNS server...remove an entry for the secondary. You will probably need to statically IP this XP box to do this for testing.
So, now your XP box will use the exhange server to resolve all names first...if exchange.local doesn't know the info (in 99% of queries it will not) it fwd's onto your ISP. One benefit is that the local DNS box cache's the query.
The Goal:
1) Internal network (home) resolves the hostname external.host.com to the internal (exchange.local)'s private IP.
2) From anywhere else the Internet DNS will resolve external.host.com to your public (global NAT IP).
See where this takes you... I am now very curious about the resolution.
[ February 18, 2005, 10:04 PM: Message edited by: John Strohfus ]
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 19.Feb.2005 12:40:00 AM
|
|
|
anonim
Posts: 34
Joined: 27.Jan.2005
From: US
Status: offline
|
John,
The two networks are not related in any way, shape, or form. The home network is just that; it's in my house. The business network is at my business location; as I said, there are thousands of machines in this network, with its own mail servers, DNS servers, blah blah blah.
Maybe it would help to explain what my overall goal is.
At my business, there are about 10 users who will be using the Exchange server to share calendars, contacts, tasks, etc (not mail). The request to install the Exchange server in the same network was denied, with their reasoning being that "we already have a mail server". So anyway, the next decision was for me to install the Exchange server on an extra machine I have at home, and set up RPC over HTTP for the 10 client machines at my business to connect to the Exchange box at my home.
So now that I've cleared that up, please read my last post again, keeping in mind that the home and business networks have no relation whatsoever.
Thanks for sticking with this!
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 19.Feb.2005 11:01:00 PM
|
|
|
jstrohfus
Posts: 5
Joined: 18.Feb.2005
From: Minnesota
Status: offline
|
Ok...making more sense to me now! :-)
Ok, so I will focus on the HOME network first.
Becasue I don't understand fully how your DMZ is setup this is what I would do.
Put the Exchange.local box on your LAN and just port forward (80/443) on your router/fw. That will eliminate any LAN/DMZ/WAN routing issues and simplify things.
Then I would make the recommended DNS server changes...(create the local zone and add the entry external.host.com with a private IP).
See if that works. If so, then you have to test from the WAN and we can troubleshoot that part.
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 20.Feb.2005 4:22:00 PM
|
|
|
anonim
Posts: 34
Joined: 27.Jan.2005
From: US
Status: offline
|
John,
My router allows me to place one PC in my network in the DMZ. This basically means that, whatever data is sent to my public IP address, it is automatically forwarded to the respective port on the machine in the DMZ. So, I think things are simpler when the server machine is in the DMZ, because there are no worries about if some required ports are not being forwarded (even though 443 is the only port that I need forwarded; don't need 80 because I am not using HTTP).
I tried adding a new zone for exchange.host.com, restarted DNS and IIS/Web server services, but it still does not work.
I am thinking about renaming my internal domain from server.exchange.local to exactly what my public DNS name is. Even though this is probably not a good thing to do, it may solve my issue. However, the process of renaming a domain is quite complicated. I just can't think of any other solution...
|
|
|
|
|
RE: RPC over HTTPS Using Port 135 - WHY?? - 20.Feb.2005 8:07:00 PM
|
|
|
jstrohfus
Posts: 5
Joined: 18.Feb.2005
From: Minnesota
Status: offline
|
If you can Ping the DMZ server (exchange.local) by it's private address from your LAN then it's not an issue...if you can't then I'd put the box on the LAN port...then you know there is no funky routing isse.
I wouldn't rename your domain...that won't help and will probably create other issues for you.
K, back to the DNS questions....
So you created the new zone...did you put the INTERNAL IP associated with the A record (exchange.host.com)?
The other thing you need to ensure is that the XP machine resolves the name exchange.host.com to your INTERNAL IP. In order to do that you need to make sure that the XP machine only knows about the exchange.local as it's Primary DNS server (No secondary).
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
Printable Version
