I wasn't able to find the answer poking around so figured I'd ask it.
We take on new sites pretty regularly and folder them into our Kaseya management for patches. Many times machines on these sites may have never been patched. If I were to add them to our standard update policy that we use for all of our other endpoints that correctly patch what would the behavior be?
Patch scan kicks off around 9pm, patching starts at within an offset of 60 minutes from 11pm, exclusion window is set from 6am-8pm. Reboot behavior is set to notify user if logged in and if the user doesn't respond within 15 minutes reboot. Since our exclusion window is set between 6am-8pm would that mean if the patching wasn't done by that time it would stop then the next scheduled patch time it would pick back up where it left off?
My end goal is to not have machines accidentally patching into the work day.
The Exclusion window applies only to the START time of any process (including patch) and works in conjunction with the Distribution Window you define in the scheduler.
When you enable the exclusion window, you are instructing the scheduler to NOT schedule the beginning of the process to start during the 6a-8p window. If the process has already started, it will not pause or stop during the exclusion window - the process will continue to run. Therefore, using the last example above, if an agent is scheduled to start execution of a process at 5:59:59a, it will begin at that time and run through the exclusion window, since that setting applies only to the scheduling of the execution start time.
The above is not specific to Patch, but is a how the Scheduler utility works. There is no out-of-the-box functionality to halt a process from running mid-way through the process during a defined window.
You might consider using the reboot action of "Everyday at" <specified time>. This will not prevent the installs from running if they begin, but it will delay any reboots until the time you specify, which could be well after business hours. This option will not reboot the machine everyday; rather, this reboot action will determine if a reboot is needed and only reboot if the machine has run a patch cycle during the previous 24 hours and has not been rebooted since the install scripts completed. If no patch installs have occurred, the machine will not reboot. Depending on the resources available to the machine, the user may or may not notice latency/performance degredation during the installs, but would not be faced with a mid-day reboot request, so you could keep the work behind-the-scenes.
That makes perfect sense, thanks for taking the time to reply. Can you think of any other maybe out of the box ways to do what we are after?
A host of custom Agent Procedures that would validate time, estimate length of time to install, and determine whether to allow the process to start could be created. This could be assigned as a Pre Procedure (Patch > Pre/Post Procedure) for AutoUpdate. That seems like a nightmare and riddled with potential points of failure, but it could theoretically be done. I might also include some pre-reboot procedures to validate the time to determine whether to prompt the user for reboot and only prompt if outside your window (to keep the noise to the end-user at a minimum). This would likely take quite a bit of development and testing.
Some MSPs take the approach in onboarding of scheduling with the new clients to patch devices during the first few days or week of service. Essentially, inform new clients that their machines require patching and to be most effective, you will need to patch the devices up front, that they may see some latency during this period, but that once the environment is up to date, patching will revert to whatever your standard patch schedule is. Some choose to start the process on a Friday, requiring the client to have all machines left online over the weekend, and make a best effort to update over a weekend with any necessary understanding/contractual obligations stated regarding machines that are not left on during the initial patch push at the time of onboarding.
You could take a step-approach to deployment. A machine missing one patch will, generally, patch quickly. One missing 1000 patches can take several hours, days, or longer, depending on the size of patches, file source, bandwidth, and other factors. Create patch policies for onboarding and 'roll' the newly-onboarded machines through a series of policies. The first policy would allow only a few of the most critical patches. The next policy will allow installation of the next group of patches, then a third and a fourth. Each limits the number of patches (and therefore, theoretically, the amount of time it would take to install the patches). This could take time to complete, but would allow you to install only a few patches at a time to make a best effort to complete the install cycle before business hours begin. You would need to determine the amount of data you feel comfortable to allow. A gross estimate could be based on the number of patches approved in each policy so that each is approved for fewer than some threshold number of patches at any given time. Let's say you set up a policy so that no more than 20 patches are approved for any given machine. If these are all small patches, they could complete in a number of minutes, but if the approved patches are large (service packs, update rollups, etc.), you could bleed into business hours. Determining the size of the patches and the max amount of data you feel comfortable transferring/allowing to install would be the better (but more labor intensive) way of trying to keep to the after-hours installs.
You might consider configuring a File Source of "From Internet," at least for the initial push. When the file source is "From Internet," the machine will leverage the exact same processes for patch installation as what a home user would use when installing patches via Control Panel > Windows Update. This built-in Microsoft process is pretty effective at reducing impact to other processes. Therefore, on most healthy machines, patching can proceed with limited or no noticeable impact to user productivity. "From Internet" requires that the endpoint have access to the internet so the machine can download the patch components, but Microsoft will leverage BITS to minimize impact. "From Internet" does mean that each individual machine will need to traverse the local network to get out to the internet to download the patch components, and there is no 'sharing' of patch data between the machines, but the process can be less intrusive to the end user and may complete more quickly than when other File Source options are selected (because there is less data to transfer to the individual machine and the transfer does not have a middle-man server to save/recopy the data). This can be difficult for some LANs to manage, depending on bandwidth, number of devices, etc., but is an option in some cases. Once the initial updates are complete, change the file source to the production-desired option (LAN Cache, UNC, System Server, etc.). FWIW, "From Internet" as your file source leverages the built-in MS processes (Windows Update Agent or WUA), but will still honor Kaseya-defined Patch Policies, provided you are only installing patches under the control of Kaseya.
Thanks, great reply!!! One last question, if we do select the From Internet option are we still safe to set the "Disable Windows Automatic Update to let Patch Management control system patching" or does that screw up the BITS portion referred to above?
Set Patch > Windows Auto Update to Disabled, regardless of File Source configuration.
Not only does it not screw anything up, Kaseya recommends that particular option is alwasy set to disabled. The "Disable" setting on the Patch > Win AutoUpdate function disables the Windows Update CLIENT so endusers cannot change the configuration of the UI. Kaseya uses the same registry keys as GroupPolicy to configure the Windows Update Client. Kaseya patch scans and some or all installs (depending on the file source) leverage the Windows Auto Update SERVICE. Kaseya always recommends the Windows Update client is Disabled and the Windows Update service is enabled and started so Kaseya can properly manage patching. If you allow the client to be configured by the end user, patches may install that you have explicitly denied via Patch Policy because the endpoint's local client could run at anytime outside of instruction from Kaseya and, therefore, Patch Policies would not be considered. It would the the same as if a home user clicked "install updates" in the Windows Update client - they'd get everything selected (which is all Microsoft-recommended patches, by default).
The WUA Client and Service are described here: helpdesk.kaseya.com/.../36048153-Windows-Update-Overview
Confusion around this particular subject is pretty common in the patching community as a whole since Microsoft uses very similar terms for a variety of components. Windows Update Client, Windows Update Service, Windows Auto Update, Windows Update, Microsoft Update, and Windows Update Agent are all different components of the larger MS-patch infrastructure. Even better, "Windows Update" used to be called "Automatic Update" so sometimes the client and service are listed as "Automatic Update Client" and "...Service". Technically speaking, Auto Update Client and Service are on older legacy OSs, but that doesn't mean the terms aren't used interchangeably (even when they shouldn't be), adding to the confusion.
Thanks again Brande!