After using Kaseya for a little over a year I have several re-occuring frustrations with patch failures that I feel I am spending more time than I should be resolving. Can anyone offer a reason why I have each of the issues below, if there is anything I can do to improve the situation and if not, what is being done on Kaseya's side to improve it.
1. Patches install sucessfully on the second attempt. - This is my biggest cause of wasted time on my part with patching. I would estimate that this is the case on about 5% of my machines each patch cycle. This leads to me spending a lot of time addressing tickets for patch failures, re-scheduling patch installs and following up on each machine. I have a fairly high number of machines to manage, so this becomes a significant amount of time.
2. Patches install successfully through Windows/Microsoft Update. - The majority of patches that repeatedly fail via Kaseya, are successfully installed by manually logging on to the machine and running Windows Update. By the time I work with the user to find a convenient time, log on the the machine, scan, install updates, reboot is necessary and then scan via Kaseya I have wasted a good chunk of time. I feel that I am using Kaseya to patch to avoid the need to do this. it is frustrating to need to do this on so many machines.
3. Patches install successfully when set to download from Internet only. - I run into many patches, most often for Office, that fail repeatedly on multiple machines evebn after deleting the source file from the on site file source. If I change to patch location to download from the Internet, these patches will install without issue. Why is this? I feel I am wasting bandwidth and time downloading patches repeatedly when I should be able to download it once to the server and deploy to workstations from there.
Thanks in advance for whatever help you can provide.
I can confirm the issue with having to manually install some difficult Patches via Windows Updates instead.
Wow. Six months have gone by and no answers posted. I can confirm I'm having the same issues as well, and have for the nearly three years I've been using Kaseya. This kind of stuff is a MAJOR MAJOR problem with Kaseya, both in the product where I have to spend MORE time dealing with junk like this (failed or unavailable patches that work just fine when the end node manually downloads and installs through WU) than if I didn't use Kaseya at all, and in what appears to be a pretty consistent lack of support across the board (i.e. crickets chirping) from a company to whom I fork over around $30,000 a year. Absolutely unacceptable.
I'll just throw in my $.02 that we also have a lot of issues with patches failing to install. Once in a while it can be chalked up to the file source or credential being wrong, but more often than not everything is setup correctly and we just end up doing manual installs of the patches.
@kcears - I agree with you completely.
And the outcome is either success or fail. There is no specific details as to why the patch failed.
Something like the following would help a lot in my opinion.
-patch failed to download
-patch downloaded, but installer didn't run
-patch downloaded, installer ran, but installer failed
Now if you contact KSupport they will tell you:
1. Try to run the patch again through Kaseya
2. Try to run the patch manually logged in to the server in question.
Which is the same response they give to everyone instead of looking for ways to improve their patching system and the errors it generates.
I have the same exact issues. I actually made a post just before I saw this. It seems to happen the most with service packs or .net installs. Going over and manually doing via Windows Update or standalone install works fine, but what a complete waste of time when Kaseya is supposed to be managing this for us.
I would just like to add that 5 months later I am just as frustrated with patching as I was then. I installed patches on my systems last night. This morning, as normal, I have at least 150 machines with patch failures. That number is just unacceptable when 95% of the failures I see install correctly using Windows Update. I have used other patch management systems and I never had to waste this much time before.
Is anything being done to address this? Add this to my frustrations with KES, agent updates, alerting and Acronis and like others on this board, I am starting to seriously weigh other options.
Patches can fail, but there will always be an underlying reason. However, the exact reason will depend on your environment, the endpoint, file source configuration, method of install, and a handful of other variables. A patch that "installs correctly using Windows Update" but fails to install through Kaseya can be due to an incorrect file source configuration, incorrect permissions to a share, a requirement - built into the patch by Microsoft - to have an interactive user present at the time of install (which, if you're installing locally via WinUpdate, you've logged on to meet this requirement), a conflict with a security software (which is sometimes alleviated when a local user with sufficient privileges is logged in), the status of Microsoft's Interactive Services Detection software (which has caused an issue with some patches recently), invalid detection logic within the patch itself, incorrect command line switches, corrupt .api on the endpoint, corrupt WUA installation (which can sometimes self-repair so the issue repairs without report of an error during a local install), network configuration blocking access (which can be negated when a user is logged on locally to a machine), or a variety of other things. When you experience patch failures, if you'd like to determine the root cause of those failures, please open a ticket with support.
Probably better than 95% of the time I can determine the exact root cause of the issue. Sometimes, as part of testing, the testing results in a successful install without determining the exact root cause, so there are rare occasions when root cause cannot be determined. However, if there is a systemic issue that isn't being addressed, then failures will continue. If there's a problem with switches, then we can address those only as they're reported - and once we're aware of those, we address them usually within one business day of determining that is the issue. If there's a patch that requires an interactive user in order to install successfully, we can help identify those so you can know of that requirement and be prepared to deploy them when a user is present (or deny them if your clients/users cannot tolerate that level of interaction).
If an endpoint is installing most patches but failing to install a few, then the issue could still be due to any of the above listed causes. It will depend on the type of patch, file source, etc. If you want to determine the cause of any of these, open a ticket, provide the KB number of the patch(es) that failing, and at least one example machine that is failing that patch. That's usually enough information to get started. The troubleshooting can often require you to complete some testing and report back results, but if you want to determine root cause of those failures (particularly helpful in identifying systemic issues to minimize overall failures), we can always assist with that.
i actually dont have a problem with patching and we have 5600 machines now.
Have you guys performed the "managemahcines\patch status\TEST" and does it Pass
Have you set the reboot action to close to your "Automatic Update" time ? or are the users shutting their machines down
whats wrong with agent update and alerting eperson ?
@eperson - I also experience issues with patches. Sometimes I have to just run them again and they work, sometimes I have to log in and manually run windows updates to get certain patches installed. It's definitely not a set it and forget it function, it unfortunately requires quite a bit of hand holding and manual intervention. As Brande noted above, there are reasons for this, although I wish that the patch failure notifications were more useful than they are (it failed and that's good to know, but tell me why).
@Brande - Thank you for your post clarifying all the various reasons patches could fail. With that knowledge could a full "Troubleshoot your patching issues" workflow diagram be created to help teach all of us how to determine root cause on patching failures? Maybe we wouldn't achieve 95% accuracy like yourself, but I think this knowledge would be useful, and would probably reduce the number of people sending in tickets for patch failures.
ssugar - That's actually something that I'm working on. It will cover the data flow, but also provide troubleshooting guidelines. It should help walk those unfamiliar with troubleshooting (as a general skill) through troubleshooting failed patches. It will give those with solid troubleshooting skills the jumping off point to understand how the process flow works, what to look for, and how to correlate patch failure data in Kaseya to data in Microsoft logs (and when that's irrelevant) so those folks can use their existing skillset to find the deeper root causes. I can't cover every single conceivable reason a patch can fail, but this doc should cover enough scenarios that can be leveraged to figure out the oddballs. I also plan to include some "down-and-dirty - just-get-it-installed" guidelines for those times when you need to get something deployed and don't have the time to figure out root cause. Windows Update is usually an option for most folks, and sometimes does become the best way to get something deployed immediately that you don't have time to troubleshoot - but there are a few ways you can force an almost-similar install through Kaseya that works pretty well.
My whiteboards are covered with this document, and I've got a decent draft. I'm working to ensure it's both accurate and provides both the simplicity and depth that's needed. It's coming, but it'll be a bit longer. In the mean time, if you have failures and want to figure out why it's failing, open a ticket. With any support organization, there are two general approaches for tickets - Make It Work Now and Determine Root Cause. Taking the time to determine root cause can take quite a bit more time and often more effort on both sides, but I'm always willing to help with that when you want to find out the underlying cause.
@Brande - Amazing. I'm very happy to hear this and am definitely looking forward to your document.
If you'd like someone to read through it and provide constructive feedback at any point in your process, I'd be more than happy to assist.
Thanks, ssugar. I'll keep you posted as soon as I've got a draft that needs fresh eyes for testing/validation.
@Brande, this would be very useful and I woul dbe happy to input as well.
I would like to chime in with my thoughts on this one. Since @eperson manages the NOC for my firm, it is very important to me that we don't end up with situations each month where he has to spend too much time troubleshooting failed patch installations in Kaseya.
@Brande - you listed a number of possible reasons why a patch install via Kaseya might fail, where it is successful when installed via Windows Update. Let’s go through them one at a time.
1) an incorrect file source configuration -> Would explain the failure of ALL patches via Kaseya, but I don't see how this would explain the failure of 1 or 2 patches for a managed computer, when other patches install successfully via Kaseya.
2) incorrect permissions to a share -> Same as above, would explain the failure of ALL patches via Kaseya, but I don't see how this would explain the failure of 1 or 2 patches for a managed computer, when other patches install successfully via Kaseya.
3) a requirement - built into the patch by Microsoft - to have an interactive user present at the time of install (which, if you're installing locally via WinUpdate, you've logged on to meet this requirement) -> I used to be a lot more involved with Kaseya patching myself, now @eperson has that responsibility, but I am pretty sure I recall a setting or note displayed for patches that specifically say a user must be logged in (used to see that a lot for older MS Office patches). If Kaseya notes that requirement, then that would certainly be a valid explanation. But absent that notation, I don't see that being the cause of the patch failures experienced by @eperson.
4) a conflict with a security software (which is sometimes alleviated when a local user with sufficient privileges is logged in) -> the credentials configured in Kaseya for our patch deployments have administrator permission, so I don’t see how that is the cause of why the patch installations fail via Kaseya. Also, we use KES, so it is Kaseya’s own security software product.
5) the status of Microsoft's Interactive Services Detection software (which has caused an issue with some patches recently) -> I suppose this could be a cause. But is this specific to Kaseya patching? Wouldn’t it also occur with Microsoft Windows Updates? (which @eperson reported works successfully most of the time)
6) invalid detection logic within the patch itself -> I suppose this could be a cause. But is this specific to Kaseya patching? Wouldn’t it also occur with Microsoft Windows Updates? (which @eperson reported works successfully most of the time)
7) incorrect command line switches -> Seems like a problem caused by Kaseya. Shouldn’t we expect correct command line switches?
8) corrupt WUA installation (which can sometimes self-repair so the issue repairs without report of an error during a local install) -> I’m not sure how a corrupt WUA could be present, causing the failure of a patch installation via Kaseya, but then self-repair itself to allow a successful installation via Windows Update. I’m curious to learn more about this possibility.
9) network configuration blocking access (which can be negated when a user is logged on locally to a machine) -> the credentials configured in Kaseya for our patch deployments have administrator permission, so I don’t see how that is the cause of why the patch installations fail via Kaseya.
You suggested opening a ticket with support to determien the cause of each failure. I can see where that makes sense. I suppose I just wish it wasn't necessary in the first place.
If you have any more info on the items above that are not related to permissions, security, configuration, etc, I would really be interested in hearing more details and explaination.
Thanks very much
Just on this very broad Kaseya Patching issue
I have noticed that out of date root certificates can prevent updates from being installed and that Kaseya Patch Management does not seem to install them every time a new version of the root certificates is released.
I have also noticed that sometimes when you install a Microsoft Patch, Hotfix or Service Pack manually via the Windows Update it will still show that the Patch, Hotfix or Service Pack is missing under Kaseya no matter how many patch scans you do or minutes hours or days your wait for it to update. In this case the only way I managed to get the patch info under Kaseya to update is when I reinstall the agent and force it to create a new agent entry in the Kaseya DB, this is not very ideal as you also lose historical data for the agent.
Unfortunately I don't have any examples of these issues at this point in time which is why I have not logged any tickets with Kaseya Support.