OWA Assistance Needed - Not Working
So, I am a little confused here. I knew this process went too smoothly. I just switched from a dedicated T1 line to Comcast Business Class (with a True Static IP). Of course when I switched, I now have a completely different static IP than I had before. I set the network up and everything works perfectly internally. However, I am unable to access our OWA site. I looked in the Exchange Management Console. OWA is configured under Client Access and our external URL is listed correctly. What am I missing or doing wrong?
April 5th, 2011 4:56pm

Unlikely to be an Exchange error, because Exchange doesn't care what the external IP address is. As long as it resolves to the correct place. Therefore you need to look at the standard things - default gateway, DNS etc. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
April 5th, 2011 5:17pm

Hmm. Well, the default gateway is set as the 192.168.2.1 private IP (default gateway is correct in my Firewall router settings). So that seems correct. However, my AD server is configured as my Primary DNS server (192.168.2.10) and the secondary is from Comcast (they gave me a Primary too though). You're saying it is probably an issue with my DNS server settings? I am unfamiliar with configuring that and have looked at it, but not sure what needs to be changed/modified.
April 5th, 2011 5:22pm

No, when I say DNS I mean the resolution of your host name to the correct public IP address. Although it isn't recommended to have any external DNS servers listed in the network configuration of any AD server. If you must use an external DNS server, then configure forwarders in the DNS server applet on the domain controller/s. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
April 5th, 2011 5:36pm

I think I realized the issue. I think it is a port forwarding problem in my Firewall. I've searched all over the internet and have seen completely different answers to this, but do you know specifically what port(s) need to be set for inbound for OWA?
April 6th, 2011 8:56am

OWA with an SSL certificate only requires 443, nothing else. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
April 6th, 2011 1:04pm

Must be a DNS issue then. The port forwarding for SSL (443) only made our internal FQDN OWA accessible.
April 6th, 2011 1:55pm

Hi, How about the situation after you opened the 443 port for the external URL? As you mentioned, you have changed your public IP, but I haven’t seen you update MX record at ISP side.Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
April 6th, 2011 10:44pm

Hi Jerome - Nothing changed when I opened up port 443, except we then had access to OWA internally (which we really didn't need that). I didn't think of the MX record on the ISP side. I assume I need to have the ISP add an MX and Host (A) record for OWA pointing to our static IP?
April 7th, 2011 9:38am

MX record has nothing to do with OWA access. Furthermore, if it was firewall then you could just browse to https://123.123.123.123/owa (where that is your static IP address) and get access, although with an SSL warning. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
April 7th, 2011 11:17am

I was confused. I didn't think it did at first, but I misunderstood what I was reading. Going to https://ourstaticip/owa worked perfectly. So that means it is a DNS issue right? It isn't correctly resolving the host name to our static IP (what Sembee originally stated above).
April 7th, 2011 11:58am

If the IP address method works, then it isn't an Exchange issue, it is DNS. Do ensure that you are testing it from a machine external to your network, so at another location to ensure you have a valid test. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
April 7th, 2011 12:17pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics