Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

When I try to install Exchange 2010 on my server 2008 R2 server I get a warning during the prerequisites check:

Warning: setup cannot verify that the 'Host' (A) record for this computer exists within the DNS database on server: 90.195.200.12.

The goal of this Exchange setup is that I'm able to sent email in my local domain as well receive/sent email through the public domain name.

Some information about my setup This Server is going to be a dedicated exchange host and has the following IP setup: (IP's are examples and not the real IP's ofc)

Local VLAN NIC:

  • IP: 10.10.50.22
  • Subnet: 255.255.255.0
  • No gateway
  • DNS: 10.10.50.1 (is domain controler with authoritive DNS)

public WAN NIC:

  • IP: 90.195.200.148
  • Subnet: 255.255.255.235
  • Gateway: 90.195.200.145
  • DNS: 90.195.200.12 | 190.160.230.14

My public domain - exampledomain.com

  • A record: mail - IP: 90.195.200.148
  • MX record IP: 90.195.200.148

As I'm seeing now the exchange setup is looking for the A record in one of the DNS servers in my Public WAN NIC. And ofc this is not where my A records are defined. I have those A records in 2 places: 1. In the domain controler DNS (the private nic) 2. In the online dns registration of my public domain (exampledomain.com)

My question is... is this warning going to be a problem? Can I do something better in my setup so that this warning will go away? Please advice?

Edit: Some additional info. Today I've tested dns functionality with dcdiag and I've also used nslookup from various places to see if I could locate my mail server through IP/domain name/computername. All is fine.

Then as a test I disabled the Public WAN NIC for a sec and started the Exchange setup again. Now the set-up goes through all checks WITHOUT any issue.

Somehow this leads me to believe that this is warning I can safely ignore but still would be nice if anyone can shed some light on why Exchange set-up seams to prefer the NIC that holds the Gateway... (at least this is my careful conclusion)

share|improve this question
    
updated question with various tests I've done –  Joost Verdaasdonk Jul 9 '12 at 16:54
add comment

2 Answers 2

This is a warning you can ignore. Hope you have a firewall somewhere between your public nic and the internet :)

share|improve this answer
    
Hi Michel, Thanks then I'll go and install it now! About the firewall the server has one and its on! ;-) DMZ would have been preferable but did not make it. Before this server goes public we will see if we can improve security a bit more. So if you have more ideas let me know! :) –  Joost Verdaasdonk Jul 9 '12 at 17:10
add comment
up vote 0 down vote accepted

After installing the Exchange server today I found that indeed this warning was not a problem for the installation process. (But it does have indeed a DNS watch-out you need to be aware of.)

However there was another problem that I spent several hours on figuring out and that was that all services worked on my server EXCEPT Outbound email. The send connector on the Hub transport was configured fine but it took me a lot of troubleshooting to figure out how to make my server send email.

The solution was that DNS resolution was conflicting on the Hub transport. To fix this I had todo the following:

  1. In the server configuration | Hubtransport select the transport on the right and select properties
  2. On the Internal DNS lookups tab set the NIC that belongs to your private domain to resolve dns in your domain.
  3. On the External DNS Lookups tab set the NIC that belongs to your WAN IP to resolve your public domain.

Because the default is to look on all available IP's all mail was hanging in the Outbound Queue. After altering these NIC settings emails where flying out like popcorn!

I hope this will help somebody else who installs an internet-facing exchange server. :)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.