Chapter 3 - Deploying Windows NT Workstation on an Existing Client-Server Network
There are several methods for upgrading your existing network clients to Windows NT Workstation 4.0.
"Pull" installations are those in which the user performs the upgrade, using tools provided by the administrator. "Push" installations are those in which the upgrade is performed for the user by the administrator or technicians, either directly or through software such as Systems Management Server. The choice of which type to use depends on several factors, including the corporate culture, the willingness of users to perform the upgrade, and scheduling. For example, if you need all the computers in a department to be upgraded on a certain day, a push installation might be required, since some users might be out of the office that day, or simply might not have a chance to perform the upgrade that day. Push installations can often be done outside regular business hours to minimize the disruption of the users' workday. In many cases, you can ask users to perform an upgrade within a certain time period, after which the upgrade will be mandatory and will be performed for them. This approach is especially easy with Systems Management Server. This chapter discusses how you can use Systems Management Server to deploy Windows NT Workstation 4.0 throughout an existing client-server network.
Using Systems Management Server for Deployment
Systems Management Server helps you deploy Windows NT Workstation, or any software package, in the following ways.
Systems Management Server gives administrators of large networks an inventory of the computers on the network, which they can query to compile a list of the computers that are capable of running Windows NT Workstation 4.0. Systems Management Server also allows remote administration of utilities to prepare each computer for the installation or upgrade. Systems Management Server can then be used to create a package of installation procedures and a job to execute the package on each workstation with the ability to monitor and evaluate the process while it's carried out.
At this point, it is assumed you have defined your preferred client configurations and set up a LAN in the lab that simulates your production LAN. You should have at least one computer in the lab for each platform (x86, MIPS, Alpha, or PowerPC) you are using in your organization. If you have not already installed Systems Management Server, do so at this time, before proceeding with the lab tests.
Systems Management Server requires an NTFS partition and at least 100 MB of free disk space. You should allow at least 1 GB of disk space for the deployment of Windows NT Workstation. If you did not choose to have Setup convert a partition to NTFS, convert it before beginning the Systems Management Server Setup program. For more information on setting up Systems Management Server, refer to the Systems Management Server Administrator's Guide.
Use Systems Management Server to perform a test deployment in the lab. This involves the following steps, which are discussed in greater detail in the remainder of this chapter:
Copy the Setup Files
The setup files for each platform (x86, MIPS, Alpha, or PowerPC) are located in their corresponding directory on the Windows NT Workstation and Windows NT Server Installation CDs. Copy each directory needed for the platforms running on your production LAN to the distribution sharepoint. For convenience, keep the names of the directories on the distribution sharepoint the same for each platform (for example, \i386 copied to \i386). Add any customization files to the distribution sharepoint, as discussed in Chapter 2, "Customizing Setup."
Be sure the directory on the distribution sharepoint is a shared directory.
Inventory the Test Lab
After Systems Management Server has been installed in your lab or on your production network, it can begin adding computers to its inventory database as the individual computers log on. You can then use the information in the database to determine which computers are ready for the upgrade to Windows NT Workstation 4.0, and which ones need hardware upgrades. Systems Management Server provides an interface in which you can construct queries to the database. The queries you create can be saved, edited, and copied to other sites as needed. They can then be re-used to perform the pilot and final deployments.
Create a "Windows NT Workstation Capable" Query
To identify the computers that have the hardware requirements to run the Windows NT Workstation operating system, create a query from within Systems Management Server. After you run the query, you can create a Machine Group with the results. Then create jobs to run virus detection software and to install Windows NT Workstation on the computers in that Machine Group. Later, you can run queries against the computers in the Machine Group to make sure that all the computers in the group were upgraded as planned.
To create a query
Once you have created a query to suit your needs, you are ready to run it. The query is run against the contents of the Systems Management Server database that has been populated by Systems Management Server as individual computers logged on.
To run the query
By running the query and dragging or pasting the query results into a Machine Group window, you can create a group of all the computers that you want to upgrade to Windows NT Workstation. This group can then be used in subsequent steps.
You might want to create several different machine groups to deploy different configurations. Use variations of the query to create different groups. All the queries should be tested before proceeding further, to make sure you are selecting only those computers you really want to target.
See Chapter 7, "Queries," in the Systems Management Server Administrator's Guide for more information on creating and executing queries. Also see Chapter 14, "Machine Groups and Site Groups," in the Systems Management Server Administrator's Guide for more information on machine groups.
Create a Package to Install Windows NT Workstation
Windows NT Workstation allows the use of special information files (.inf files), that can specify all possible custom settings. The format and parameters for these files are described in Chapter 2, "Customizing Setup."
Systems Management Server can use these information files for automated installations of the software. The vehicle for this is the Package Definition File, or PDF. A PDF is an ASCII file that specifies setup programs, installation options, and execution command lines for the software you will install. If the PDF contains a reference to an .inf file, then the .inf file is made available to the destination computers when the package is delivered through a Systems Management Server job. In fact, several .inf files can be included in a single package.
Since the PDF has options for installing Windows NT Workstation on computers currently running MS-DOS, Windows 3.1, or Windows for Workgroups 3.11, the queries need to target each platform individually.
In order to install Windows NT Workstation on the target computers, for MS-DOS-, Windows 3.1–, and Windows for Workgroups 3.11–based systems, the winnt command must be used to install the operating system. For computers that are running an earlier version of Windows NT Workstation, use the winnt32 command to install the operating system. Both the winnt and the winnt32 commands include a complete set of command-line switches that can further help automate the setup process. For more information on this, see Chapter 2, "Customizing Setup." Systems Management Server Distribution Packages can be used to run these commands locally on targeted workstations.
Each package is completely self-contained: It has all the files needed for the task or tasks it is designed to do. Furthermore, a single package can contain several different sets of helper files, EXEs, and INFs. The command you want is chosen when you create a job using the package.
To create a package to deploy Windows NT Workstation
For more information on creating packages, see Chapter 10, "Packages," in the Systems Management Server Administrator's Guide.
Create a Job to Execute the Package
In order for the winnt or winnt32 command in the "setup" package to be run on the destination computers, it must be made available in a Run Command on Workstation job. The job is created by dragging the package to the machine group on the site and filling in the Job Details dialog that appears as a result. You might also choose to take advantage of the job scheduling and configuration options.
After you have set up the job, it appears in the Jobs window as a pending job.
Monitor the Systems Management Server Job Status
Monitor the status of the job by selecting that job in the Job Properties dialog box, clicking on the Status button, and viewing the Sending and Working columns in the Job Status dialog box.
After the job has had a chance to propagate, you can check on details of the job. In the small network you have set up in the lab, this could take as little as 30 minutes. In your production network, you'll need to allow more time. To view the details of the job, select Details from the Job Status dialog box. The Job Status Details dialog box appears.
When the Status column changes to Complete, the job has been distributed. The total duration of the job depends on a number of factors, including the parameters set for the job and the behavior of your users (who must log on to accept the Systems Management Server Package).
For more information on jobs, see Chapter 11, "Jobs," in the Systems Management Server Administrator's Guide.
Evaluate Distribution Results
A "complete" job status does not necessarily indicate successful deployment of the operating system. You must perform additional analysis to determine results.
First, make sure the inventory has been updated for all computers in the target group of workstations. Then run queries against the Machine Group to which you sent the Windows NT Workstation installation job. For example, you might create "Successful Windows NT Workstation" and "Unsuccessful Windows NT Workstation" queries.
Examine the computers that were not successfully upgraded on a case-by-case basis. Check, for example, whether there were changes in available disk space or in the availability of some other resource between the time the computer was added to the target group and the time the upgrade was performed.
The computers that were successfully upgraded should be tested to make sure the configuration you specified works as expected.
You can check details of job events to troubleshoot problems. For example, if a job has failed, perhaps because the .inf file was not available where it was expected, this would be reported in the job events.
To view the job events
Viewing job events is further described in the section, "Viewing Job Events and Status" in Chapter 11, "Jobs," of the Systems Management Server Administrator's Guide.
A log is created as each job progresses; each task is logged to a log file as it is performed. This log file can be examined if the job failed or produced unexpected results, to help you pinpoint the source of the problem.
Use Trace.exe, which you copied to your Systems Management Server server while setting up the lab, to view log files of jobs that have been run. When you start this program, the Systems Management Server Tracer window appears.
You can open a log file by choosing Open from the File menu, and view the contents of the log file.
If you need to contact Microsoft Product Support for help with the deployment, be sure you have copies of the following files for the test or deployment attempt for which you need help:
Modifying Logon Scripts
Logon scripts for existing network clients can be modified to include a mandatory upgrade. (Logon scripts point to a batch file that runs automatically every time a user logs on.) One example of a logon script might include the command net time \\servername to set the time on all workstations in the domain to be the same as the server time.
Existing logon scripts can be modified to include the winnt or winnt32 command, providing a forced upgrade when a user logs on. A prompt could be included in the logon script to give the user the option to postpone the upgrade. The user will be prompted for information unless you specify an answer file with the /u option and possibly a UDF with the /udf option. (For example, if the computername for this particular computer is not specified in an answer file or the UDF that you specify on the command line, the user will be prompted for the computername.) For information on these options to the winnt and winnt32 commands, see Chapter 2, "Customizing Setup."
Note This method is only viable for smaller LANs. If undue stress is placed on the network from hundreds of concurrent upgrades, the entire network can fail. However, it is a useful alternative in some situations, as when Systems Management Server is not available, staffing resources for deployment are limited, or only a few users typically log on at any one time.
Remember that any time the winnt or winnt32 command is used, the setup files must be placed on a distribution sharepoint. If necessary, answer files may be included and, if used, must be included in the logon script syntax.
Sending a Batch File as an Embedded Link in an e-mail Message
This option is only useful in a small LAN with users who have sufficient expertise to comfortably initiate the upgrade. Users who are given responsibility for their upgrades can introduce variables (such as when each upgrade takes place or what options are included) that can disrupt your planned deployment. To avoid unnecessary stress on the network, send only about 25 setup batch files at one time. Monitor the users who have been given the option to upgrade to keep track of which workstations are upgraded. The files must be kept in place until all users have performed the upgrade. In some cases, you might need to remind users to perform the upgrade so that you can go on to the next group of users, or remove the installation files from the distribution sharepoint.