I'm sharing the bullet points from my internal e-mail to Engineering & Customer Success on patching of Windows 7, 8.1, Server 2008 R2, Server 2012 & 2012 R2 and Windows 10. I'd love to know what other Kaseya users are doing and how they're messaging this to their Customers.
Care to weigh in?
I have thought of this future limitation concerning and affecting the patch management on our systems. My ultimate concern is if/when microsoft releases these roll-ups, will Microsoft give us the ability through cmd or powershell to rollback problematic updates and if so in what scope?
While I consider us at the mercy of Microsoft in this regard; you did pose a potential business challenge and opportunity for all RMM vendors.
Can and will Kaseya be the first to leverage this new approach in their favor? Personally, I hope so.
Kaseya can't and wont be the first to leverage anything with a third party, have you ever seen how they handle issues with AV modules? it takes them months to fix issues with it, because they don't really have a flexible or open relationship with third party developers. And when these third party developers make a change the farthest thing from their mind is "Oh will this screw up our friends at Kaseya" They don't think that way because Kaseya doesn't pay them enough to make the slightest considerations on there behalf
The long and the short of it if is an issue within core will be resolved quickly anything else that relies on another company gets the long drawn out wait .
I can understand Microsoft's desire to remove control of system patching from the public but it's completely unacceptable, in my opinion, to remove it from the Enterprise. I would also be very surprised and amazed to hear that Kaseya had wrested control of patch management back from Microsoft and I don't expect that to happen in my lifetime.
I've been a Microsoft supporter for most all of the last 20 years but, the more I see of what Microsoft has done with Windows 10 and how frequently they are thumbing their nose at Enterprise management in so many ways, the farther I get from wanting to stay with them. Were retirement not looming I would be taking a very hard and serious look at moving the computer systems, of the company that employs me to manage their systems, away from Microsoft and off to some other solution...
oromeroCan and will Kaseya be the first to leverage this new approach in their favor? Personally, I hope so.
I hope so too. I'm looking forward to seeing how the new patching & third-party software update module behaves in the 9.4 beta (though I obviously won't be able to share my impressions beyond the beta group). The granular & process-oriented manner in which we handle patch distribution has always been one of our key differentiators, and I hope that whichever third-party solution Kaseya integrates into the VSA to replace the largely reliable but dated Patch Management module can address these challenges--particularly rollback if we identify a "bum rollup" that borks a bunch of machines.
timypcrThe long and the short of it if is an issue within core will be resolved quickly anything else that relies on another company gets the long drawn out wait.
I'd argue that, regardless of the third-party integrator, patching functionality is still part of the core functionality of the product. Kaseya Support had better be ready to not "punt the football" to the integrator when they hit the ground running with 9.4...
zippothe more I see of what Microsoft has done with Windows 10 and how frequently they are thumbing their nose at Enterprise management in so many ways, the farther I get from wanting to stay with them
Way of the future, my friend Office 365 / Azure are gaining significant traction, Windows is becoming an operating system as-a-service, on-prem servers are an endangered species, on-prem phone systems are being replaced with cloud-hosted PBX at nearly every refresh, and Customers are insisting that all of their capital expenditures transition to operational expenditures as soon as possible. Anyway, a bit off-topic... I'm not saying traditional enterprise management is dead, but it's definitely undergoing a full & rigorous health assessment with vendors lined up to replace the worn-out legacy bits with bionic appendages.
/ I haven't yet had enough coffee to make good analogies
This is certainly a 'hot topic' among MSPs and Enterprise IT departments at the moment, and worthy of extended discussion.
I'm in favour of moving to a cumulative update model for several reasons.
1. Patch fatigue set in for me years ago - having to try on a monthly basis to sufficiently review, test and approve dozens of patches each month for a half-dozen supported Windows operating systems across nearly 3000 endpoints (plus the same again for Microsoft Office) is time consuming, error prone, frustrating and thankless. Having to then follow up on why some seemingly random selection of patches failed to deploy on potentially hundreds of machines is just brutal. I want Microsoft to take back a large part of that responsibility - it won't be perfect but it will be better than what we've got now.
2. I like the idea that ISVs are forced into (shock horror) *maintaining their software* and can no longer hide behind ridiculous statements like 'oh we can't work with XYZ patch, don't deploy that'. Their malfeasance has gone on too long and I'm sick of having to come up with workarounds and put special exceptions in place to make up for their shortcomings.
3. Getting and keeping machines up to date will be significantly simplified. If you're on-boarding a customer who has previously had poor patch management, or if something goes wrong and machines miss a patch cycle or two you're still only one patch away from fully up to date.
Now - what's Kaseya's patch management role right now and going forward?
1. Scheduling. This is key - customers need to know when their machines will be patched and rebooted. Right now I think Kaseya's control over patch scheduling for 7/8.1 is very good but things seem to come a bit unstuck for Windows 10. There are good examples out there of products that can reliably scan and trigger patch installation on Windows 10 (see for example www.powershellgallery.com/.../PSWindowsUpdate) so there should be no reason Kaseya can't achieve this. Tight scheduling and control of update-related reboots with Windows 10 looks to be somewhat of a bugbear but there are 'active hours' settings that Kaseya could centrally control, and ultimately we need to make sure we have clearly communicated with the customer what to expect, even if the message is that we have less control than previous.
2. Approval. Right now Kaseya offers very granular approval pushing the work back on us to 'pick and choose' the patches we need, but with the increasing move of products to a cumulative update / click-to-run / 'as a service' model this becomes less and less relevant. What I'd like to see is Kaseya taking advantage of the well-documented WUB registry settings for Windows 10 to allow us to centrally control the upgrade and update release 'rings' - setting customer machines to CBB with a 6-month upgrade delay and 2 week update delay, for example. With regards to the 'security only' cumulative update if you're leaning that way - although it won't be offered when scanning against 'Windows Update' it's a safe bet there will be a new release each month for each supported OS and it *will be* downloadable from the Microsoft Update Catalog - it's not a stretch to expect that Kaseya should handle scheduled downloading and installing of this update if we nominate this as a preferred approach. Presumably you could even switch streams when you felt the need - sticking with security updates only until you saw a compelling fix released in the latest CU, you test and deploy this, then move back to the security updates only stream until some later CU takes your fancy.
3. Distribution. I wish I could say I liked the whole 'LAN cache' implementation for patch deployment but I don't - it's finicky and annoying and I've run into lots of problems with it over the years. Additionally, with the move to cumulative updates the LAN cache will get increasingly full of huge outdated patches that we'll probably need to clear out manually. Windows 10 offers WUDO (Windows Update Delivery Optimization) and I would like to see Kaseya offer us central control of the registry settings for delivery optimization rather than try to use the oldey-styley LAN cache approach. Microsoft - if you're listening - if you're going to force a CU model for 7/8.1 you really should be back-porting WUDO to 7/8.1 too!
There's plenty more to delve into but that will probably do for now :-) I welcome everyone's thoughts and any constructive feedback.
I truly enjoy these high level conversations in the community!
I agree with Brian Dagan in regards to the opportunity Kaseya has here. They can set themselves apart from the 'rest' as technology trends are shifting it is important to have products agile enough to maintain their bloodlines through most changes.
I'll share my notes as well. We haven't started the communication process with our clients just yet.
has anyone heard/seen an update on this? October is next week and Microsoft seems very quiet for such a big change