Adding second Domain Controller to Windows 2000 domain

E

electech98

[H]ard|Gawd
Joined
Jul 12, 2002
Messages
1,800
OK, there's something I just can't figure out:

I am trying to add a second Windows 2000 domain controller to our current domain. I don't want to add another domain or a sub-domain...just a second DC for our current domain for redundancy and load balancing. Eventually, when we open our branch (I work at a credit union) the new DC will be relocated there to serve the DNS, WINS, and print server requests of the workstations at the branch. At the main office here, we use 192.168.1.X private IP's with a 24-bit subnet. At the new branch, we will be using 192.168.2.X IP's with a 24-bit subnet. The main office and the branch will be connected two ways: a T1 between routers, and via VPN through business-class DSL that the main office currently has and the branch will have when we set it up.

Our original DC, which will stay here at the main office, is serving DNS and WINS. I want the new DC to serve DNS and WINS as well. I want each domain controller to be able to server DNS and WINS for both the 192.168.1.X and 192.168.2.X networks in case one of the DC's goes down. Everything (AD, DNS, WINS) needs to be replicated because of this.

So, I have the new DC on the network (currently on the 192.168.1.X network), and I have setup AD on it. Everything has transferred fine as far as AD Users and Computers, etc. I setup DNS on the new DC, and the Forward Lookup Zone seems to have transferred fine. I then created a Standard Secondary Reverse Lookup Zone on the new DC to be a copy of the Reverse Lookup Zone on the original DC. Then I tried to mess with the Forwarders settings, such that I named the original DC as a Forwarder to the new DC, and vice versa. In each DNS zone, I listed both DC's as Name Servers for the zones. Also, on the original DC I created another Reverse Lookup Zone for 192.168.2.X, and created a Standard Secondary copy of that zone on the new DC. However, I listed the new DC as the primary name server on that 192.168.2.X RLZ, whereas on the 192.168.1.X RLZ the original DC is the primary name server, as it is on the AD-integrated Forward Lookup Zone.

Then I tried setting up WINS on the new DC. I authorized it in AD, then set the originial DC as a replication partner. On the original DC, I set the new DC as a replication partner in WINS.

I also went into AD Sites and Services and set the new DC to have a Global Catalog, even though the original DC hosts it as well.

Yet, with all this, I think I might be messing with too much stuff, or not setting things properly to begin with. I have gotten DNS errors regarding forwarding, such that it tells me that I should not restrict recursive entries, even though each DNS server does not have recursive entries restricted. I have gotten other DNS errors as well, but I do not remember which ones in haste to write this out for the forums.

Am I doing something wrong here? I want this to work now while I have the new DC on the same network as the original DC, so that I can be better assured of success when I move it to the 192.168.2.X network when we configure the branch. How would you guys set this scenario up such that all AD services are replicated on each DC, so that if one DC were to go down, all users in both networks (.1.X and .2.X) would be able to still authenticate and request DNS and WINS successfully?

Sorry for the long post, but thanks in advance for your help!

EDIT: added some DNS settings info.
 
Make sure all your DNS zones, forward and reverse are Active Directory integrated. You don't need forwarders between them in any configuration. AD integrated zones will trade zone information automatically through AD replication. You don't need to manually create any of the nameserver records either. Either server will be considered authoritative for any zone it stores (and they'll both be storing identical copies of all the zones you have.)

Having both DC's as GC's is a very good idea. If one DC fails and it's the only GC you'll have a hell of a time getting your GC back. There is an island issue with GC's if it happens to be on the Infrastructure Master, but that only applies in a multi-domain environment, and only if there are other non-GC DC's in the forest. In short, you don't have to worry about whether or not your Infrastructure Master is a GC in your setup.

WINS setup sounds fine as well. WINS is AD unaware and can be considered on it's own. In any event, it's best to have all your clients at both locations set with DNS and WINS server settings in the IP configurations to point to their local WINS/DNS as primary and the remote WINS/DNS as secondary. We're also combining DNS and WINS on the same DC's for a large worldwide forest (over 350 locations) and haven't had a problem yet (DNS and WINS only installed at hub sites, not at branches.)

I strongly recommend considering 2003 though. Almost every detail about AD has been greatly improved in AD, especially when you uplift the forest and domain functional levels to 2003 native mode.

Note that DC's don't register everything they should in DNS so long as they have DHCP addresses. This behavior is intentional as it helps make it easier to initially stage DC's at a central location before shipping them out.

Sounds like you're mostly on the right track, but have a little smoothing out to do on the DNS side of things.
 
Hey, thanks for the help...I didn't even think about converting the Reverse Lookup Zones to be AD-integrated. I'm trying that right now, and we'll see what problems that fixes. I'll let you know what comes of it. Thanks again!
 
OK, so I posted my questions on another forum, and one of the guys suggested this:

Although you didn't ask, make sure that you've configured AD correctly when you move the DC to the branch. Go into Active Directory Sites & Services and create subnet objects for 192.168.1.0 and 192.168.2.0. Assign 192.168.1.0 to Default-First-Site-Name and create a Site for the branch and assign 192.168.2.0 to it. When you move the DC, you'll have to manually go in and move the server object for that DC to the new Site. If you don't do this, you're going to have tons of problems with replication.

I think that sounds pretty accurate, but I didn't think about that yet.

Good suggestions, guys. Thanks! You have no idea how much I learned in the past few days.
 
OK, seems to be a bit of a problem that has come up:

Since we do not have the new branch open yet, we have simulated a default gateway for the new 192.168.2.X network using our firewall to redirect traffic. I have put the new DC on the .2.X network with the simulated gateway address and such on it. With all that, it seems I am able to communicate with the old DC, but cannot browse to any other computer on our 192.168.1.X network. Furthermore, it seems that replication between DC's is one-way at this point - the new DC has successfully replicated info from the old DC, but the old DC seems to not be picking up any changes to AD (for example, Sites and Services) from the new DC. So the new DC seems to be able to pick up the changes from the old DC, but not the other way around.

A big example of this, as mentioned above, is in AD Sites and Services. On the new DC, I had created the new site, the new subnet, and moved the new DC server object to the new site. There is a site link between the sites, and everything seems to be setup correctly there. However, I just noticed today that the old DC reflects none of those changes in AD Sites and Services. Hence, it seems to not be pull-replicating correctly with the new DC.

Am I missing something here? Let me know if I can provide any other information.

Thanks!
 
You must log in or register to reply here.
Back
Top