How many different patch schedules do you have?
Hi,
I've been using the KBox since before Dell acquired it from KACE, and I still hate still struggle with making the patching process efficient.
I'm curious how you setup your patch schedules. Do you have separate schedules for each OS / machine importance / patch importance? (If I setup something like that I would have 18 different patch schedules, just for our servers!)
Please share how you setup machine & patch labels and patch schedules for your Windows servers with the group so that we can all benefit from each other's experience.
Thanks,
djz
0 Comments
[ + ] Show comments
Answers (4)
Answer Summary:
Please log in to answer
Posted by:
Bruce_P
7 years ago
We have over 150 schedules. It's a large environment (4500 workstations and around 600 servers) and we operate 24/7.
Patch schedules are broken up for departments and are based around their operating hours, or least busy times. Server are broken down to their business function and when acceptable downtime is for the users. We try to distribute the workload throughout the week to lessen the load on the Kace box.
Posted by:
chucksteel
7 years ago
Top Answer
We have several main schedules for workstations, server patching is handled by a separate group. All of our schedules include the OS and application patches that we push, we do not use separate schedules for software/critical/etc. Patch definitions are updated Tuesday night, this allows us to test on Wednesday and then deploy to production on Thursday. Occasionally we do setup a specific schedule that is more aggressive (can you say WannaCry?).
Patch Production - This is the default patching schedules for machines. Detection runs Thursday morning, patching runs Thursday night. Users can snooze the restart for an hour a few times before they are forced to restart. The schedules are both set to run on next connection of the computer is offline.
Test Patching - Runs on a smaller set of computers for testing purposes. Detect Wednesday morning, patching Wednesday night.
Lab Patching - Lab computers (higher ed environment) get patched every night with a detect and deploy schedule. This schedule does not run on next connection of the machines are offline, which is one of the reasons it runs every night. We originally did have this schedule run on next connection, but it interfered with teaching, so that changed.
No Patching - System critical machines (and some faculty that can't be told what to do) are in this schedule. We run a detect schedule once a month and inform users if they are out of date. Repeat offenders may be moved into an actual schedule.
We have one schedule setup for a specific department with special needs. It runs a detect and deploy cycle once a month.
Posted by:
Nico_K
7 years ago
2. One global detect and one global detect + deploy. It is a small environment but has a few remote systems.
Usually you should patch all software at the same time but maybe split the systems so you patch only a few systems at the same time (department wise)
Usually you should patch all software at the same time but maybe split the systems so you patch only a few systems at the same time (department wise)
Comments:
-
Nico_K, does the detect + deploy install patches/programs faster since you did a detect beforehand? - flip1001 7 years ago
Posted by:
getElementById
7 years ago
Great question! I'm interested to see how others do it too.
I do maintain several patch schedules: 14 total.
Workstations do all the OS patches at the same time. I have separate schedules for both Java and Adobe stuff which I run reports against because I like to make extra sure they get installed. I have another schedule that does other 3rd-party apps like Chrome, Firefox and a few others.
Servers run in two groups. Basically I just install the OS updates but the "less critical" servers get patches first just in case. I don't install SQL or Exchange updates with Kace because I've never been brave enough (not sure if they are even available through Kace?) so I do them manually.
Those are my primary schedules.I have a few that I run manually using the "Run now" option at the bottom of the schedule. One is for a group of 24/7 uptime servers that I have to plan downtime for. I have another manual one that I use to get a single machine up to speed very quickly. It does a full detect + deploy for all OS and application patches.
I have a New Machine schedule that runs against a smart label of machines less than 7 days old. This runs every night and will allow a new machine to get patched as the OS, Office, and other apps get installed throughout a week.
Other than that I have a full detect that runs daily on the entire inventory.
As for the scheduling aspect, most schedules run weekly on their own day of the week. Some nights multiple schedules run a few hours apart from eachother.
I have two things I still want to figure out a system for: laptops and failed patches.
I don't have many laptops but the few I do have miss patches every now and then. I've seen other Kace folks use a separate schedule specifically for laptops that runs on next connection and then prompts the user for reboot so I might do this.
On failed patches, I've considered creating a "remediation schedule" of sorts that basically runs against machines that failed to patch. Maybe also using a patch smart label of only patches that failed to patch so that its a relatively quick detect + deploy that runs nightly. I'm not sure yet though. Because I patch weekly I don't get too worried and I don't have to deal with failed patching very often.
Comments:
-
I'm amazed that you "don't have to deal with failed patching very often." My experience is quite the opposite... more often than not we have failed patches, and it is a pain to trouble-shoot and fix up. - zookdj 7 years ago
-
Ah, my apologies. I do have failed patches almost every week. A more accurate statement would be that its only on a few machines (few relative to the total number of machines) each patch schedule. In most cases, they are successful on the next scheduled run. My current solution involves a daily patch statistics report that I use to manually track machines for potentially needing manual intervention in the near future. - getElementById 7 years ago
