Just to throw it in, here is my patching strategy. I am lucky enough to have a fairly good base of Development and QA devices. I currently use 3 vehicles to deliver a patch. 1.)WSUS for managing patch downloads, approvals, etc... 2.)Group Policy for what, where and when. 3.)Scheduled tasks with a javascript to run windows update.
The schedule:
Patch Tuesday - Patches applied automatically to IT Infrastructure and Help Desk staff (controlled via Group policy)
Thursday after Patch Tuesday - Patches released to the rest of IT (Developers, QA department, and our Information Protection Group)
Monday after Patch Tuesday - Patches approved for Dev and QA servers. (again, controlled via Group policy, but I manually check the boxes)
2nd Monday after Patch Tuesday - Patches are released to a test bed of PC's in the business. These are usually the SME's of the department.
2nd Thursday after Patch Tuesday - Patches are released to the rest of the business (controlled via group policy to apply at 11:45 AM for the corp office, most users have no issues rebooting before going to lunch, and for our other areas at times that are end of shift) When the next version of SMS comes out, we will probably change the deployment method to a nightly push, and wake up the PC's to do it.
2nd Thursday after Patch Tuesday - Patches are also approved for installation on Production servers. We use a javascript to install the patches as part of their regular maintenance window. Those windows may be daily, weekly, or monthly depending on the server function, but ALL windows server have a LOB agreed upon (in writing) maintenance window or I will not install the server.
That is basically our patch schedule and how we deploy. I can say that we are usually in the 95% patched range on client PC's within 30 days of release, and 99% patched range on servers within 30 days.
Hopefully someone will find our method as usable for themselves. I can say that if M$ did decide to change to a daily released patch schedule, then I would have to consider setting up additional test groups, but the
So, the biggest reason that I can remember for the creation of patch Tuesday's was that system administrators, and other computer savvy people, complained that they had to patch a system what seemed like every day. Microsoft used to release patches when they finished them, but changed their policy to only provide patches once a month.
While I am a system admin, and like only having patches once a month, I also like the other side of the coin that can have me patch my systems when the patch is ready if I so choose to do so.
For non-system admins, you can use the control panel applet to set the date\time that you want your patches to install(Auto with set date\time, download and prompt me, just prompt and don't download). You can also choose to not apply the patches, and create a scheduled task using a script that will apply the updates, and then reboot. We use a script on all of our servers, and apply patches as part of the regularly scheduled reboot of the server.
Slashdot Mirror
Just to throw it in, here is my patching strategy. I am lucky enough to have a fairly good base of Development and QA devices. I currently use 3 vehicles to deliver a patch. 1.)WSUS for managing patch downloads, approvals, etc... 2.)Group Policy for what, where and when. 3.)Scheduled tasks with a javascript to run windows update. The schedule: Patch Tuesday - Patches applied automatically to IT Infrastructure and Help Desk staff (controlled via Group policy) Thursday after Patch Tuesday - Patches released to the rest of IT (Developers, QA department, and our Information Protection Group) Monday after Patch Tuesday - Patches approved for Dev and QA servers. (again, controlled via Group policy, but I manually check the boxes) 2nd Monday after Patch Tuesday - Patches are released to a test bed of PC's in the business. These are usually the SME's of the department. 2nd Thursday after Patch Tuesday - Patches are released to the rest of the business (controlled via group policy to apply at 11:45 AM for the corp office, most users have no issues rebooting before going to lunch, and for our other areas at times that are end of shift) When the next version of SMS comes out, we will probably change the deployment method to a nightly push, and wake up the PC's to do it. 2nd Thursday after Patch Tuesday - Patches are also approved for installation on Production servers. We use a javascript to install the patches as part of their regular maintenance window. Those windows may be daily, weekly, or monthly depending on the server function, but ALL windows server have a LOB agreed upon (in writing) maintenance window or I will not install the server. That is basically our patch schedule and how we deploy. I can say that we are usually in the 95% patched range on client PC's within 30 days of release, and 99% patched range on servers within 30 days. Hopefully someone will find our method as usable for themselves. I can say that if M$ did decide to change to a daily released patch schedule, then I would have to consider setting up additional test groups, but the
So, the biggest reason that I can remember for the creation of patch Tuesday's was that system administrators, and other computer savvy people, complained that they had to patch a system what seemed like every day. Microsoft used to release patches when they finished them, but changed their policy to only provide patches once a month. While I am a system admin, and like only having patches once a month, I also like the other side of the coin that can have me patch my systems when the patch is ready if I so choose to do so. For non-system admins, you can use the control panel applet to set the date\time that you want your patches to install(Auto with set date\time, download and prompt me, just prompt and don't download). You can also choose to not apply the patches, and create a scheduled task using a script that will apply the updates, and then reboot. We use a script on all of our servers, and apply patches as part of the regularly scheduled reboot of the server.