best practice 1

[terry712]

currently at central site have 2 servers for root forest of 2003 ad - both run AD integrated dns zone for parent
each points to each other as primary and then themselves as secondary address

i have a seperate child domain at a seperate physical site - again these are setup similar way and these forward to the parents above - the dns is delegated from above zone

i' m going to put another domain into this tree/forest what ever you want to call it - this will be upgraded from nt4 pdc and then the upgraded pdc will be removed when new dc's put in . there will be 2 servers at the same location as the root servers as this is the central point

what is best way to install the dns for this
install it on the pdc during the upgrade and then install dns on the 2 servers that will replace this - and just let the AD replicate the zone and then delegate from above

or if during upgrade i point it to one of the root servers will it create a seperate child dns zone in this server or ?

 

[ITPangaeaArchitect]

From a replication standpoint, I say stay away from delegation of zones for child domains....I have pasted in a template for recommended DNS config that I send to customers...currently your DNS config is not what it should be...although it is workable...it still has many chances and glances to break you and bring your environment to its knees:

DNS configuration (if you are running Windows 2000 and do not use this configuration, you may experience issues anywhere from replication to authentication of users, 2003 can also experience same issues):

**Note: I have included a custom method I use that I refer to as standardization. The standardization technique has the potential to decrease the frequency of “business down” issues that are caused by name resolution by approximately 80-90% (assuming long term downage here…examples are file replication, and user logons). The standardization method does take more time to initially set up/configure, but the downtime saved is easily worth the extra effort. To use the standardization method, you must take inventory of all DCs in your domain. Meaning, you will need the IP address, as well as the AD site they belong to. It is easiest to write this information down into a word or text document and then rearrange them in site order (this way you can go site by site instead of searching a list for site members). I would also make a mark by the PDCe so as to not confuse anything (example below). In the recommendations below, the standardization method will always be the method to follow the “-OR-“ (which follows the simple, acceptable method).
EX (servername – IP – sitename; PDC will be servername-PDC-IP-sitename)---
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston

**this should make it substantially easier to go through the process without losing your place. It also has the additional benefit of creating DC documentation for later reference.

Standardization method PROS/CONS---
PROS:
-Has potential to decrease major issues caused by name resolution almost in their entirety (I have not seen any name resolution related problems whatsoever any of the times myself, or a customer I recommended the method to, performed this method). This method allows us to maintain DNS name resolution site by site because, for example, if a failure on the PDCe occurs, all members in the PDCe site, since they point to the same alternates in the same order, will fail back to the same DNS server, and begin registering there instead…if that replica DC fails, the same still goes…each time we have a failure all members of the site will fail to the same DNS server, thereby maintaining DNS name resolution almost indefinitely. I do not guarantee no failures at all, but it would substantially decrease the chances of them occurring at all.
CONS:
-Takes longer to configure
-If roles are transferred (specifically the PDC role), complete reconfiguration is required enterprise wide to reflect the new PDCe (this is a step that should be taken whether using standardization or simple method)


*****

Default advanced TCP/IP properties (settings should match these)---
DNS server address is listed
Append primary and connection specific DNS suffixes is marked (radio button)
Append the parent suffix of the primary DNS suffix is checked (checkbox)
Register this connections addresses in DNS is checked (checkbox)
Everything else should be blank
Ensure NetBIOS over TCP/IP is enabled and not set to default (mainly for Win2003)

Domain controllers---
PDCe faces itself and itself only for DNS, with defaults in advanced tcp/ip properties
Replica DCs in the enterprise (all sites) point to the PDCe for preferred DNS, and themselves as alternate, with defaults in advanced tcp/ip properties
-OR-
All replica DCs in site with the PDCe point to the PDCe for preferred, and all the same replica DCs in the same order beginning with the replica DCs in the site with the PDCe, and then out of site replicas (you choose alternate DNS order based on preference and site membership, there is no certain way you need to do this, although I would stick to site by site method…I normally base off of machine performance…such as a 3ghz processor w/ 4GB RAM would be listed before a 2ghz w/ 4GB RAM). Replica DCs in different sites than the PDCe should use the same methods, using the PDCe as preferred, and then the same order for alternates, beginning with replica DCs in the same site as first alternates, then moving to replica DCs in other sites.
EX (using server names and info from example above and adding on complexity):
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston


P: = preferred DNS A: = alternate DNS
DOM1DC1 – Dallas site - P: 10.0.1.2 & A: None
DOM1DC2 – Dallas site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7
DOM1DC5 – Dallas site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7
DOM1DC3 – Houston site – P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6
DOM1DC4 – Houston site - P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6
DOM1DC6 – Houston site - P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6


Domain members (servers and workstations) in site with PDCe:
Face PDCe as preferred DNS, and replica DCs as alternates in the same order specified on replica DCs in that site
EX:
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston

WORKSTATION1 – Dallas (PDCe) site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7


Domain members (servers and workstations) outside of PDCe site:
Choose a replica DC in that site to act like the PDCe’s DNS role for DCs (there is no special way to go about this…i.e.; if we choose DOM1DC3 to be preferred for all clients is fine, on the same note, so is choosing DOM1DC7 if we wanted). The top alternates will be replica DCs from the local site, then other sites replica DCs. The reason for not doing the same DNS config on clients outside of site of PDCe as we did on replica DCs in that remote site is to save time and bandwidth for DNS name resolution.
EX:
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston

WORKSTATION2 – Houston site – P: 10.0.1.4 & A: 10.0.1.5, 10.1.0.7, 10.0.1.2, 10.0.1.3, 10.0.1.6


-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[anthonymeluso]

ADgod,

Awsome post. Thanks for the tips.

Anthony

 

[GlenJohnson]

Brandon, have you put that into a FAQ? Might consider it. Good post.

Glen A. Johnson
If you're from the Illinois or Florida area, check out Tek-Tips in Chicago IL
To help with disaster relief for hurricane Katrina, click here