Okay. You’ve already downloaded the “Migrating an NT 4
domain to Windows 2000” technical white paper from the Microsoft website.
You may have even said to yourself “Holy smokes, it’s a trillion pages
long. How is a guy ever going to find time to read this thing?” A very
salient question indeed.
Okay. You’ve already downloaded the ‘Migrating an NT 4 domain to Windows 2000’ technical white paper from the Microsoft website. You may have even said to yourself ‘Holy smokes, it’s a trillion pages long. How is a guy ever going to find time to read this thing?’ A very salient question indeed.
For all the white papers, magazine columns, and yes, books, I
have read that cover the topic of Windows 2000 (Win2k) migration from NT 4, I
have yet to come across one that outlines the conversion process specific to
small and mid-sized organizational networks. The overwhelming majority of the
information that is out there addresses the concerns faced by enormous,
multinational, multi-domain, heterogeneous networks out there. Alot of technical
concepts and considerations that are addressed in print just don’t apply to
smaller networks. While Win2k offers administrators a rich and powerful set of
tools and functionality, some of that Win2k functionality may not necessarily be
applicable to these smaller networks.
While there is certainly a need for providing migration plans
and strategies that focus on the largest of corporate networks, there is also a
great (and mostly unfulfilled) need for addressing the technical issues that an
administrator of small and moderate-sized networks must face in making
the move to Win2k. That is the impetus for this series of articles. While alot
of the information I will highlight in this series is universally applicable
across all networks alike, I am not going to spend significant time
discussing the more advanced Win2k features that smaller networks
will not employ in the first place.
For the purposes of developing a migration strategy, we must
make general assumptions regarding the particular network(s) this article is
attempting to deal with. Based upon that statement, I am going to assume that
your network adheres to the following guidelines:
Your NT environment is comprised of a single, flat domain.
While there may be multiple network segments or subnets, all users log into
the same domain irregardless of their location.
Within your network, you presently have a dedicated (at
least available) connection to the Internet, and your domain name space is
registered with one of the “domain banks.”
Your network is TCP/IP-based. Although other protocols may
be used, IP needs to be one of them used for server-to-client (and vice
All remote subnetworks are connected via reliable WAN
links. Obviously, network services are only as reliable as the medium that
There is currently employed a successful name resolution
method somewhere within your NT environment. While DNS is strongly
encouraged, there are still plenty of companies making use of WINS, LMHOSTS
and HOSTS files. As long as name resolution occurs consistently, there is no
While this list is in no way, all inclusive, it does provide
what I consider to be a framework that this column will be able to address. If
your particular network doesn’t satisfy every one of the items, don’t worry.
Read on and you can certainly adapt the information given to your specific
technical circumstances. With that being said, let’s get started.
Step 1: The Foundational Basics
Before we can move ahead with planning the migration, it is 100%
essential that you verify your particular hardware (and yes, software) will
peacefully coexist with Win2k. While the actual Win2k installation routine will
give you a rudimentary assessment of your software applications, this is one
step in which it pays to do your homework before you get to class. Check the
Windows 2000 Hardware Compatibility List to ensure that your
server/workstation/PC and its peripherals have been tested and verified to run with the new OS.
Be meticulous in your efforts. A smooth Win2k transition depends greatly on how
much effort and confidence are present with regards to your existing hardware
Once you have verified that your hardware and software
applications are Win2k-ready, it is a good idea to check your BIOS
compatibility. Because Win2k incorporates several advanced power management
features along with Plug and Play support, your BIOS revision can potentially
cause a serious problem if it is unable to support ACPI. Check with your BIOS
manufacturer for Win2k-aware updates. One of my favorite websites for BIOS
updates can be found at driverzone.com.
Now that you have successfully ensured that your existing
hardware, software and BIOS version are able to sustain operations following a
Win2k migration, it’s time to begin laying the groundwork for the actual
installation. At this point, it is sound practice to determine what your order
of server upgrades will be. There is alot of information and opinions out there
that vary greatly on this point. How you proceed to upgrade your existing NT 4
servers depends upon your network layout and your desired objectives.
This mile marker represents a significant juncture for a Win2k
migration because of a few reasons. First, it is necessary now that you decide
if your overall goal for the migration to get your network to native mode (all
NT servers have been upgraded to Win2k) as quickly as possible, or to introduce
Win2k and its functionality into your network in a more gradual manner.
Secondly, your decision ultimately chooses the order in which your existing NT 4
servers will be upgraded to Win2k. Make no
mistake, this is a very important decision. If you are seeking the more gradual
implementation approach, the initial Win2k installations may actually offer very
little change to
your network thus giving you more time to plan the Active Directory portion
of Win2k migration. All in all, the more gradual plan impacts your network
considerably less (on an immediate basis) than does the straight shot to native mode.
If your goal is to take your network to native mode as quickly
as possible, you have very few options on how to accomplish it.
In order to gain the benefits of Active Directory (we will discuss AD shortly),
it is necessary that the NT domain be in native mode. Sounds simple enough, huh?
Not really. Native mode necessitates that your Primary Domain Controller (PDC)
be upgraded to Win2k first. This is a big deal because the PDC is involved in
many administrative operations. Replication, synchronizing with Backup Domain
Controllers, and authentication are all “background” processes that an
NT 4 PDC performs. After you upgrade the PDC to Win2k Server, virtually all of
these, and many other, processes are transformed into their Win2k
If you find yourself grappling with the mixed mode versus native
mode decision about your network, I suggest you consider the following
guidelines. These are merely a subset of a multitude of considerations that
could be present in your particular network, but it serves well as a guide to
making your decision more intuitive.
Consider native mode if:
Your target window for upgrading all NT 4 domain controllers
is relatively small.
The software applications running on the domain controllers
is Win2k approved.
Technical support staff has a strong understanding of DNS.
Active Directory and its inherent benefits are of prime
Network client operating system is Win2k Pro, NT 4, or Win
Consider mixed mode if:
You want a slower deployment of Win2k Server throughout your
Mission-critical software apps are not Win2k-ready.
Network client workstations are running Win 3.x, Mac OS, MS
As you can probably see, alot of the decisions you will face
while planning a migration, are actually made for you by your environment. None
of these items are to be considered show-stoppers, but Win2k represents a
greatly different animal than NT 4 administrators are accustomed to. I recommend
that you invest signficant time and thought into how a migration could impact
your network, positively and negatively.
Coming up in Part II
In Part II of this series, we will begin looking into the
preparation of your DNS namespace. Anyone that has implemented Win2k will likely
advise you to spend thoughtful time laying out your namespace. Everything from
authentication to security depends upon it in the newest version of Windows.
We’ll take a high level view of DNS, what administrators need to consider before
dropping the Windows 2000 Server CD into their trusty CD ROM drive.