Patching Schedule (Best Practice)
Hello,
I am looking for the best way to patch my test machines first, then do production. I would like to do a schedule using labels for test such as patches released in the last 15 days and then have production on 30. If anyone has some setup similar to that, any information would be much appreciated. Thanks!
0 Comments
[ + ] Show comments
Answers (2)
Answer Summary:
Please log in to answer
Posted by:
Nico_K
6 years ago
there is not "the best way" globally.
The following setting is easy to maintain and saves space but needs attention.
Pro:
- you don't need to fiddle with patching smart labels
- easy to maintain
- flexible
Con:
- it does not patch software installers so no new major versions or systems which don't support incremental patching
- if the patch level is very old it needs many updates to get the latest one (esp. Java or Flash which has so man subversions nearly every week)
The following setting is easy to maintain and saves space but needs attention.
Pro:
- you don't need to fiddle with patching smart labels
- easy to maintain
- flexible
Con:
- it does not patch software installers so no new major versions or systems which don't support incremental patching
- if the patch level is very old it needs many updates to get the latest one (esp. Java or Flash which has so man subversions nearly every week)
Prerequisites:
- make sure all systems have the latest major version of a software installed.
- review the managed installs regulary to install a new major version (ie: the setting can patch Java 8.1 to 8.171 but not to 9)
Setup:
1. Patch Download Settings: Coose Files Detected as Missing and Delete unused files after 90 days (if they are needed, they will redownloaded)
2. Run the Download in a Schedule (in my case daily at 20:00 with Files After signature Download)
3. Subscriptions:Subscribe all as neededed except under Application Patches | Types don't subscribe the Application Patches
4. Disable WIndows Embedded (except you have POS systems which need it)
5. Don't inactivate Superseded Patches
6. Don't detect Disabled Patches
7. Run a Detect Only on all systems on wednesday morning (in my case at 10:00 when they are online)
8. Report the results
9. Run a Deploy Only on the Test systems on thursday morning and afternoon (10:00 and 16:00) -> some patches need a reboot and since the Deploy only stops at this point and don't install after the reboot the Deploy needs to be reran.
10. Run a Detect Only friday on the test systems (just to be sure all is patched)
11. Disable patches which made problems
12. Run a Deploy Only on the production systems on monday morning, afternoon and tuesday morning, afternoon (to get a grip on all machines) - > optional you can also use WOL and patch them over the weekend.
Alternatives would be patching using patch labels (with software installers) for the software you really need.
- make sure all systems have the latest major version of a software installed.
- review the managed installs regulary to install a new major version (ie: the setting can patch Java 8.1 to 8.171 but not to 9)
Setup:
1. Patch Download Settings: Coose Files Detected as Missing and Delete unused files after 90 days (if they are needed, they will redownloaded)
2. Run the Download in a Schedule (in my case daily at 20:00 with Files After signature Download)
3. Subscriptions:Subscribe all as neededed except under Application Patches | Types don't subscribe the Application Patches
4. Disable WIndows Embedded (except you have POS systems which need it)
5. Don't inactivate Superseded Patches
6. Don't detect Disabled Patches
7. Run a Detect Only on all systems on wednesday morning (in my case at 10:00 when they are online)
8. Report the results
9. Run a Deploy Only on the Test systems on thursday morning and afternoon (10:00 and 16:00) -> some patches need a reboot and since the Deploy only stops at this point and don't install after the reboot the Deploy needs to be reran.
10. Run a Detect Only friday on the test systems (just to be sure all is patched)
11. Disable patches which made problems
12. Run a Deploy Only on the production systems on monday morning, afternoon and tuesday morning, afternoon (to get a grip on all machines) - > optional you can also use WOL and patch them over the weekend.
Alternatives would be patching using patch labels (with software installers) for the software you really need.
Posted by:
PaulGibson
6 years ago
Top Answer
I setup 2 Patch Smart Labels and 2 Patch Schedules, one for the computers that should get the updates early for testing, and one for the rest of the computers. I first run a detect on all the computers, then run the deploy on the different sets of computers. The main difference is in the Smart Labels, where I want to wait a few days after a patch is released before deploying it. They're something like this:
For the early deploy, my Smart Label is
Status is Active
Type is not Software Installer
Missing is True
Released is not within last 2 days
For the main deploy, my Smart Label is
Status is Active
Type is not Software Installer
Missing is True
Released is not within last 4 days
You could change the Released is not within x days to what you're comfortable with.
