Loading service packs and hotfixes is a constant drain on any administrator’s time. But how do you keep your Windows 2000 systems up-to-date and secure and still get home at a decent hour? With a few simple scripts and Group Policy, you can make these tasks easier. By setting up the proper infrastructure, you can submit a script or batch file to any subset of computers in your network. You can put anything you want in the script, including instructions to load a hotfix.
Let's look at an example where you can configure each computer to check for and, if found, run the script whenever the computer boots. The frequency of this routine might not fit your needs, but I’ll show you how you can tailor the script accordingly. We’ll make sure that the script runs with necessary authority on the target system and let you track which systems have successfully executed the script. Finally, with the help of Group Policy, we’ll accomplish all of this without having to make repetitive changes on each system.
Creating a Boot Script
Begin by creating a BootScripts user account with Active Directory Users and Computers, and set an appropriate password (e.g., sjW298d@U) for this account. Remove this user account from the Domain Users group. This step is important—because you're embedding this account password in a script file, you need to ensure that this account has the least authority necessary. Next, create a new folder called BootScripts on a file server and share this folder.
Open the permissions for this directory and give Administrators Full Control. Give the BootScripts user account Read & Execute permissions, and use the Advanced view to grant the special permission Delete. When each computer boots, it will use the BootScripts user account to connect to the BootScripts folder on the file server and look for a .cmd file bearing its computer name. If the computer finds this file, the computer will run the file, and if successful, delete the file. Therefore, this generic user account needs read, execute, and delete access.
Next, use Active Directory Users and Computers to create a new organizational unit (OU—called Test OU in this example) in your Active Directory (AD) domain, and move one of your lab computers (called lab1 in this example) into that OU. Open the Properties window for Test OU, go to the Group Policy tab, and create a new Group Policy Object (GPO) called BootScriptsPolicy. Edit this GPO and maneuver to Computer Configuration/Windows Settings/Scripts, as Figure 1 shows. Double-click Startup to get to the Startup Properties dialog box, as Figure 2 shows. This policy lets you create scripts (.cmd files or Windows Scripting Host—WSH—files) that the GPO stores. Each computer where you apply this GPO will execute the script when that computer boots. The scripts run under the full authority of the local System account. Click Show Files from the Startup Properties dialog box to display an Explorer-like view of the Startup folder. Create a new .cmd file in this folder (call it checkforbootscript.cmd for this example), and add the following lines, where fs1 is the name of your file server:
net use \\fs1\bootscripts sjW298d@U /user:BootScripts if not exist \\fs1\bootscripts\%computername%.cmd exit pushd \\fs1\bootscripts del %computername%.log call %computername%.cmd > %computername%.log if not errorlevel 0 goto bottom del \\fs1\bootscripts\%computername%.cmd :bottom popd
The script begins by connecting the share you created using the BootScripts user account. This step is necessary because the checkforbootscript.cmd file currently runs under the machine local System account, which has no meaning to other servers. Next, the script maps the first available driver letter to the BootScripts folder using the pushd command. The script checks for a .cmd file bearing the computer name and calls that file. The script redirects the output of the .cmd file to a log file with the computer’s name so that the administrator can diagnose the script if necessary. If the .cmd file ends successfully (errorlevel 0), the script deletes the .cmd file so that the file doesn’t run the next time the computer boots. Deleting this file also signifies to the administrator that the update was successful. Finally, the script deletes the drive mapping it created earlier.
Many administrators have used similar logon scripts with Windows 9x systems. However, these logon scripts don't work well for deploying system updates to Win2K because they run under the user’s authority, and the user is typically an administrator on the local system.
Now that you’ve created the checkforbootscript.cmd file, add it to the list of scripts in Figure 2 by clicking Add. You also need to create a new .cmd file in the BootScripts folder named after the lab computer you put in Test OU (called lab1.cmd in this example). To test the lab1.cmd file, you need to add some commands. For a quick test, add the following line to create a directory on the local system:
md %systemdrive%\didit
To apply a hotfix (e.g., q269049) using the script file, you need to download the hotfix executable (e.g., q269049_w2k_sp2_x86_en.exe) into the BootScripts directory and add a line to lab1.cmd, such as
q269049_w2k_sp2_x86_en.exe –f –q –m
The –f, –q, and –m switches cause the hotfix to apply without user intervention and to immediately reboot the computer. When you deploy a hotfix this way and a user boots his or her workstation first thing in the morning, the system will boot as usual. However, before the user can log on, the computer will immediately shut down and reboot so that the hotfix can take effect.. You can adapt this behavior using other switches. To understand what each hotfix switch does, type the name of the hotfix executable followed by /?. To test your setup, reboot lab1. Win2K will apply Group Policy and run checkforbootscript.cmd, which in turn will execute lab1.cmd and then delete it. You will know if lab1.cmd executes successfully if the file disappears.
After you finish testing, link the BootScriptsPolicy GPO to other OUs as appropriate. Each computer within that OU will now start checking the BootScripts directory for a .cmd file bearing its computer name. To submit the same script to many computers, make a copy of the script in the BootScripts directory for each computer name. To make sure that checkforbootscript.cmd doesn’t delete the computer’s .cmd file until it executes successfully, make sure you set the errorlevel properly before exiting the .cmd file.
Customizing the Infrastructure
You can adapt the infrastructure surrounding the script or batch file to fit your needs. For instance, if you want your computers to check every hour for a script, change the startup script to start a second script that runs in the background and wakes up every 60 minutes to check the file server for a .cmd file with the computer’s name. To do this, your startup script can simply execute the following command:
start checkforscript.cmd
You must start a second script because Win2K waits for startup scripts to complete before the OS lets the user log on. This way, checkforscript.cmd will run in the background whenever the system is up. Checkforscript.cmd looks similar to checkforbootscript.cmd, but you add one line to the beginning and two to the end, as follows:
:loop net use \\fs1\bootscripts sjW298d@U /user:BootScripts if not exist \\fs1\bootscripts\%computername%.cmd exit pushd \\fs1\bootscripts del %computername%.log call %computername%.cmd > %computername%.log if not errorlevel 0 goto bottom del \\fs1\bootscripts\%computername%.cmd :bottom popd sleep 3600 goto loop
Note that the sleep command is part of the Win2K Resource Kit. Sleep pauses the specified number of seconds without wasting CPU cycles.
As you can see, when it comes to centrally deploying updates and taking care of unforseen needs that require execution of commands on systems under your care, the sky is the limit. If you deploy Win2K laptops without an AD domain, and therefore without the ability to configure startup scripts using Group Policy, don’t despair—each computer has a local GPO. Before you deploy each computer, simply configure the local GPO to run checkforbootscript.cmd as a startup script and point it to a file server on your network. This approach is especially easy if you are using Ghost or another imaged OS installation product and can configure the original system to run checkforbootscript.cmd prior to saving the image.
