Security UPDATE, Web exclusive, September 3, 2003
Windows & .NET Magazine Security UPDATE--September 3, 2003
As you know, maintaining service pack levels and hotfixes on your systems is important. Many factors affect how and when you patch your systems. If you've tested your particular architecture and know that a given service pack or hotfix won't adversely affect operations, you still face the problem of how to roll out the service pack to all your systems, especially if some of your systems are mobile and connect only periodically.
You can roll out patches various ways. You might use Microsoft Systems Management Server (SMS) with Software Update Services (SUS), SUS by itself, or any of several third-party service pack and hotfix-management tools. Also, you can ask users to patch their systems, or you might patch systems manually. Clearly, however, automation is the most effective rollout approach.
One efficient way to handle patch management is by using Group Policy and scripts. You can use scripts to check a system's patch levels, then use Group Policy to cause systems to load patches--for example, if a system doesn't have a given patch installed. To use this approach, you need some level of proficiency in writing script code, which isn't hard to achieve but does require some time and focus.
Patrick Goodwin, who reads the HowTo Mailing List \[http://184.108.40.206/listserv/page_listserv.asp?s=howto\], recently offered readers a startup boot script that he uses to help automate service pack installation. (Goodwin's employee, Chi Kin To wrote the script.) The script checks the OS type and service pack level against presets written into the script code. If the system doesn't meet conditions (e.g., Windows 2000 Service Pack 4--SP4--isn't installed), the script places that computer in a service pack installation group (a Group Policy Object--GPO). The script schedules a system reboot at a predetermined time (e.g., in the middle of the night when no one uses the system). When the system reboots, the system downloads and installs a copy of the service pack. When the same script runs again and determines that the system has the specified service pack installed, the script moves that system out of the service pack installation group.
Depending on your particular situation, you might find this script handy. You might also consider modifying the code to fit another task or purpose. Also, if you want to learn scripting techniques, the script serves as a good example of how to perform various actions, such as determining an OS type, service pack level, and GPO membership. You can access the script to examine or use in the HowTo for Security mailing list archives \[http://www.secadministrator.com/listserv/page_listserv.asp?a2=ind0308c&l=howto&p=3253\]. You'll find another version of the script \[http://www.secadministrator.com/listserv/page_listserv.asp?a2=ind0308d&l=howto&p=2351\] (Chi Kin To also wrote this version), which has additional code that checks a machine's IP address to make sure it's connected to the local subnets before any actions are performed. This check might be helpful for systems connected over slow WAN links. The IP address check can ensure that the script doesn't cause that system to try to download a huge service pack file over a slow link.
You can get a head start on script writing by searching for ready-made scripts on the Internet, by learning about scripting techniques in any of various forums \[http://www.winnetmag.com/forums/categories.cfm?catid=43\], and of course by reading the Windows Scripting Solutions newsletter \[http://www.winscriptingsolutions.com\].