I have two public dedicated web servers that I want load-balanced using windows NLB. I want to take advantage of DFS replication to keep all my files in sync between the two servers.
To do this I need to configure Active Directory, which also requires DNS Server to be installed.
I know I'm a little over my head here, but hopefully I can get some answers on how to correctly set this up.
Can I use the 'dcpromo' wizard to setup a domain controller and DNS Server on my server?
What should I use for the FQDN, my public domain name (DNS setup externally) is house-mixes.com, should i use something different such as house-mixes.local?
Would installing the DNS server affect anyone accessing my web server to view the house-mixes.com website?
I just want to ensure I don't deny myself access to the machine after configuring and rebooting.
UPDATE:
A few of you have pointed out that DFS may not be ideal in my situation, well I will explain my scenario a little more to hopefully find an elegant solution.
I am load balancing for 2 reasons, high availability and to spread the load (it's a pretty busy website).
Each of the 2 servers are identical both with around 10TB of the same data, an average of around 10-15gb of new data gets uploaded by users of the site each day, as well as a few GB deleted, files are never modified…just created or removed.
I need the uploaded files to be replicated pretty much instantly to the other machine otherwise the media files will work on one machine and not the other until they are in sync.
At the moment I have a SQL server database installed only on one of the machines, I do want to setup another SQL server as a backup on the other machine, but I will leave that for another question.
At the moment I am using some software called ViceVersa Pro, which is basically what rsync does but has the ability to do this when any file changes are recognised. This software has worked ok so far, but I was looking to try and do this without any third-party applications if possible.
Thank you!
Best Answer
Your comment "...ensure I don't deny myself access to the machine..." causes me to suggest, first, that you really should mock this up using virtual machines in a lab before you begin working on your real production machines.
dcpromois the tool use to "promote" a stand-alone Windows Server machine into being a Domain Controller (DC). Being the first DC in your Active Directory (AD), you will be prompted to install the Microsoft DNS Server onto the machine during promotion. The machine will be configured to refer to itself for DNS. It should use itself and only itself for DNS (until you promote a second domain controller, at which time the 1st DC should have the second DC specified as a DNS server and the converse).Microsoft's recommendations re: AD domain names are a good first item for you to read. The "tl;dr" version is that you should be using either a subdomain of a domain you already own (ad.domain.com), or a domain name you own that isn't in use for public Internet services (someotherdomain.com).
Using your "real" public domain name (which Microsoft and I recommend against) creates a "split horizon DNS" situation where the DNS servers responsible for the AD believe they're authoritative for "domain.com" while other DNS servers that run your public Internet presence think they are authoritative for "domain.com". As a result, you get the make-work job of synchronizing "A" records between the DNS servers for "domain.com" services that need to be accessible to both servers that a members of the "domain.com" AD domain and Internet users.
I'd name the AD domain something like "ad.house-mixes.com" and go from there.
Your servers that will be members of the AD domain need to have only DNS servers specified in their own TCP/IP configurations that are running on DCs. If you only have a single DC (which, itself, is not a good idea) then the member servers should only have the IP address of the DC (which will be running a DNS server) specified as their DNS server.
The public shouldn't be able to access your DCs' DNS servers. Being accessible to the public doesn't create a security vulnerability, per se, but it can leak information. You don't want potential attackers learning anything about your AD configuration via DNS.
Third-parties accessing your web site are directed there by, presumably, some already-existing authoritative DNS server. As long as that's left intact the domain membership of the web servers (and what DNS server they're using for queries they generate themselves) won't cause any change in the public's ability to access your web site.