By the time you read this you will probably only have five months to wait until you see Windows 2000 on the shelves. If you think there is nothing you can do until it’s released, this article will hopefully get you moving and show there is a lot you can do now. There are a number of areas in which you can start to prepare: your company’s actual network, which will consist of one or more protocols and the services provided thereon (such as DNS, WINS etc.); the client machines and the servers.

Tasks for the network

Domains are now DNS names and so you will need an Internet domain name, which can be requested from Network Solutions (http://www.networksolutions.com). You don’t have to register your Windows domain root with Internic but it may lead to complications if you don’t and connect to the Internet. As you may be aware, the Domain Name Service is part of the TCP/IP suite of protocols and this forms one of your first pre-Windows 2000 deployment actions, the standardisation of TCP/IP as your intranet’s primary protocol. TCP/IP is not an option in a Windows 2000 domain and all machines that will participate in a 2000 domain must have TCP/IP installed. Communication with the domain controllers is primarily LDAP (Lightweight Directory Access Protocol) which relies on IP as the data carrier. Windows NT is supplied with a built-in TCP/IP implementation and each machine has a unique 32-bit address. If your machines are or will be connected to the Internet it is important that the IP addressing scheme you use has been allocated by Internic to avoid conflicts with other machines on the Internet. Alternatively you can use any addresses on your local intranet and then use a proxy server for Internet communication that will hide your company’s internal addressing scheme.

DHCP

Rather than keeping large, cumbersome, manual records of IP addresses used by each machine, which can also lead to addresses being lost if a machine is reinstalled and a new IP address given, use the Dynamic Host Configuration Protocol method of IP address allocation.

DHCP allows one or more servers to be configured with a service that allows clients to send out a request for an IP address and the DHCP server will respond with an IP address from its database that is not currently in use for the client to use. This has the advantage of guaranteeing two machines won’t have the same IP address (as long as you configure the servers correctly) and there will be no wasted IP addresses since no machine ‘owns’ an IP address permanently. Another advantage of DHCP is that it can send the client much more than just an IP address. Gateway information, WINS servers, domain names and other IP-related information can all be sent to the client along with the IP address including DNS server addresses, which brings us to the next important pre-2000 task.

DNS

Since Windows 2000 domains are DNS names, a method of resolving these names is necessary and due to the complexity of the DNS entries and special record types, lmhosts won’t cut it and so as well as TCP/IP, DNS is a core component of every Windows 2000 domain tree. For example a DNS server hosting savilltech.com could handle domains legal.savilltech.com, sales.savilltech.com, etc., anything with savilltech.com in the domain name. There are many DNS implementations for Windows NT including a very capable one with Windows NT Server. Current DNS implementations all do basically the same thing, however, in Windows 2000 you will need some of the special abilities of DNS 5.0, most importantly, service records and dynamic update so implementing the Microsoft DNS implementation now is probably in your interest. You will need to upgrade DNS prior to installing your first 2000 domain but the upgrade from DNS 4.0 to DNS 5.0 is almost automatic.

One final TCP/IP related component is WINS which makes up for DNS’s (current) inability for machines to dynamically register their name to IP address pairing and allows machines to register their NetBIOS name to IP address mapping. This allows other machines to query the WINS server with a NetBIOS name and be able to communicate with the machine by its IP address.Workstations and servers also use WINS to find domain controllers (although it’s not the only way) by querying the WINS server for records of type <1C> which is reserved for DCs. Alternative methods of domain controller discovery include local broadcasts and the LMHOSTS file. In a pure Windows 2000 environment, NetBIOS names are not used due to 2000’s DNS foundation and so WINS servers are not needed and the service can be disabled on the servers and clients. During the migration to 2000 however, clients can use WINS to find the domain controllers and each other, so you should ensure WINS is deployed on your network.

The clients

We talk of installing TCP/IP on the clients, but what client? This forms the next objective for your pre-2000 installation, upgrading all clients to Windows NT Workstation 4.0 with Service Pack 5 installed. There are a number of reasons to upgrade to Windows NT Workstation 4.0:

• Microsoft will supply an Active Directory bolt-on for Windows NT 4.0
• Upgrading to Windows NT 4.0 now will make the upgrade to Windows 2000 Professional (the 2000 equivalent of Windows NT Workstation) easier since NT 4.0 Workstation and 2000 Professional share a common architecture in many important areas.

Depending on your current hardware you may need to upgrade elements of some computers or buy entire new ones so they meet the specification for Windows NT 4.0 but you obviously want to look beyond this so ensure any new PCs meet the Windows 2000 hardware requirements. There are a number of options open to your Windows NT 4.0 rollout depending on your current operating system and if the hardware meets 2000 requirements.

No supported upgrade path from Windows 95/98 is possible (although you can upgrade from Windows for Workgroups, Why!?) for Windows NT 4.0 and so if you have this operating system you will need to install Windows NT from scratch. If you take the reinstall approach you will need to make sure you backup all the users’ data and settings, however profiles from Windows 9x are not usable in NT. If this seems daunting you may want to wait until 2000 is released as an upgrade from 9x will be possible to 2000 which would result in all your applications and settings being preserved.

Deploying Windows NT 4.0 Workstation

Upgrading from NT 3.51 is supported and would enable you to install 4.0 over your existing installation and keep all your application and configuration settings. In the other scenarios you should use one of the following methods to deploy Windows NT 4.0 Workstation:

• Manually install Windows NT 4.0 on each machine. This requires the least preparation but will take the longest to implement in any medium/large size company.
• Buy new PCs with NT 4.0 pre-installed. Obviously very little work but again in medium/large organisations a large amount of customisation may be necessary. At a minimum, network configuration and domain membership will need to be completed. If your current hardware does not meet the minimum required for 2000 this may be your best option.
  Some PC manufactures (such as Dell) will be selling machines with Windows 2000 Beta 3 installed with free upgrades to the final product but do you want to be running unsupported, beta software on your live networks?
• Perform an unattended installation on the machines. Windows NT allows a script to be used to specify the settings used by the installation and so no user intervention is needed. Applications can also be installed using the SYSDIFF tool. This requires some preparation but makes the actual deployment very easy.
• Cloning installations. Perhaps the easiest method is to create an NT installation, install all the applications, configure the machine then just clone the entire system to a file and then distribute to the other machines. Software such as Ghost can perform this image copy however you should first use the SYSPREP tool from Microsoft before cloning which solves the SID duplication problem.

The Security Identifier

The last option above raises another pre-2000 install action point. When Windows NT is installed, at the start of the GUI phase of installation a Security Identifier or SID is created for the installation which is used for local machine purposes. If you clone a machine after set-up is complete, the SID will also be cloned. This does not cause a problem for computers in an NT 4.0 domain since a domain SID is given to each machine when joining the domain. It does form a major problem in a Windows 2000 domain as the local SID is used and any machines with cloned SIDs will have major problems regarding security.

Microsoft does not support installations that were created using cloning techniques that did not either use SYSPREP, or the system was cloned at the point of installation before the GUI phase started (and so no SID had been created yet). To fix the duplicate SID problem there are a number of software products available:

What these products do is generate a new SID for the machine and replace and reference the old SID in the machine’s registry. Make sure the client machines are up-to-date with Service Packs and hotfixes (this is also important for Y2K compliance) and also that they are using the NTFS file system. FAT drives can be converted to NTFS using the command below:

C:\>convert <drive>: /fs:ntfs

If you convert a system or boot partition the conversion will take place at the next reboot.

The servers

The above covers all the main client actions. You should also pay attention to your domain structure and its content as some work now may save you a great deal later on. When you upgrade to 2000 your accounts and groups are migrated into the Active Directory and so it is very important to perform housekeeping on your accounts and groups, both local and global.

You should examine all user accounts and first identify any duplicate user accounts, after consulting with the user remove the duplicate since a user should only need one account. If you find a user needs multiple accounts you should re-examine your domain structure and it may be necessary to implement some new trust relationships. Also check for accounts for people that have left the company and disable then delete them. This is also a very good exercise to perform, as it will improve the security of your system. Having a large number of unused accounts will make it difficult to spot hackers. Identify any service accounts that are now redundant, for example Exchange service accounts and if Exchange is no longer used, delete the service account.

Whenever you delete an account it is very important to ensure the accounts do not own any critical resources and if they do you should reallocate ownership before deleting the account or you will have permission problems. Take care when deleting any account and make sure you have full information just in case you delete in error and have to recreate.

Groups

Groups are also an area for consolidation, however this will be more complicated than just deleting old user accounts and will require an examination of your organisation’s needs before you can start consolidating groups both local and global. That being said, once done it will aid your 2000 migration and ease the overall administration of the migrated domain. You should remember how groups should be used in domains: Users should be placed in global groups in the domain. Global groups from the domain should then be placed in local groups within the domain and trusting domains. Finally the local groups should be granted access to resources. The actual domains provide yet another area of possible consolidation, as the fewer domains there are, the easier the migration. The problem is NT 4.0 domains are not easy to consolidate and it may be better to consolidate domains after migration. Consolidating after the upgrade will enable you to move entire domain contents into Organisations Units in other domains within a forest allowing the old domain’s resources to be kept in a group. There are several ways to merge domains in Windows NT 4.0 ranging from dumping out users to a file using the resource kit addusers.exe command and then reading into another domain, through to complex tools such as: