One new (to Microsoft) technique is
hot-patching, which updates running code in memory. Hot patching does not replace the actual executable on disk until after the service or application has shut down. This typically happens on the next reboot. Keep in mind here that this technique requires the user that installs the update to have the “Debug Programs” privilege. If you have removed that privilege from Administrators, for example, you need to grant it back at least to the accounts that will install updates. Unfortunately, hot patching comes at a cost – hot patches cannot be integrated into an installation point by slip streaming.
Another technique being built into the new installers is
warm patching. In this case, the update installer attempts to shut down the application(s) that is using the files in the update prior to installing it. This is important because often the reason a system has to be rebooted after patching is because the update updates files that are in use. By shutting down the service prior to patching it, you can avoid having to reboot the system after the update is installed. This is obviously faster than a full system reboot. However, warm and hot-patching is not available for all security updates, and does not work for some types of security updates. You may be able to manually recreate the same effect though.
http://www.microsoft.com/techn...les/patch_management.mspx#EBAA