Export (0) Print
Expand All

Preparing for Windows 2000 Server

Chapter 12 from Introducing Microsoft Windows 2000 Server, published by Microsoft Press

On This Page

Overview
Single Machine Installation
Deploying Large Sites
Upgrade Paths
Setup Walk-Through
Migrating to Windows 2000 Server
Summary

Overview

Now that you have mastered the features and technologies included with Microsoft Windows 2000 Server, you can begin implementing it in your network. Careful planning now can save a great deal of time and energy in the future, and this chapter will guide you through the process.

This chapter also provides detailed instructions on using the setup routine and points you toward other resources you might need to efficiently deploy Windows 2000 in your network.

Single Machine Installation

The simplest way to install Windows 2000 on a single system is to put the CD-ROM directly into the system's CD drive. If a Windows operating system is already installed on the computer, inserting the CD should bring up a prompt to upgrade the system. If you decide to start the setup process manually, execute winnt32.exe if you are using Windows 95, Windows 98, or Windows NT 4.0. From any other operating system, run winnt.exe.

If this is the first operating system to be installed on the computer, you must boot from either the CD-ROM or the floppy disks. Many new computers allow booting directly from the CD-ROM, which provides a very quick upgrade path. Alternatively, you can insert the first of the four setup floppy disks and follow the instructions to install the operating system.

winnt Command Syntax

Run winnt.exe from the command prompt to start the Windows 2000 setup routine from an MS-DOS, Windows 3.1, or Windows for Workgroups 3.11 system. The winnt.exe program accepts many different command-line parameters that change the behavior of setup and optionally automate the process. The following parameters can be used:

  • /u:answer_file specifies an unattended install using an answer file. Answer files are used to bypass the interactive questions asked of the user and can even be used to automate the setup process completely.

  • /e specifies a command to be executed after setup has completed. This can be used to launch automated application setup routines to complete the installation.

  • /s:sourcepath specifies the path to the Windows 2000 setup files. This option is required only if the files are not located in the current folder.

  • /t:tempdrive specifies which partition setup will use to store temporary files. This option is not recommended.

  • /rx:folder copies a folder you create into the system folder. This option is generally used to copy drivers that are not part of the standard Windows 2000 distribution. This option can be used multiple times to copy multiple folders.

  • /r:folder specifies that a folder be created during setup. This option can be used multiple times to create multiple folders.

  • /a allows you to choose accessibility options. This option is not recommended for most users.

  • /i:inffile specifies the file name of the setup information file. By default, this is Dosnet.inf. This option is not recommended.

Note: The command line options listed for winnt.exe are the ones that were available at the time this book was written.

winnt32 Command Syntax

Run winnt32.exe to start the Windows 2000 setup routine from a Windows 95, Windows 98, Windows NT 3.51, or Windows NT 4.0 command prompt. The winnt32.exe program can accept many different command-line parameters that change the behavior of setup and, optionally, automate the process. The following parameters can be used:

  • /debug[level][:filename] creates a debug log file containing information at a specific level. If you do not specify a level, 2 will be used. Level 2 records warning information. If you do not specify a filename, the log file will be written to C:\winnt32.log. Use of this option is recommended because the log file can be used to diagnose setup problems.

  • /s:sourcepath specifies the path to the Windows 2000 setup files. This option is required only if the files are not located in the current folder.

  • /tempdrive:drive_letter specifies which partition setup will use to store temporary files. This option is not recommended.

  • /unattend is only useful for upgrades. All answers are decided based on information in the current operating system. No answer file is required.

  • /unattend[num]:[answer_file] specifies the name of an answer file. Answer files are used to bypass the interactive questions asked of the user and can even be used to automate the setup process completely. The optional num parameter is used to specify the number of seconds between the time setup finishes copying the files and the time setup restarts.

  • /udf:id[,UDF_file] specifies an ID in a uniqueness database file (UDF). A UDF makes changes to an answer file that varies from one machine to another. For example, you can specify computer names in a UDF. This allows a single answer file to be used for all systems on a network.

  • /cmd:command_line specifies a command to be executed after setup has completed. This can be used to launch automated application setup routines to complete the installation.

  • /copydir:folder_name copies a folder you create into the system folder. This option is generally used to copy drivers that are not part of the standard Windows 2000 distribution. This option can be used multiple times to copy multiple folders.

  • /copysource:folder_name operates in much the same way as /copydir, but the folder is removed after the setup has completed. This option is for transferring additional setup files to the system.

  • /syspart:drive_letter is used to copy setup files to a partition of a hard disk and mark the partition as active. The hard disk can then be installed in another computer. When that computer is started, the next setup phase starts automatically. This option must be used with the /tempdrive:drive_letter option.

Deploying Large Sites

When installing fewer than 20 systems, manual installation is efficient. However, for larger networks, it is worth the administrator's time to automate as much of the setup as possible. One method of automation is the answer file. Using answer files is a complex topic and is described in more detail in the Microsoft Windows 2000 Server Resource Kit (Microsoft Press, 1999).

Another method of automating setups—remote installations—was described in Chapter 3. Remote installation is the most efficient way to perform a massive deployment of Windows 2000 Server.

Upgrade Paths

You can upgrade any of the following operating systems directly to Windows 2000:

  • Windows 95

  • Windows 98

  • Windows NT 3.51 SP5

  • Windows NT 4.0

Older operating systems, such as Windows NT 3.1, Windows NT 3.51, and Windows for Workgroups, will require either an upgrade to one of the systems on the previous list or a brand-new installation.

Note: If you must perform a new installation for a user, consider configuring the system as dual-boot for a week so he or she can use the previous operating system if any problems arise with an application.

Whether you are creating a new installation or upgrading an existing system, the same installation options apply. You can choose to load the software from a network file server, from a local CD-ROM, or by using the remote installation features discussed in Chapter 3.

Setup Walk-Through

The manual setup routine will take you through a series of steps in a very wizardlike fashion. Make sure you have the necessary information gathered before you begin the setup routine. Here is what you'll be asked for:

  • Licensing Agreement Be sure you have purchased a license for every instance of Windows 2000 you install.

  • Regional Settings If you speak English and live in the United States, you can accept the defaults here. Otherwise, select the proper language and locale settings as discussed in Chapter 2.

  • Computer Name and Administrator Password Both can be changed after setup has completed. Be sure to set an administrator password, or your machine will be vulnerable to attack as soon as the network starts.

  • Date and Time Settings Choose your time zone. If this is the first operating system installed on the computer, you will need to set the time as well.

  • Network Settings If you are using Dynamic Host Configuration Protocol (DHCP), select the default and your network settings will be automatically configured. If you must enter the settings manually, you should enter at a minimum an Internet Protocol (IP) address, subnet mask, and default gateway. If you are using DNS (Domain Name System) or Windows Internet Name Service (WINS), specify those servers as well.

  • Domain Settings If you are joining a domain, you must have a user account that has rights to create a computer account in the domain.

  • Upgrade to NTFS If you are not dual booting with an older operating system, you should upgrade your partitions to the NTFS file system. If you choose to skip this step now, you can always upgrade later.

  • Name and Organization

  • Provide Upgrade Packs Upgrade packs are used to modify applications to work with Windows 2000. Check with your software vendor to obtain an upgrade pack. They will not always be necessary—most software should run on Windows 2000 without modification.

Migrating to Windows 2000 Server

Most major Windows 2000 deployments will be upgrades from previous Windows operating systems. This section guides you through the entire migration process, breaking it down into six phases. Phase One, Streamlining, reduces the complexity of your network by cleaning up resources. Phase Two, Updating, improves the chances of a successful migration by upgrading current operating systems and applications to the latest patch versions. Phase Three, Planning, creates a detailed plan that will be followed for the remaining phases. Phase Four, Testing, validates the system architecture and flushes out any problems before they cause downtime. Deploying, Phase Five, is the actual installation of Windows 2000. Finally, in Phase Six, Determining Success (or Failure), you evaluate the work and determine whether you have succeeded.

Phase One: Streamlining

Make the migration as simple as possible by cleaning up your existing network and servers. This is good practice at any time, but it is particularly helpful when preparing to upgrade. Audit your user account database to ensure there are no duplicate or unused accounts. Clean unnecessary files off every server and desktop system, and make sure that all systems have plenty of free space.

If you have been putting off any hardware upgrades necessary to support your existing environment, perform them now. Windows 2000 Server is more demanding of hardware than Windows NT Server 4.0 is.

Phase Two: Updating

Windows 2000 Server is a major update from Windows NT Server 4.0, but many of the new features have been released as add-ons. Make your migration smoother by implementing these updated components on all of your servers several weeks before you plan to upgrade. In particular, make sure Windows NT Server 4.0 Option Pack (with Microsoft Internet Information Server 4.0 and Microsoft Transaction Server) and Windows NT 4.0 Service Pack 4 are installed.

Note: Both Windows NT Server 4.0 Option Pack (with Microsoft Internet Information Server 4.0 and Transaction Server) and Windows NT 4.0 Service Pack 4 are available for free download from http://www.microsoft.com.

Your system's architecture might need to be revised. If you are using any network protocols besides TCP/IP, remove them. All other major network operating systems support TCP/IP, so compatibility is not an issue.

Next, make sure you are taking full advantage of the TCP/IP services included with Windows NT Server 4.0. Make sure you have WINS servers on your network and that all clients are configured to use them. Also, consider using DHCP; while it's not suited to all environments, you should take advantage of it if possible.

Implement a DNS structure and configure all client machines to use DNS. If you currently use UNIX for DNS services, migrate the servers to Windows NT for tighter integration with Active Directory. If you cannot migrate all DNS servers, create a separate subdomain that can be handled exclusively by Windows NT servers. Having a separate subdomain fits into the Active Directory architecture very well and limits the damage if problems occur during migration.

Windows 2000 networks do not require NetBIOS networking. To ease the transition from NetBIOS, make sure that all systems have a primary host name that matches their computer name. For example, if a server has the computer name KURT and a fully qualified domain name (FQDN) of www.company.com, give it an alias in the DNS database as kurt.company.com. After you have performed these updates to your network, you are ready to begin planning the migration.

Phase Three: Planning

Several important tasks must be completed before you begin updating systems. The tasks are as follows:

  • Map out a system architecture.

  • Determine a budget.

  • Create a detailed task list.

  • Specify a timeline.

  • Identify human resource needs.

Creating a System Architecture

Windows 2000 has different architectural requirements than Windows NT 4.0. For example, your new architecture might not require multiple domains and so might need fewer domain controllers. Alternatively, you might need to add a DNS infrastructure, which would require purchasing additional hardware.

Take the time to create a diagram of the new architecture and itemize any necessary additional hardware and software. You will use this itemization when determining a budget and creating a task list.

Be sure each of your Windows 2000 systems meets these specifications:

  • 166 MHz or higher Pentium-compatible microprocessor or Alpha CPU

  • 32 MB RAM for Windows 2000 Professional; 64 MB RAM for Windows 2000 Server

  • 2-GB hard disk with a minimum of 500 MB of free space

  • VGA monitor and video card

  • Keyboard and mouse

  • A network card or CD-ROM to retrieve the setup files

Determining a Budget

Migrating all the systems on a network is a major undertaking. It is much better to specify a budget beforehand than to run out of money halfway through a project, so take some time to estimate costs and verify that the funds have been set aside. Several factors will contribute to the overall cost:

  • Hardware upgrades Any system that does not meet the hardware requirements for the new operating system must be upgraded. Be sure to include the cost of labor in the estimate.

  • New hardware If your new system architecture requires that additional systems be purchased, include the costs of the hardware and set-up in the budget.

  • Software upgrades This will vary depending on your organization's licensing scheme.

  • Overtime In most organizations, employees have a full schedule simply performing day-to-day tasks. Planning and executing a major upgrade will consume additional time that will cost the company money if it pays overtime.

Creating a Task List

Create a detailed list of discrete tasks that must be accomplished during the migration. Consider the following scenario: You are upgrading your Windows NT 4.0 domain to Windows 2000 Server and Active Directory. You plan to start the migration by upgrading the primary domain controller for your domain, SERVER-PDC. This system requires a processor upgrade to run Windows 2000 Server effectively. The task list you create might look like this:

  1. Verify that a processor upgrade kit and Windows 2000 Server software are available.

  2. Perform a full backup of SERVER-PDC.

  3. Inform users that SERVER-PDC will be taken offline.

  4. Synchronize all domain controllers.

  5. Promote SERVER-PDC to primary domain controller.

  6. Add the additional processor to SERVER-PDC.

  7. Synchronize all domain controllers.

  8. Promote SERVER-PDC back to the primary domain controller.

  9. Upgrade SERVER-PDC to Windows 2000 Server.

  10. Verify that everything is functioning correctly. If SERVER-PDC is not working correctly, remove the additional processor and restore from backup.

  11. Inform users that SERVER-PDC is back online.

By specifying each required step, you reduce the chance that anything will be forgotten. It is easy to forget to make a backup before upgrading a system, but skipping this step can have disastrous results if the upgrade does not work properly. Make sure several people in the organization review the task list to verify that no steps have been omitted. For large networks, start by creating a higher-level task list and dividing the list among different administrators.

Note: Always have a rollback plan! If any step fails, you should have a way to restore services to their original state.

Specifying a Timeline

Once you have created the task list, determining a timeline is easy. Determine how many hours of work are required for each task. Be realistic—leave extra time for human error and unexpected delays. Think about which tasks can be performed at the same time and which can only be accomplished after other tasks are complete. If you have the resources, you can have people working simultaneously on different tasks.

Identifying Human Resource Needs

Depending on the size of your network, migrating to Windows 2000 Server can take several months. During the migration phase, personnel will have to dedicate part or all of their time to upgrade tasks. Assign each task from the task list to a specific administrator. If you do not have enough people to accomplish the tasks within the given timeline, consider hiring consultants or changing the timeline.

Once you have identified who will participate in the migration, make sure they have the proper skills. Everyone is new to Windows 2000, so everyone will require some training, self-study, or both.

Phase Four: Testing

In an ideal world, all software would work as expected. Every administrator knows that networking is not an ideal world, so take measures to detect problems early. While planning, allocate time for software testing. Set aside a system, and install Windows 2000 Server on it. Then layer on the network applications you use and verify that each of them continues to work exactly as it did with Windows NT 4.0. Connect to the server with a variety of clients, and verify that the clients and the applications still function.

You will almost certainly uncover a few problems. It is obviously preferable to identify them in the testing phase when they will not cause user downtime. Troubleshoot any problems you find, and work with the software vendor's support groups to resolve the more difficult problems.

If you are upgrading desktop systems, be sure to test each of the different hardware platforms that you use. It helps if you can verify that all of your systems are on the Windows 2000 Hardware Compatibility List, but performing a test install on surplus hardware is the most reliable way to identify hardware compatibility problems. If your plan includes user-guided automated installations, have a user walk through the installation process to verify that the documentation you have provided is clear and accurate.

Note: The most recent Hardware Compatibility List is at http://support.microsoft.com/default.aspx?scid=KB;EN-US;131900&.

Even a small flaw in your plan can cause a great deal of downtime for your users. Testing is an extremely important phase, and it can save your organization copious amounts of money. Do not allow this phase to be bypassed because of a short timeline. But do not spend so much time on testing that you waste resources. Except in very large migrations, it is neither necessary nor productive to test every permutation of software and hardware, client and server.

Once you have resolved any problems revealed by the testing process, you are ready to begin implementation.

Phase Five: Deploying

Your planning and testing efforts will pay off during the upgrade to Windows 2000. Small organizations with less than 50 clients and servers should migrate all systems at once. Plan to do the work after hours when it will cause the least downtime for users.

It is not practical to upgrade medium to large organizations in a single phase. Instead, start by migrating primary domain controllers to Windows 2000 Server. Leave a full week after the first systems have been upgraded before migrating the backup domain controllers.

By migrating servers in small numbers and allowing the updated servers to function in a production environment, you are performing a final stage of testing. After all the servers have been upgraded, migrate user systems one department at a time. By taking small steps, you limit the worst-case scenario to partial downtime rather than total downtime.

Phase Six: Determining Success (or Failure)

After you have completed each phase of your migration, perform a series of tests to validate functionality. Even if everything is working okay, be prepared for users to raise support issues. There are usually surprises when performing a major upgrade. Deal with problems as they arise, and be prepared for the worst-case scenario: rollback. If any postmigration problems are severe and cannot be quickly resolved, restore your systems from the most recent backup and return to the testing phase.

I hope that everything will go as planned. You, the users, and your organization will all benefit from the improvements offered by Windows 2000.

Summary

This chapter has introduced you to the Windows 2000 Server setup routine and the steps required to successfully migrate your network. Depending on the type of installation you are performing, you must choose among running setup directly from the network or a CD-ROM, automating the process, or using remote installation functionality. You must also decide whether to upgrade systems or to perform a clean install of the new operating system.

A successful migration requires careful planning. For large networks, a dedicated project manager should run the deployment. Even small networks require careful planning to stay within budget, stay on time, and keep lost productivity to a minimum.

The above article is courtesy of Microsoft Press. Copyright 1999, Microsoft Corporation.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.

Link
Click to order


Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft