This is certainly a common problem. While I hope you are paying attention to all vendors' security patches and updates, Microsoft patches get much of the attention of systems administrators. If you invest a little time in planning and preparing for the release of Microsoft patches, you will be set up well in the long term. First, you should determine the roles and responsibilities of each person involved in the patch management effort. Since Microsoft releases patch and update information in a very regular fashion (the second Tuesday of each month, except for highly critical patches), designate one person (or several, depending on the size of your staff) to monitor these updates. Microsoft will pre-release certain information about each month's patches (including number and severity), so use this opportunity to prepare for the expected effort that each set of updates will involve. Your specific needs and policy will dictate how quickly patches need to be rolled out (often directly influenced by the severity that Microsoft attaches to each patch). Turn your policy mandate into a specific schedule that will guide the testing and deployment of each month's updates.
Regarding testing -- this is the component of patch management that is typically given the least attention. This is not necessarily by choice, but often, as in your case, because of a lack of resources. It's absolutely critical to test patches before mass deployment though, so I would suggest using some sort of virtualization software (e.g. VMWare, Virtual PC) to test patches against your environment's typical server and workstation builds. This is often cheaper and simpler than using many dedicated systems for patch testing. If you are not currently using any patch or systems management software (or other tools that will allow the automatic and remote installation of patches), you can take a look at some of Microsoft's free tools for patch management, including MBSA and SUS. These tools can be very useful for assessing and patching your environment, but keep in mind that each has some limitations with regard to supported technologies and platforms.
This was first published in March 2005