To submit the lm-fix patch (which I described previously) to each machine, create a simple batch file called stub.bat with the following commands:
Pushd \\server\ nt4sp3$\lm-fix
call update.bat
Popd
The Pushd command maps the next available drive to the specified directory and changes the current directory. The Popd command terminates the drive mapping and changes the directory to what it was originally—before the Pushd command. (For more information about these commands, enter
Pushd /?
or
Popd /?
at a command prompt.) Next, from the DEPLOY$ directory, run deploy_stub.bat.
The deploy_stub command makes a copy of stub.bat for each computer listed in the workstations.txt file. Then, when a workstation reboots, the Autoexnt service runs the autoexnt.bat file. This batch file maps a drive to the deployment directory and runs the workstation’s copy of stub.bat. The stub.bat file runs update.bat in the lm-fix directory, thus applying the hotfix and making the Registry changes. If all the commands run successfully, autoexnt.bat deletes the workstation’s copy of stub.bat and reboots the workstation so that the patch takes effect.
Deleting the workstation’s copy of stub.bat serves two purposes. First, the patch is no longer applied every time the workstation reboots. Second, you can easily track which workstations haven’t applied the patch. After a couple of days, you’ll notice a copy of stub.bat, with the associated computer name, in the DEPLOY$ directory of those workstations that haven’t rebooted or that have failed to run autoexnt.bat successfully for some other reason. You can manually reboot those workstations and force the batch file to run. If your workstations don’t reboot regularly, you might want to use the resource kit’s Sleep or Waitfor tools to make autoexnt.bat an infinite loop with an efficient pause in each iteration.
The Shutdown command, which is another resource kit tool, runs an immediate unconditional reboot by virtue of the /c parameter. This command doesn’t cause user data loss, because autoexnt.bat runs before the user logs on.
Automated patch deployment might make you nervous about security. However, handling the process properly prevents most problems. If you use file permissions to prevent users from changing the autoexnt.bat file, the Autoexnt service doesn’t create a security hole. If Autoexnt is compromised, the damage is limited to the local workstation and possible deletion of the stub.bat copies on the deployment server. Be sure you remove the DEPLOYER account from the Domain Users group, and give the account only read, execute, and delete permissions. With limited permissions, the DEPLOYER user account can’t change the stub.bat files and thus can't run arbitrary commands on other workstations.
Some users might object to coding the DEPLOYER password into autoexnt.bat. Alternatively, you can run the Autoexnt service as the DEPLOYER domain account. However, you’d have to make DEPLOYER an administrator on every workstation, which creates additional security risks: If the DEPLOYER account were compromised, users would have administrator access to every workstation. To prevent this type of problem, you’d need to make significant changes to users’ default right assignments.
Make sure you have tight control over write and add permissions on the DEPLOY$ directory. If this directory is compromised, an intruder can propagate malicious code to every computer listed in workstations.txt.
Deploying patches to existing servers. You can use the same method to deploy patches to servers as you used for workstations. However, because you have far fewer servers than workstations, and because of the servers’ importance, you might want to install updates manually at each server. You’ll still want to use the update.bat file coded for the patch to ensure consistency and to save labor.
If you use automated deployment for some of your servers, keep in mind that Autoexnt relies on a reboot to trigger the patch. Servers typically don’t reboot as often as workstations do. Thus, you’ll need to use the infinite loop and efficient pause method that I mentioned in the previous section.
A security concern is that users who have write or add permissions on the deployment directory also have indirect Administrator access on the computers that look in that directory (because Autoexnt runs batch files located in the directory, under the LocalSystem account). To apply hotfixes, you must have this level of access to the systems you’re updating. Users having Administrator access on workstations might not cause problems, but you typically don’t want someone to have Administrator access on all the servers. You might want to eliminate the central DEPLOY$ directory for servers. Instead, create a DEPLOY$ directory on each server, and grant write and add permissions only to that system’s local administrators group. Install autoexnt.bat on this directory so that systems administrators can deploy patches to it.
Tracking Patch Levels
Even with a well-conducted patch-management procedure, you’ll sometimes wonder what patch level a system on your network is running. Without SMS, determining patch levels can be tricky. You can use the hotfix command with the /l parameter to display the Microsoft Knowledge Base article numbers for installed hotfixes; however, this method doesn’t accommodate remote workstations, and the information it provides isn’t particularly useful.
MTE Software (http://www.mtesoft.com) has a useful tool called SPQuery. This tool lists current service packs and hotfixes on a system. It provides the Knowledge Base number, the hotfix date, and a text description. The latest version of SPQuery can even download, install, and remove hotfixes from a system.
Get A Good Night’s Rest
You don’t have to work nights and weekends to keep your network current and secure. You just need to implement a well-organized strategy for managing service packs and hotfixes. To maintain a secure network in today’s dynamic environment, you must stay up-to-date with security developments, evaluate patches for applicability to your systems, test the patches you need, and deploy them to your systems