So, here are the issues I find currnetly with the patch module (PM 2.0):
1. A number of windows updates are now "multi-OS". e.g. KB2604114 is for both Windows 7 *and* Server 2008 R2. If you do automatic patch approvals by platform, these patches are NOT approved for every OS; if I look at the patch details screen, Kaseya only sees this patch as appropraite for Server 2008 R2; therefore it is not approved for Windows 7 by default, and I have to go and manually approve it.
So, the bug is that K can't handle Multi-OS patches.
2. Duplicate patches. KB2890788 appears 4 times in my VSA; each instance has different patch approvals, despite them being the SAME patch released on the SAME date. All have the same 'data source' GUID identifier, but different Update Identifier GUID's. This is NOT the same as patches like KB890830, which keep the same KB number but are different updates (a new version is released every month).
3. Approval by patch - there should be a way to select which policy(s) a patch is approved or denied by - not just "all" or "none".
4. Patch scans on server 2012 & windows 8. You need to run a patch scan manually on the machine and agree to 'get updates for windows and other programs' before the patch scan works (you get an inaccurate offline scan otherwise). This needs to be fixed.
5. Patch scans in general - if the WU service isn't running, why not just start it, rather than writing a massive error message all over my patch status screen?? Why not just note that the last scan failed in the patch results column, and show the most recent data recorded in the other columns....i'd rather see the last data I successfully captured (even if outdated), rather than have it all hidden by a massive red error message.
6. when you bring up the missing approved and missing denied screens (and the approval status screen in approval by patch), why not have a button to change the status of the patch (i.e. deny or approve)? It would apply then to whatever policy(s) the machine is a member of; that way if you notice you haven't approved something, you don't need to write the KB number down then drill through a bunch of screens to update the approval status (remembering that you can't just approve by patch number thanks to the limitations mentioned in point 3).
7. in approvals by patch screen, when searching, can you just make the "kb article" filed ignore if you put the KB in the box? Currently if you copy and paste e.g. KB396020 it complains - you have to strip off the letters KB and just input the digits, which is annoying as KB numbers don't have a space, so all copy and paste processes generally include the letters. A small change to the UI, but a huge change in usability!!!
8. When applying patches, the pending procedures info just shows a generic message, no matter how many patches are pending -- from this it is hard to tell if there is progress being made, or roughly how long it might be till completed. A more detailed outcome would be better; I'd prefer one pending procedure per patch; this would allow us to see how things are progressing and more detail without having to try and read the agent procedure log, and more importantly, have more control over cancelling individual patches.
Just some thoughts..............comments anyone?
Did you get any traction on these issues with KSupport?
Frankly, I've just posted them here so far. I've given up putting through bug reports and feature requests for now; waiting until post-January release to see where things go before reporting issues as I suspect the playing field is about to change radically anyhow.
I'll address your items above as best I can.
Item 1: MS has changed the way they tag patches, and that's something to which Kaseya must react. We currently recognize a patch as unique from any other when the Update ID (all four parts) and the Language differ from any other patch known to the VSA. We often refer to this as a patch's Five Part Key. These five parts make allow us to identify the unique patch. With MS leaving these details the same but changing only the Product, we are not recognizing a changed product (but otherwise duplicated five-part key) as a unique patch. There has been discussion about how we will address this issue going forward. I would continue to recommend you open a ticket on the issue as tickets play a significant part in determining criticality and impact of issues. It isn't the only factor, but does carry weight.
Item 2: This goes back to the five-part key. You will see multiple versions (or "flavors) of a patch any time the Update ID and language together differ from any other patch known to the VSA. If the same patch is realeased 10 times, the release date, file size, etc. is all the same BUT the language is different, that is considered a unique patch and results in a unique entry in the DB. While the KB number is the same, the patches are actually unique to each other.
Item 3: This has been discussed for a future release of the product. I cannot comment on when/whether this will be included, but has been discussed.
Item 4: This is due to an update to the Windows Update client. Please review KKB000904 for full details.
Item 5: This was discussed early on (not in relation to KPatch 2.0, but in the 'early' days of the product as a whole), but the feedback from customers (at the time) was that Kaseya should not be making functional changes to the state of services on a machine. This approach has been reevaluated and may result in future changes that do result in auto-start of the service. In the mean time, admins will need to ensure that the services necessary for management are properly configured on endpoints. To mitigate, you could create an Agent Procedure to run on machines to start the wuauserv service.
Item 6: If this is functionality you would like to see, I recommend you submit a Feature Request for this.
Item 7: This has been discussed (a frustration I share with you, as well). This may be addressed in a future release, though I cannot say whether it will be included as a change in the January 2014 release. Again, it would not hurt to submit this as a feature request to add additional weight to this small but frustrating field.
Item 8: You can review the AP log for info to determine where in the process the installs are. There has been significant discussion about providing additional levels of visibility into real-time status. I do not know when this will be included in the product, but I know directly of some efforts that were made to include additional visibility. I cannot say when/whether this will end up in the product, but there has been R&D conducted in this area.
I understand that might not address all of your concerns, but I hope it at least provides you with a little insight.
This is a very important thread. I have 'sold' Kaseya to my new employer as a method of patching around 1000 servers (no desktops). Some of the frustrations above are a significant issue for us and I would like to add more. The once jewel in the crown (patching) for Kaseya is looking seriously long in the tooth and needs alot of work to modernise.
#5 - agree. This should be allowed by some sort of policy. servers can be different, sometimes you dont want it started.
#4 is a distinct concern and needs to be handled natively without special rules or procedures.
#8 is very high. I am training the end users on patching a group of servers and there is no real-time dashboard for progress. you just sit and pray that all is working well. Sure you can go digging around script logs but that defeats the purpose of an automated system. A status should be displayed on a single screen with % completed etc. This NEEDS to have a look and feel refresh to allow us to order by columns and do export to excel etc.
#9 - Working with WSUS. Getting Kaseya past a enterprise customer is a big ask. They usually want the perceived security of a WSUS server. Some servers are offline and cant go on-line 'by policy' and this makes automated patching near impossible. (integarate with WSUS for patching source)
#10 - That freaking yellow triangle! When you have a machines that should go online, can go online yet it decided that its going to do an 'offline' scan anyway, help the user solve the problem. at the moment I have to dig through the WUA log, which is horrible at the best of time. The 'test' button only tests access to kaseya and not to windows update itself for patching scans.
#11 - 'internet only patches' - there is an increasing about of these. This relates to #9 which is a completely offline system. The goal should be to allow machines to be patched completely offline.
This is just off the top of my head. PM is good. But its no longer great. Fix these issues and you are well on your way.
further to this.
#8 was solved by me in a morning. I wrote an SSRS report that shows all machines that are patching and thier progress. it even counts the individual patching installs from the logs allowing a crude % completed calculation. Im not a programmer but im OK in SSRS. If I can solve this in a morning given the data already in the DB, surely the perceived army of internal K devs and do a far better job in a pretty short amount of time.
Item9: This has been discussed and there has been significant R&D on allowing some level of integration with WSUS. I don't know whether this will be included in the winter release.
Item 10: If a machine is configured to use the online data source as the default and happens to scan against the offline data source, the 'reason' for the use of the offline source will be included in the Agent Procedure Log. Note that if the default IS to use the offline data source, then no entry regarding the 'reason' will be present in the AP log. To learn more about this, please review KKB000781.
Item 11: Some patches are internet-based install only because MS has not released a stand-alone (distributable) installer or because the only stand-alone installer is a non-supported type. Kaseya can install .exe, .msi, and .msu files via a LAN Share, LAN Cache, etc. Other extensions, such as .cab, or patches for which MS has not released a distributable installer must be installed via the Windows Update Agent. In these cases, the patches are marked as internet-based install only. Other times, the target machine has not been clearly identified for a given patch. Examples include: the patch notes it is language-specific but does not identify the target the language; the target machine OS version or type (32 v. 64 bit) is not made clear; the OS type is not evident. These are some examples, but there are several similar reasons. In these cases, the Windows Update Agent (WUA) is leveraged to install the patch as can directly communicate with MS to determine the appropriate version/flavor of the patch to install. Generally, fewer than 5-10% of patches on any given system are internet-based install only. If you are seeing increasing numbers of these, I recommend you address that concern with Support via a ticket at portal.kaseya.net. However, it is important to know that there will almost always be at least some internet-only patches as MS may not release a distributable version of some patches.
Thanks for your reply. I am aware of all these answers already.
My main point with all of these is that the patching module is degrading in value in the modern world. In its current incarnation its really dated in both usability and functionality. Its become increasingly full of quirks (2012/Win08) and the model is was built on needs work. It does great things but the 'last mile' of functionality is everything. Things like the 'test' button needed work a long time ago. people think that its genuine patching test and tear their hair out when patching fails after it passes the test!
Of course the 'reason' for the yellow triangle is buried in the logs and just shows the '0x3433442A' code anyway. But is that helpful? Its like the previous argument about telling us that the windows update service is stopped. is that helpful?
im big on 'usability'. Any automation tools should a focus on being helpful to the end user. Like alot of things Kaseya, the tech behind the scenes is really interesting and has lots of thought, but the user facing part can so often be less than helpful. This is where the work needs to be done and is long overdue.
Lets hope the next release delivers miracles.
Oh, I just thought of the other item i had been try to remember!!!!
#12 - Patching Staging: By this I mean 'pre-download' of the patches you want to deliver. When patching a server you generally have a window to work with, lets say 2 hours. It can be deeply frustrating to have the first hour eaten up by downloading of patches and then have to hope/pray you can deliver in the final hour. I have not seen a method of pre-downloading the patches ready for delivery exactly when you set your patching install schedule. in an enterprise environment, this is sorely needed. I really mean this, its BADLY needed! We should be able to set a 'staging schedule' that is 2 hours ahead of time.