From many rounds of patch management over the years, I would highly recommend the following:

1) Have a Computer Management Configuration Database (CMDB) in place, and make sure that the patch information is updated regularly thru an automated process.

2) If databases servers have their own CMDB, and there are good reasons to do so, make sure that the Windows support and patch management team(s) are aware of it. Provide them with the appropriate interface so they understand which are the DB servers. Not every junior Windows admin will realize that DB and web/app servers need to be treated differently.

3) SLA's for each server should be documented. It should be easy to group servers by application to see how the entire patching schedule should be set up. One of the more annoying things to deal with is spending Friday afternoon and evening re-schreschedulingxceptions to the company-wide patching window.

4) The patch coordinator for each application should be identified and easy to determine. Application inventory systems may only list the high level owner who won't always recognize 'ServerX'.

5) Make sure that you are getting the high availability from your clusters. In an active/passive setup, the passive node needs to be identified before every patching cycle. This should be automated, and fed into the process, as discussed in #1 & 2. Of course we would like every instance to be on the preferred node, but that doesn't always happen. Since cluster nodes are likely to have consecutive IP addresses and/or server names, both nodes could receive the patch at the same time, something that should obviously never happen.

The bottom line is that it is critical to have good processes in place. To quote the Yogi Berra Aflac commercial, when you don't have it, that's when you gotta have it.