A Small and Mid-Sized Organization's Guide to Migrating to Windows 2000 (Part I)
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.Overview: 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 versa) connectivity.
All remote subnetworks are connected via reliable WAN links. Obviously, network services are only as reliable as the medium that carries them.
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 problem here.
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 and software.
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 counterparts.
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 concern.
Network client operating system is Win2k Pro, NT 4, or Win 9x
Consider mixed mode if:
You want a slower deployment of Win2k Server throughout your network.
Mission-critical software apps are not Win2k-ready.
Network client workstations are running Win 3.x, Mac OS, MS DOS.
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.