Steve Pruitt at myITforum.com

Do you concentrate just on applying the latest updates? Do you figure that once last month's patches are done you can forget about them? If so, you are leaving some machines vulnerable without realizing it. Every time an application is installed, or uninstalled and reinstalled, there may be appropriate patches required. That's true even if they were applied previously. The same thing can happen just adding a feature to Office, if it's one that was vulnerable. If a support engineer uninstalls and reinstalls an OS component on a workstation or server, some patches that had run before may be needed again. The biggest exposure comes when you install SP2 on an XP SP1 machine, or upgrade the version of Office. These absolutely guarantee that some old updates must be reapplied, because different versions were needed for the new software versions. Other updates weren't appropriate before but are now.

What not to do
You do not need to hang on to each month's update package and rerun it every week or so. That will just add unnecessary overhead to each affected machine, and possibly disrupt operations if it causes an unexpected reboot. In this context, any reboot that's not at a scheduled time and pre-announced rates as unexpected. Even if the patch gives a 30 minute warning, that's meaningless to a manager who is away at a meeting. How about on a server outside the maintenance window, or while an engineer is performing other maintenance activities?

What you should do (the basics)
SMS 2003 provides a mechanism designed to make this easy. Create a patch deployment package using DSUW that includes all previous patches that you want to include. At my last job I think we had everything since 2002. Make sure you exclude any updates that have been superceded. Advertise it to run from the Distribution Point; do not set it to download. The individual machines will copy the executable from the DP, analyze the last scan results, and only copy locally any updates that are required. This means you can have a huge package with minimal impact on the target workstations and servers. Each month you'll add the new updates to it and remove any that became superceded. Only the changes are propagated to the various DPs, not the whole package. This even works well, under most circumstances, with remote users.

Why it's not quite that simple
You had to know it couldn't be that simple. What is? In this case the biggest catch is the reboots needed after patches are applied. If you make the patch package do reboots you will create the unexpected reboots I warned against earlier. That's true even if you make it an interactive package with a long countdown - you'll still disrupt some machines.

What happens if you just apply the updates without rebooting? That's not good either. First off, the machines remain vulnerable until they are rebooted. Since that could be a long time, this is not good. Second, this may result in another form of unexpected reboot the next time patches are applied. See my article Unexpected reboots when patching.

Suggestions
For workstations, I'd run the baseline patches silently, without reboot, once a week. I like Saturdays for minimal impact and the best opportunity for reboots. Other schedules will be better in some organizations. Make sure the scanner will always be run prior to the baseline, so that any required patches would be detected. Have a reboot package scheduled for that night, applying only to machines without a user logged on. Run reports of machines needing reboots Monday, after any daily HWI has run. Report again on Tuesday if you have many laptops, since some might be patched Monday morning. Take whatever steps are most appropriate in your organization to get them rebooted before the next patch cycle. This could be rebooting machines even if a user is logged on, writing to the user and manager, or running a script that nags them to reboot.

For servers, I'd try to give the support engineers a way to run the scanner and baseline patches after they perform maintenance that might require new patches. They could be set up so they could be run by the engineer at will through Control Panel. If that's not practical, they could inform the SMS Administrators of planned maintenance and have the scanner and patch package scheduled as part of the operation. Failing these things, or as a second level of protection, run the scanner daily and report any machines that require patches. If a server appears on that report, schedule the patching and reboot with the appropriate support team for the next maintenance window.

The most important thing to consider, always, is the business needs of the organization. Patching always involves weighing the tradeoffs between complete patching in a timely manner and minimizing user disruption. It's impossible to have both, but it is practical to find procedures that provide acceptable levels of each. The more closely you can work with the management of the server support teams, business units, and key departments like night operations and call centers, the easier it is to reach an acceptable balance.