none
Head node as AD Controller with two NICs

    Question

  • We have our head node configured as a AD Controller for our clients.  One NIC connects to the university's (CCNY) network for client access, and the other connects to the compute nodes on a private network (but still are members of the domain).  However, with this setup the DNS server (which must be running for the AD controller) has trouble.  It seems that multihomed AD controllers are not generally recommended, but I'm not sure how else to configure this system.
    Any tips?
    Thanks!
    Wednesday, October 21, 2009 3:01 PM

Answers

  • Thanks Dan.  (Just saw response today, not sure why it didn't alert me by email).
    We actually just used a layer 3 appliance to route between public and private networks.  This solved the networking issue, but now the compute node can't get out for Windows Update (per our site's IT dept. request, these computers should just exist in their private world).
    But I'll post a new question for that.
    Thanks again.
    • Marked as answer by elansey Thursday, November 5, 2009 11:35 AM
    Wednesday, November 4, 2009 9:10 PM

All replies

  • Hello elansey
    As you say multihomed DCs are not recommended, but I believe this is a supported configuration. From experience there are some things which can help in this environment...
    Check the bind order of your network interfaces, make sure that the internal NIC is listed first
    The DNS shouldn't have records for the public interface that is outside of the client network. Make sure that the DC/DNS doesn't have and doesn't listen on the external interface. To check that go to the external interface and disable the option "Register this connection's addresses in DNS" under TCP/IP advanced properties. Then from the DNS console make sure that only the internal interface is selected to listen for DNS queries.
    Make sure that you don't have incorrect routes configured.
    Check that clients point to the correct internal DNS server address ONLY, and that they can resolve the FQDN of the domain.
    Check the underscore (service) records in DNS & ensure that they are correctly configured for the internal interface address.
    Configure a forwarder on your DNS server to direct external DNS requests to your enterprise DNS infrastructure.
    There are a few other steps which may help, but this should be a good start.
    Cheers
    Dan
    Tuesday, October 27, 2009 9:57 AM
  • Thanks Dan.  (Just saw response today, not sure why it didn't alert me by email).
    We actually just used a layer 3 appliance to route between public and private networks.  This solved the networking issue, but now the compute node can't get out for Windows Update (per our site's IT dept. request, these computers should just exist in their private world).
    But I'll post a new question for that.
    Thanks again.
    • Marked as answer by elansey Thursday, November 5, 2009 11:35 AM
    Wednesday, November 4, 2009 9:10 PM