We have really struggled with patch Management. One of the things that drives us crazy, is that to install 151 patches on a brand new i7 PC with Kaseya will take nearly 3 hours. The same thing initiated from the PC with it downloading patches and restarting JUST twice, takes 24 minutes. Kaseya support tell me that's normal, but I don't think it should be normal.
I understand that for many 3 hours isn't that big of a problem since they patch overnight, but we patch machines we sell and they might be on a tight deadline for delivery. 3 hours for patching doesn't seem reasonable, especially since the patches are coming off our lan at GB speeds as opposed to Windows Updates coming down at the maximum speed of our Internet which is 80Mbps.
this is just the way patch management works. You cannot compare this with windows update, because it are different systems.
when I have a deadline for delivering new systems, I just don't update in front, but install the pc and afterwards let patch management update the system.
You deliver PCs and put them into production knowingly missing possibly very critical security patches?
No, I just said I patch afterwards. What I mean is when I have a deadline for delivery, I bring the pc and afterwards install updates. This means, when I cannot update before delivery, I bring the pc and before I leave, I have setup the pc to install updates. At that moment, it still takes some time before the pc is up to date, but the pc is deliverd. Sometimes you just don't have a choice here.
Also, as the client has to pay me, he can decide to deliver a pc without updates installed. I mention it can have some security risks, but it's not my call.
While I can't offer any definite answers, I've noticed this as well. Initial Update takes FAR longer than regular Windows Updates. While I can't comment on how patch management system works, they definitely can be compared because they both perform the exact same function.
I'm sorry but suggesting you can't compare the two isn't right. They are products that do the same job and actually I can patch less with Kaseya than I can with WU, as I can do drivers etc with WU. They shouldn't take 4-8 times as long to patch a machine.
I'd like to agree with networkn, Kaseya patching does take a good bit longer for things that normal WU patching handles in a quicker time frame. It's a sore spot for us as well.
While these are valid points, Kaseya is not comparable in the fact that their methodology is different to Microsoft's and I think this is the point Tjibbe is making.
This being said you are always able to make a feature request for the time this process takes to be improved. I personally take a similar approach to Tjibbe and just install the patches later, but it would be nice if Initial Update was faster.
Also, 3 hours is pretty good. I did some testing in my lab the other day with a WIn 7 Vanilla Office 2010 and initial update took 9 hours and even then it didn't install Windows 7 SP1.
This being said I am sure most OEM builds out there won't be as out of date as that machine was.
Ghetto, yah I have seen upward of 9 hours, too, esp with xp. We are just finding more and more compromise with Kaseya on a daily basis lately.
Pointless making a feature request, I am still waiting for stuff I asked for which is fundamental which I was told would be a priority from a few days after we got Kaseya. If they could make it faster I am sure they would.
Just to clarify, there are two different methods to install almost any patch (regardless of the use of a third-party such as Kaseya):
1. Via the Windows Update process (control panel or start menu) leveraging the Windows Update Agent (WUA)
2. Via the downloadable, distributable patch (the .exe, .msi, .msu, .cab, etc.)
Installing via method 1 will almost always be faster than option 2. WUA will download and install only the components of the patch the specific target endpoint needs. This communication is smooth, does not require user interaction (in almost all cases), and the MS WUA agent communicating to the MS patch sites to patch the MS OS is pretty seamless.
Installing via method 2 requires all components of a patch be downloaded and executed. This may result in a larger amount of traffic between the download site and the endpoint than method 1. This can be easily tested - download the patches from MS and install them and compare the time it takes to do that v. the time it takes to install the same patches using the Windows Update function.
Specific to Kaseya, which method we use for install will depend on the endpiont's file source configuration, the type of patch, and the function (within the VSA) that scheduled the installation.
All patches that are flagged as "internet-based install only" will ALWAYS install via method 1.
Machine Update and Patch Update will ALWAYS use method 2 UNLESS the patch is marked as internet-based install only.
Automatic Update and Initial Update will ALWAYS honor the file source configuration
Method 1 (WUA-based install) is use when File Source configuration is set to Download from internet
Method 2 is used when File Source configuration is set to System Server, LAN Share, or (for those running 6.3) LAN Cache
WUA-based installs will almost always be faster on a per-machine basis, but they can generate more overall traffic to the internet at a single site. LAN share/System Server configuration allows the endpoints to get the distributable patch files from an internal source. That source machine will download all of the patches that any requesting endpoint needs, retain those patches within the repository, and distribute the patches to requesting endpoints. Barring issues (such as a bad download), each patch needed by the environment only needs to be downloaded from the internet one time. Patches are then distributed via the company's internal network. This saves bandwidth, but the trade-off is a potentially larger single file to execute.
WUA-based installs look like this:
100 endpoints configured to download from internet > WUA service is engaged on each endpoint > each endpoint sends requests to Microsoft to install the necessary patch components.
Distributable patch installations look like this:
100 endpoints configured to the same LAN Share send requests for patches > One LAN Share downloads the patch(es) from the internet > Patches distributed to the endpoint and executed via command line
If your file source configuration is to use a LAN Share via System Server, the process is longer. Those patches are downloaded from the internet to the KServer, sent from the KServer to the LAN Share, then sent from the LAN share to the endpoint.
As you can see, depending on the specific file source configuration and method of installation, the time of each process can vary. Each execution should be timely, but you will find that, most often, "download from internet" will take less time than "from LAN Share via Internet" which will take less time than "From LAN Share via System Server". This isn't a function of Kaseya slowing the process; rather, it's a function of the configuration based on business needs and amount of available network resources, bandwidth, and processing power of the machines involved.
Out of curiosity are you using the patch share? Cause I believe windows updates uses BITS so doesn't always download the whole patch, whereas I know that Kaseya downloads the full patch.
Personally I havent had any issues with Patch Management, I don't sit there with a clock watch. Our systems typically go into a staging area in our office or at the client before being used live.
This is what I don't get about the explanation from Kaseya (and thank you for the detail).
My lan is attached via GB, all patches (or lets say 95%) should be on the LAN cache, so as far as I understand it, Kaseya determines which patches are required and should copy and install them via GB, as opposed to let's say 10Mbit for our internet connection taking into account Internet congestion. I am failing to see how patching from the Internet could be in any instance, faster.
Obviously the issue is not bandwidth. With initial update, as explained when you schedule it, Kaseya installs some patches, reboots, installs some more, reboots, etc. On top of this, Initial Update is re-scanning the machine after each reboot to work out what patches are now required and goes from there. It is this re-scanning and rebooting that takes a lot of the time and in fact there are times when the machine will in fact be sitting idle (such as waiting for the next patch scan to start which is often scheduled to run in a few minutes rather than immediately as they allow time for the machine to reboot).
As you know with manually running windows updates, not all patches are installed on the first go. You need to re-run an automatic updates scan after rebooting and then download the next bunch. Now granted MS Update does this in fewer reboots, but this is because Kaseya have planned out a different methodology for their Initial Update process that involves more reboots.
At the end of the day, Initial Update is not the fastest method to get updates installed and as Brande has pointed out it never will be. If time is of the essence, running Windows Update manually is probably the way to go. If on the other hand you want to let the updates run overnight and you don't care how long it takes, Initial Update will do the job and is very thorough as far as automated processes go.
True, providing that you have the patch share configured, credentials are set and your patch management is set to obtain from that source on that agent. Depends on your agent template and also whether that agent template has been fully applied on a new agent install(often it takes time for settings to be applied and audits to run etc). Some organizations don't use a template for each client, so really depends on what template you have.
You can usually see from the script log and agent procedure tasks where it is getting the patches from, also whether it is downloading the patch or whether it already has it.
Thing to note about initial update as well is that it is constantly doing patch scans, before and after every reboot. This takes additional time, cause the idea is that it might install an OS service pack and then run a patch scans and only install the patches for that service pack rather than patches already addressed in that service patch. Shouldn't be taking the time you are reporting though.
I dont really know what the issue is, just would suggest checking all above is in order and otherwise lodge a ticket.
I usually tell my engineers that I dont pay them to sit and watch them to wait for patches install or watch paint dry, Kaseya is one of the those tools that automates things across many PCs and saves time if you doing lots and lots of PC's simultaneously... However its not the best tool to run and want things to happen instantly on. Honestly if you want to patch just one PC straight away and your going to sit and watch it then you are better off running windows update. But if you want to click a button to patch 20 or more PC's and then think about it tomorrow then Kaseya is the tool.
Yup I understand what you guys are saying, but why does Kaseya do things in a LESS efficient way? Yes we need to run Windows Update Twice, so two reboots, but if MS Doesn't require a scan after each reboot, why would Kaseya? Surely it determines what it needs in step 1, and then applies all those patches and then perhaps does another scan at the end? You are right, we obviously can't use Kaseya for time sensitive upgrades, but then I am thinking should we just find a product that works the way we would expect. I am no sure if the same issues occur with other RMM products... The assertion that Kaseya is very thorough, doesn't seem to fit well with me, since WUA will do driver updates, which Kaseya to the best of my knowledge doesn't do?