All About Windows 2000 DNS, Sites, and Replication.
By Russ Bishop
http://www.boneville.net/lanadmin/
DNS is the
core name resolution system for Windows 2000, which is a refreshing change from
the WINS days of yore. However, this means that DNS must be setup and
working properly for your Windows 2000 Pro clients to login, replication to
occur, and the sites to work properly (that is, each client logs into a DC in
its site. This depends on sites being correctly specified and setup in AD and
DNS.) First I’ll describe how to setup a basic DNS system, then
deal with some specific issues.
Every
Domain Controller in your network ought to run DNS. There is absolutely no
good reason to do otherwise. Besides giving you good load-balancing
capabilities, you also get fault tolerance. DHCP can issue up to three DNS
servers to each client, so take advantage of it. Have DHCP running at a
specific location issue the Primary DNS to be the DC at that location. If there
are two DCs, have it point the Secondary to another
DC. Have the third server point to a DC over your WAN, if available. This helps
ensure you don’t have a single point of failure on the client side.
Setting up DNS on a DC isn’t very difficult. Just install the service, and set it up to be “Active-Directory Integrated.” In the DNS Server properties enable scavenging of stale records for every seven days. Also setup a forwarder to the Unix DNS server. This ensures that any DNS names that we cannot resolve (which will be anything outside of msad.company.net) gets forwarded to the Unix boxes, which know about the outside world. The properties here are on a per-server basis, so you might want to setup these settings on each server that runs DNS.
Remember: In
the TCP/IP Properties for the Domain Controller, setup the Primary DNS server
to point to the DC itself. This step is VERY IMPORTANT. Let me say
that again, this step is VERY IMPORTANT. Do not EVER
use a 127.0.0.1 address; Always use the machine’s external address. You
can fill in the secondary address if you wish, but it isn’t required. I
recommend setting the secondary address to the Unix DNS Server IP if anything.
Now create
the “msad.company.net” forward lookup zone. You will want to set it to
allow Dynamic Updates (not “only secured.” There are specific issues related to
all that which would take 10 pages to explain, and that don’t apply to our
situation.) Go to the Zone Transfers and select “only to servers on the Name
Servers tab”. Then, go to the name servers tab. If you have any other DCs running DNS, they should appear here. Add the UNIX DNS
server to the list. This should be all that is required to get a basic DNS
setup going. Most other issues, like reverse lookup zones, etc are only
conveniences, and are not required to allow clients to login or to perform
replication. The settings here are replicated to every DC running DNS, so you
can set it once and forget about it.
Note: if you
see another forward lookup zone, such as “.”, delete it. The only forward
lookup zone that should exist is the one holding the domain in question.
The next
step is setting up Sites, in order to facilitate replication and intelligent
client login. Open up the Sites & Services control panel. It is worthy to
note that the site you see called “Default First Site” is the site that catches
all computers which have an IP address in a range that isn’t assigned to any
other site. It is a catch-all for anything and everything, at least at first.
Later, after multiple sites are setup, clients are liable to randomly pick a
site if their subnet doesn’t fall into any specific assigned range. It would be
a very good idea to ask the router guy or check your DHCP configuration
and find out ALL the subnets in use, including static ones and ones that are
assigned to servers, printers, and such, then enter
them into the proper sites.
The first
thing to do is rename this default site to a location identifier, typically the
main location. Go into the subnets and add a subnet that corresponds to this
site. You must then assign the subnet to that site. Repeat this process for
each of your locations that are connected at less than 10MBps. “Sites” linked
with 10Mbps or more do not need to be defined in AD; they can be part of the
site they are connected to. For example, if Site A is the main location, Site B
is connected to it with a T1, and Site C has a 11Mbps
wireless lan to Site B, there is no need to define
Site C in AD. Just make the subnets in Site C part of Site B.
Once this is complete, you must
start creating Site Links (Intersite-transports\IP). These tell AD how expensive a trip across the
wire is, as well as what sites have wires to other sites. A suggested rating
might be a cost of 100 for a T1, 500 for 512k-256k, and 750 for 128k. These
costs just tell AD how to rate a line if multiple ones are available. For
example, if a site has two links, one with a cost of 100 and the other with a
cost of 200, AD will usually send most of the traffic down the 100 link and
just a small amount down the 200 link. If a site only has one link to it, then
the cost doesn’t really apply, other than to tell it how much processor time it
should waste trying to compress the data before sending. You can also select a
replication frequency. Since only changes are sent, this data shouldn’t be very
large. I’d recommend 15 minutes for all sites as a good replication time.
Another
important thing to note about sites is that you can specify a bridgehead server
for the site. This means that all traffic coming in and out of that site will
go through that server, rather than letting servers in one site randomly talk
to servers in another site. If the bridgehead server is down, AD will randomly
pick another machine in the site to act in its place temporarily. For a very large
site, it might be best to pick a specific powerful machine to be the
bridgehead. You will almost always want to use IP as the intersite
transport; SMTP can only replicate the Configuration schemas, and not the
actual data partition.
Lastly,
don’t forget to actually move the DCs to their
specific sites when they are first promoted. If a DC’s subnet doesn’t match the
subnet for an existing site, the machine gets dropped into the Default First
Site usually.
Once sites and DNS are configured, you need to verify that Replication is working. You should give the servers at least an hour to replicate amongst themselves and reconfigure their information to adjust to the new site information you have provided.
There is a nifty utility in the
Support Tools folder on the Server CD-ROM, called “Replication Monitor.” Install
the Support Tools on every DC. That previous sentence was a command and not
an option, and one day you will be glad you did. Once they are installed, run “replmon”. Click the Edit menu, and add a server. Repeat for each of your DCs. Now
look at the status for each server and see if any are not replicating. If a
server shows that it isn’t replicating with one of its partners, there are
several issues to address:
A.
Check to see that the servers can ping each other.
B.
Make sure that both servers’ DNS entries for each
other point to the proper IP addresses
C.
If server A says it replicated fine, but server B
says it couldn’t contact Server A, check the DNS setup on Server B. Chances are
it has a record for Server A pointing to the wrong place.
D.
Run Netdiag and see if it
reports any errors or problems.
Once replication shows up as working properly, you should
have a basic AD framework setup, and you can move on to other specific issues.
Once DNS and replication are
setup, it is generally a bad idea to change a servers IP address (at least
according to Microsoft). Just be sure that is what you really want to do before
starting the process. It is a bit kin to changing the
Internal IPX number of A Novell server, but it can be done.
1.
Change the Server’s IP address
2.
Stop the NETLOGON service.
3.
Rename or delete SYSTEM32\CONFIG\NETLOGON.DNS and
NETLOGON.DNB
4.
Restart the NETLOGON service and run “IPconfig /registerDNS”
5.
Go to one of the other DCs
and verify that its DNS is now pointing to the new IP address of the server. If
not, change the records manually and give it 15 minutes to replicate the DNS
changes out.
6.
Run REPLMON and make sure that replication is working
now. You may have to wait a little while for things to straighten out. Give it
an hour or two if necessary.