Answers are inline below.

--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.


> Since we lack sufficient budget to perform a proper migration 
> we'll need to do in-place upgrades to our domains and then 
> consolidate some of the rogue domains into our structure (as 
> well as cleaning things up after upgrade). All domains will 
> remain mixed mode until we're able to complete application 
> testing.  One of our main drivers is the need to consolidate 
> domains as well as eventually eliminate our dependence on the SAM.

I'm one who strongly believes in a migration rather than upgrade, especially
if you're cleaning up a full mess topology. I also just don't like in place
upgrades of anything, but that's just me.

One possible option to avoid large budget costs for migration is to do a
leapfrog approach. Replace your current production NT4 domain controllers
with desktop machines (I'd leave the PDC as a 'real' server and swing at
least a few others). Once that' done, rebuild those production grade boxes
into the new AD Domain Controllers and migrate to them. If possible, you
could target the smallest domains first, allowing a quicker recouping of
their hardware resources.

Also keep in mind that the Microsoft ADMT does about 75% of what the
commercial migration tools do, and its free.

> 1.     One of my concerns is following the upgrade of the PDC 
> it will be
> the only AD domain controller in the domain.  Our current DNS 
> settings for servers and workstations are to our enterprise 
> DNS servers, which are not AD-compatible.  We anticipate 
> creating a new DNS structure for AD and then using forwarders 
> to the other DNS servers for non-AD-related address 
> resolution.  It's my expectation that NT4.0 clients w/o the 
> AD client will not be impacted by this in any way.  Is this correct?

My last company bought a 1500 person company with just that arrangement - 1
AD DC, the rest were downlevel NT4 BDC's. It wasn't the best design, but it
worked. They happened to have run that way for over a year, but that was
more political than technical.

There are two ways you can handle AD DNS - make your AD DNS zone a child
zone or completely separate zone from the primary DNS, or delegate the
Microsoft specific subzones in the existing DNS zone to the AD Domain
controller. I much prefer the former method, but the latter will work. As
long as your existing DNS servers are aware of the AD DNS zones, either by
delegation or pulling a zone transfer of the zones, it shouldn't matter if
all your clients continue to point to the enterprise DNS servers.

One interesting thing I've seen in production is that BIND servers
functioning as secondaries of your AD zones will forward client registration
requests (ie DDNS requests) to the server they use as the master for that
zone.

> 2.     It's also my expectation that the Win2k clients will 
> be impacted
> depending on their configuration.  For example, Win2k client 
> that does not have the DNS domain for AD listed in the suffix 
> for the client nor in the DNS search order would not realize 
> that there was an AD domain controller in their midst and 
> would continue to authenticate to the domain as they had 
> prior to the upgrade.  And Win2k clients that have the DNS 
> domain for AD in their suffix or search order would 
> prefferentially authenticate against the new AD DC to the 
> extent that they would begin to ignore their local BDC. This 
> is one area of significant concern as we don't want to 
> overload any of the domain controllers.  I thought there was 
> a client reg entry that would eliminate this.

This really can be handled a few ways. The easiest is to set the DHCP scope
to pass the desired DNS suffix out as part of the lease. Its also possible
to set the default suffix through either the registry or the client GUI, as
part of the domain change.

I *think* this might be automatic following the upgrade, assuming the
clients' default setting of automatically update the default suffix when
changing domains hasn't been changed, but I've never really looked.

> 3.     Should we, once we complete the upgrade of the PDC, 
> build a new DC,
> move all Operations Masters roles to the new DC and rebuild 
> the old from scratch as Win2k, so as to avoid any legacy 
> issues?  We'll also be bring up other AD DC's to split the 
> roles up between boxes.

I would strongly suggest doing this - you really want a clean install of
everything whenever possible.

> 4.     If something goes wrong and after an hour or two, or 
> sooner, find
> that we need to turn off the AD DC and fire back up the 
> offline BDC and promote it to PDC, are the Win2k clients 
> going to be OK?  I thought I remembered that if a box 
> authenticated against the domain using Kerberos it never 
> would go back to NTLM.

I believe that particular behavior was fixed in a service pack (maybe SP2 or
3) but I don't remember for sure.
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to