Solved

Exchange resolves remotely but not locally - why

Posted on 2014-10-30
38
87 Views
Last Modified: 2014-12-02
As part of an ongoing project that I have asked questions about before, I now have another even more obscure question.

I have an existing Exchange server set up in my office, all working perfectly, OWA, Outlook anywhere etc etc. the particular mail domain IP is ***.***.***.244

Clients in the office connect to this exchange box using outlook and all is fine.

I had a need to add another exchange server as we needed to be able to use another domain from the same outlook clients whilst keeping everything separate.
My idea therefore was to set the new exchange box up on a different domain with mail pointing to ***.****.***.246 and then use outlook anywhere to allow the workstations' outlook to connect, in effect giving each office user 2 totally separate e-mail accounts within the same outlook client - exactly what management wants.

I have hit a problem though - everything works perfectly when I use a laptop on a different internet connection to the office (in my house for example) but the moment I try and set it up on a computer on the office LAN it won't even resolve the mail server name.

I'm fairly sure that Exchange is set up correctly because it connects just fine when I'm not in the office - what else could be the problem?
0
Comment
Question by:dangermouse1977
  • 18
  • 12
  • 7
  • +1
38 Comments
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
If you can connect to the server externally and email is flowing fine on there my guess would be a connection/dns issue in the office. I would start with the basics:

1. Can the laptop see the mail server when it's internal - can you ping it/access it/does the hostname resolve correctly?
2. Is it using autodiscover? If so does the internal record resolve correctly?
3. If you add a dns record for the external hostname of the server but put it to the internal IP does it connect/work?
4. Check the Outlook autodiscover/connection status (ctrl + right click the Outlook icon in the notification pane on windows) this should tell you what Outlook is trying to connect to.  
5. Can you access the webmail inside the office from the laptop - does it work?
6. Does the SSL certificate have the internal server name listed on it?

There's a number of reasons it could be so it's a case of narrowing them down one by one.
0
 
LVL 11

Expert Comment

by:hecgomrec
Comment Utility
The reason is simple:  Outside the organization the client is able to find both servers as their public name is assigned properly.

You should do the same in your internal DNS, so the clients can find your server name.  You should have DNS records for both of your domain names:  mail1.yourdomain.com-->10.63.1.6  ;  mail2.yourdomain.com-->10.63.1.9

Don't touch anything else as you mentioned outside the organization is OK, this mean your settings are correct on the servers, you just need to update your DNS records so both servers can be reached by their public name within the organization.

This is by default, most of today's routers/firewalls will not allow an internal loopback, because the public address is valid but is requesting the point of origin, therefore it will block the package and you will get the error message.

Good Luck!
0
 

Author Comment

by:dangermouse1977
Comment Utility
That makes perfect sense, but I'm afraid I don't know enough about DNS to make those changes confidently... would you mind offering a little more assistance?

If I open DNS on my domain controller, under the heading "forward lookup zones" I can see many entries on the right hand side, including one for the local servername of the original mail server (mailserver1) this host record points to the internal IP address of the server (which is 192.168.10.**) it's timestamped as "static"

The new mail server is called (mailserver2) and has a local IP address of 10.10.100.** (it also has a different gateway to any other server)

Are you saying that I need to create a new "host A" record with "mailserver2" as the name and 10.10.100.** as the IP address?

The reason I ask is that I cannot even ping 10.10.100.** from the domain controller
0
 

Author Comment

by:dangermouse1977
Comment Utility
I've run the tests that Andy noted as well, just for completeness of information:

1) No - cannot ping, DNS doesn't resolve ( I wouldn't expect it to though as it's on a different subnet, see above)

2) Yes, we're using autodiscover - if I ping "mail.domain.co.uk" or "autodiscover.domain.co.uk" from the workstation then it resolves to the correct external IP address (94.200.114.246)

3) See my comments above regarding DNS, happy to test this but need more detailed instructions.

4) I can't get that far at the moment, the name won't resolve when trying to set up outlook (I deleted the account after I'd set it up at home)

5) No, OWA doesn't work either when tried on an internally connected computer

6) No, the SSL certificate doesn't as I was warned by Digicert when I bought it that certificates are no longer allowed to have .local names or internal server names on them so the only names on the cert are the external ones.
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
From the information provided am I correct in thinking that both email systems are completely separate - separate internet lines, separate routers, no connectivity between either domain/network?

If both networks effectively use the same router it could be an internal loopback as noted above by hecgomrec (I've seen similar issues with a Watchguard router system that we have that has multiple networks on it for multiple external IP's but unless we allow each network to talk to each other internally it won't connect externally either due to loopback issues).

If both systems are completely separate then this shouldn't be an issue unless there's some routing problem with the ISP between the two IP's. May be worth running a tracert from the workstation to the 94.200.114.246 IP to ensure there's connectivity there. The fact that it brings up the external IP for the secondary server on the workstation correctly would indicate dns is fine (if there's no connection internally then it would use the external address accordingly).

It would also be worth checking the autodiscover configuration to ensure it's got no internal address assigned to it as this could cause problems (especially if there's no internal ssl).
0
 
LVL 11

Expert Comment

by:hecgomrec
Comment Utility
It looks like you have 2 network on LAN.  One is using 192.168.10.0 /23 and the other one 10.10.100.0 /23.  Like I mentioned before the external IP will be found yes... but the router will not allow the traffic cause the request is coming back to source point.

I don't know why your other server is in a different network, this will prevent machines from finding each other.

If you need to keep it like this but still want the 192.168.X.X network to find this server you will have to add another IPv4 to the NIC.

So in your DNS Forward Lookup Zones you will create a new zone called yourservername (as your external DNS matching your settings on Exchange) and create the host record for it.

 Example:  If your Exchange Name is mail.domain.co.uk this is how your new zone should be called and there you will create a new host record pointing to the new IPv4 IP 192.168.X.X you just assigned to the server's NIC.
0
 

Author Comment

by:dangermouse1977
Comment Utility
I do have both servers attached to the same internet connection and the same Fortigate router/firewall.

They're on different networks on the same LAN as I was told in a previous question on here that it wasn't possible to have 2 exchange servers on the same lan. If that's incorrect then I could change the local IP address of the second exchange box to 192.168.**.** address.

If that won't work then how do I add another V4 to the NIC - I think I have the DNS bit sorted in my head.
0
 
LVL 11

Expert Comment

by:hecgomrec
Comment Utility
I don't know why you got to this scenario.

Exchange 2013 can handle several domain names using the same server.

You can have several sites in the same domain, as long as they have their own server and of course they are routed on the firewall to the correct server.  Don't forget your DNS to point to do the same.
0
 

Author Comment

by:dangermouse1977
Comment Utility
I got to this scenario as we basically run 2 businesses from the same office with the same people and the email has to be completely independent. Outlook and exchange seem to be incapable of supporting this.

When I tried installing the second domain on our existing exchange server and setting both accounts up in each user's outlook it simply wouldn't work. Outlook kept defaulting to the primary account
0
 

Author Comment

by:dangermouse1977
Comment Utility
Having defaulted to the primary account outlook would then either deliver all mail to only one of the mailboxes or it would driver mail to the 2 mailboxes but when you clicked reply the reply would only send through the primary account.

Because of these issues I decided it was best to have a completely separate exchange server for this new project ( which again is a different company with the same staff in the same office)

It sounds to me as though my best bet is to simply change the IP address of the new server to be in the same subnet as the existing servers, not worry about changing the fqdn and that should sort everything?
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
There's a few options available here.

The first (and probably the easiest option) is to create a route between the two networks so they can talk to each other. This way the internal workstations should be able to see the secondary email server on it's internal address (and you can add dns records accordingly).

Regarding changing the server IP - be very careful doing this. For starters if the secondary email server is also a Domain Controller I would strongly recommend not changing the IP as this will cause a lot of issues. If it's just exchange then this is possible but it's not a simple case of just changing the NIC's IP - you also need to readjust dns/iis bindings. If doing this I would recommend firstly stopping all exchange and iis services, change the IP, adjust dns and ensure that the 2nd server can see everything fine on the 1st subnet (and vice versa) then start the services back up and adjust relevant bindings in IIS if required. If you change the IP while exchange is running it will go bonkers.

The other option you could have gone with is to add the second domain to your primary email server as an accepted domain. Then setup separate email accounts for the secondary address rather than adding them to the existing accounts (you'd need to setup separate recipient policies for generating the email address or manually amend the accounts). Outlook 2010 and onwards has no issues running two exchange accounts at the same time and if you are using a version below that you can still always use OWA to access one account and Outlook on the other.
0
 

Author Comment

by:dangermouse1977
Comment Utility
Understood.

For sake of time expediency let's go with option 1 and create a route between the 2 networks.

I've got myself so confused with this now that I think it best to ask you to lay out what I need to do step by step if you'd be so kind I'd really be grateful, I've tried so many things over the last month that I've tied myself in knots!
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
Hi

Unfortunately I'm not familiar with your actual router system so wouldn't be able to give you step by step instructions on creating the route between the network on there - you would need to contact your supplier/manufacturer/support for instructions on how to to do that. Basically all you want to do is create a route that allows one network to see the other and pass traffic between them.

Once it's done both email servers should be able to ping each other and you should be able to ping the 2nd email server from any machine on the main network.

Once that is done on your main dns server you will need to create a new forward lookup zone for the secondary domain and add A host records for the external address to point to the internal IP (i.e. mail.domain.co.uk to go to 10.0.0.x). This should allow Outlook to then connect and allow use of OWA as well.
0
 
LVL 11

Expert Comment

by:hecgomrec
Comment Utility
As I said, just try by adding another IP address to the server on the 192.168.x.x scope (make sure is out of DHCP range) and add the zone as I mentioned before pointing to this ip.
0
 

Author Comment

by:dangermouse1977
Comment Utility
Ok, so we're getting closer i think.

I added 2 "policy" entries to my Fortigate router, one allowing traffic from the LAN port to the specific port that the new mail server is plugged in to and one for the reverse.

This has now enabled me to ping from my desktops to the new mail server using the mail server's 10.10.100.** IP address but (crucially I think) not by its local network name (mailserver1)

If I've read Andy's instructions correctly, in order to make the network name resolve I need to make a new entry into the DNS of the domain controller to point "mailserver1" to 10.10.100.** (do I need to do anything to the DNS on the new mail server??)

I tried to make outlook connect to the new account using the 10.10.100.** address for the mail server but that didn't work - will the DNS entry sort that as well?

Finally, can you walk me through creating the relevent DNS entries, I don't know the first thing about DNS I'm afraid!!
0
 

Author Comment

by:dangermouse1977
Comment Utility
Just another piece of information that may be salient as well, whilst all of my normal servers, workstations etc are on one domain (lets call it XXX.local) the new mail server is on a different domain (yyy.local)
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
On your primary dns server go into dns and open up/expand forward lookup zones.

Have you got a zone in there for your secondary email domain (in this example lets call it domain2.co.uk)?
If not create one by right-clicking the Forward Lookup Zone and click New Zone.
Go through the options and create a primary zone with the name of your domain (i.e. domain2.co.uk)
Once this is done it will add the zone to the forward lookup zones.
Open this up and right-click in the right-hand pane, create a new A host record with the external hostname of your secondary mail server (i.e mail.domain2.co.uk) and put the internal IP address of that server (i.e. 10.0.0.x).
Wait for this to propagate to the workstations.

If this works correctly the external hostname for the secondary mail server should resolve to the internal IP on internal devices and be reachable from the systems on the primary network/domain.

Note that if your secondary domain also has a website and other web-based services that the internal systems need to reach you will need to add A host records for these to your internal dns as well otherwise internal systems may not be able to reach them.
0
 

Author Comment

by:dangermouse1977
Comment Utility
OK, have followed that and created the records. One question though, when I create the new host A record if i type the full mail.domain2.co.uk then it seems to auto complete to mail.domain2.co.uk.domain2.co.uk

Is that right or should I just be putting the word mail on its own in the "name" field of the new host record?

I hope that is clear, if not I'll take some screenshots
0
 

Author Comment

by:dangermouse1977
Comment Utility
Ignore my last, think we're past that now.

Current situation:

From the workstations I can
Ping new servers IP address
Ping mail.domain2.com (resolves to the external IP address 94.200.***.***)
Ping new servername.fulldomain.com

Outlook still cannot connect the mail though
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 
LVL 13

Expert Comment

by:Andy M
Comment Utility
The mail.domain2.com should be resolving to the internal IP of the server rather than externally. You will need to alter the A host record for that in dns.

It would also be worth checking your internal url's in exchange on the domain2 server and seeing what they are coming up with (could be causing some conflicts/confusion in exchange). I generally would edit the internal url's to match the external urls.
0
 

Author Comment

by:dangermouse1977
Comment Utility
Ok, have changed the DNS as you note, a ping now resolves mail.domain2.com to the internal IP address of the mail server, Outlook still cannot connect.

Where do I go to check the Ineternal URLs in Exchange, I have opened Exchange Admin Centre and I can't see anything pointing to domains?
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
The autodiscover url's have to be accessed/changed within exchange management shell.

If you run "Get-clientaccessserver | fl" it will give you information, including what the autodiscover url's are currently set as.

If it's pointing to anything but mail.domain2.com you will need to set it using "set-clientaccessserver -identity <server> -autodiscoverserviceinternaluri <url>"

Note it does need the \autodiscover\autodiscover.xml after the domain url
0
 

Author Comment

by:dangermouse1977
Comment Utility
Made those changes as well, autodiscover URLs now read as you note... still no change, Outlook seems to simply be unable to see the mail server no matter what method I try to use (IP address, servername etc)

Starting to seriously run out of patience now, it really shouldn't be this difficult to connect an e-mail client to an e-mail server that's sat not 10 feet from it!
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
Hmm, sounds like something else is going on here.

Can the workstations reach the webmail on that server (i.e. https://mail.domain2.com/owa), if so does it show any certificate warning at all? Can they log onto it fine?
0
 
LVL 11

Expert Comment

by:hecgomrec
Comment Utility
Please remember, if you did not create all DNS records needed on your server, outlook will never find on its own the server.

This means, you will have to create DNS for mail.domain2.com, mail.domain2.com/owa, autodiscover.mail.domain2.com, etc.

Like a host file, where you can redirect a host (mail.domain2.com) to any IP address in a local machine, DNS server will do the same for the entire organization.  So if you create a forward lookup zone called: mail.domain2.com with service records for http, https to point to your server's IP (10.x.x.x) it will find only that unless you also add the other possible host names.

You can still leave it as is.... just to let you know why is not working....  I know time is everything so create the account manually and write the correct name of the Exchange server (internal: server2.local), username, password, etc., then proceed to "More Settings", open connection tab and enable Outlook Anywhere, click on Exchange Proxy Settings,  enter your server's external URL (mail.domain2.com), at the end of the window locate Authentication settings and select the one that matches your server settings and click on OK and finish the setup.  If everything goes well it should as for the user credentials to access the mailbox, type the info in and choose to remember the credentials.

Note: In the server your IIS should be redirecting all request to mail.domain2.com to mail.domain2.com/owa since is there where all validations occurs when you request any service (activesync, owa, ecp, etc.).  If you need to make sure this is working you should try from outside the organization your owa by typing one at a time: http://mail.domain2.com, it should bring you to https://mail.domain2.com/owa and finally https://mail.domain2.com should do the same.

Good Luck
0
 

Author Comment

by:dangermouse1977
Comment Utility
OK, I'll post replies to the 2 messages above seperately for ease:

Andy... no, OWA is not reachable from the workstations, I simply get a 404 error (also tried to ping mail.domain2.com/owa and that won't resolve, though pinging mail.domain2.com resolves to the 10.10.100.**)
0
 

Author Comment

by:dangermouse1977
Comment Utility
Hecgomrec

Understood on the DNS stuff but I cannot create DNS records for mail.domain2.com/owa, when I go into the domain2 forward lookup zone and right click, select new host A record, the FQDN is already specified as simply domain2.co.uk I cannot add the suffix

It is also not possible to add the mail account manually, when I try and do that, clicking next on the first "add new account" screen simply sends Outlook off trying to find the server, it then hangs and I can go no further.

Tried your tests from outside the organisation.

http://mail.domain2.com gives me a "server error" 403-Forbidden, access is denied message
https://mail.domain2.com does redirect to https://mail.domain2.com/owa as you note.
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
It sounds to me like there's something going on with IIS on the server - possibly restricted to allow access to certain IP's? The fact that mail.domain2.com is resolving to the IP on the workstations and is pingable is indicating that the workstations can see the server.

The /owa is basically asking the server if the workstation can access the owa directory in IIS - you don't need a separate dns record for it (just need the main mail.domain2.com dns record) and it won't ping either.

It may be worth having a look at IIS to see if there's any restrictions or errors in there.
0
 

Author Comment

by:dangermouse1977
Comment Utility
Nothing that I can see amiss in IIS, to be truthful I never touched it after installing it when I first installed Server 2012 on the server. it will be set to whatever the defauts are upon a normal install
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
Hmm, only thing I can think of is maybe try rebuilding the virtual directories on the Exchange server - in Exchange 2010 and 2013 you can do this within the exchange management console/admin center (links below). On 2007 or earlier it's a bit trickier - the following links should help.

http://www.exchangeranger.com/2011/03/how-to-recreate-all-virtual-directories.html

http://technet.microsoft.com/en-gb/library/ff629372%28v=exchg.141%29.aspx

http://exchangeonline.in/re-create-owa-virtual-directory-exchange-2013/
0
 
LVL 11

Expert Comment

by:hecgomrec
Comment Utility
Have you try my recommendation from within the organization, what are the results?  Can you try https://10.10.100.**   and https://10.10.100.**.

The redirection should be done on your IIS any request to http://mail.domain2.com should be sent to https://mail.domain2.com/owa.

Setting an account in outlook manually, should be the option at the end of the screen when you press to add an account, the next button should be grayed out unless you start typing name, email address, etc.

I don't think you have any problems with your IIS settings regarding names (host names) as it resolves and behaves properly when you are outside... your issues are just internal ones.

Once you get your redirection fixed you should be ok to create your outlook account.  You must first need to get your OWA working internally. So when you type on your browser mail.domain2.com it should redirect you to https://mail.domain2.com/owa.
0
 
LVL 27

Expert Comment

by:Steve
Comment Utility
Hi,

Hope you don't mind another opinion, but the redirection of mail.domain2.com to mail.domain2.com/owa isn't really important. Many people set up the redirection because they prefer it, but it has no effect on the functionality the system.

Have we established which version of Exchange this is? 2010 or 2013?

As far as I can see you've had some good advice from the guys above so you're definitely going in the right direction, but I recommend concentrating on why you cannot see OWA between the 2 networks as Outlook is unlikely to work if OWA doesn't (especially if using Exch 2013)

It's worth confirming that each network can resolve & ping the appropriate internal IP addresses for the other network's mail server:
mail.domain.com (or whatever your FQDN is)
autodiscover.domain.com

Also, do you have valid SSL certs for the FQDNs (including autodiscover)?
0
 

Author Comment

by:dangermouse1977
Comment Utility
I'm running Exchange 2013

Valid SSL certs are in place (purchased from digicert, they include only the external names as I was advised that internal server names are not allowed on certs anymore)

As far as pings are concerned, from outside the office, both mail. and autodiscover. resolve to the external IP address of our internet connection provided by our ISP (94.200.114.***)

From inside the office, both mail. and autodiscover. resolve to the internal IP address of the mail server (10.10.100.**)

in both cases pings work perfectly
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
Have you had any further joy with this at all?

When you do the internal pings does it work both ways - from workstation to server and from server to workstation?

What happens if you try to access webmail on the server itself (i.e. https://127.0.0.1/owa)?
0
 

Author Comment

by:dangermouse1977
Comment Utility
Nope, no further joy and I'm pretty much out of time now unfortunately.... I think I'm going to have to abandon the whole project as it just won't work for some reason.

using IP addressing, pings work both ways, from server to w/station and w/station to server
using hostname, cannot ping the server from w/station and cannot ping workstation from server
using hostname.domainname.com can ping server from w/station and pinging w/station from server resolves to a completely different IP address in a range we don't use.

on the server, https://127.0.0.1/owa results in a security warning page saying that the certificate doesn't match (I imagine this is because you can no longer have internal names on a security cert so our digicert only has the external names on it), if you then click the "advanced" link you get a message saying "this server could not prove that it is 127.0.0.1 its security certificate is from mail.domain.co.uk" there's then a link to go unsecured, if you click that then the OWA page opens normally.
0
 
LVL 13

Expert Comment

by:Andy M
Comment Utility
Hmm, sounds like something to do with routing still going on. As we've established OWA is working (your server test indicates this is fine - the certificate warning is expected) and external connections are working.

Sorry I couldn't be more help on the matter. If you do decide to pick it back up in the future I would probably start by looking at the routing/connection as the actual exchange system itself sounds like it's working correctly.
0
 
LVL 11

Accepted Solution

by:
hecgomrec earned 500 total points
Comment Utility
Please create proper DNS records on your server so workstations can find the server.

You should create a site with your domain name (domain.co.uk)
Then create a site for this domain (mail)
Add an MX record mail.domain.co.uk to your IP server 10.10.100.*
Add a Host record to your server: 10.10.100.*
Finally, you may add special services records like POP, SMTP, IMAP to it if you need this to be resolved internal also.

If this doesn't work, Check on your Fortinet firewall for any rule preventing the workstations from accessing other networks within the LAN and turn them off, delete them or add the network to the list.

Is been a lot since I worked a Fortinet but there are places you can do that, check them out!

Good Luck!
0
 

Author Comment

by:dangermouse1977
Comment Utility
Bingo

Those changes you note have been made and now the clients can see the server, though I have an issue with security credentials... I shall create a new question for that though.

Thanks to all who've helped,
0

Featured Post

Integrate social media with email signatures

Is your company active on social media? Do you also use email signatures? Including social media icons in your email signature is a great way to get fans for free. Let all your email users know you’re on social media quickly and easily, in a single click.

Join & Write a Comment

Easy CSR creation in Exchange 2007,2010 and 2013
This article explains in simple steps how to renew expiring Exchange Server Internal Transport Certificate.
In this video we show how to create a Distribution Group in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >>…
In this video we show how to create a Shared Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Sha…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now