The last two patches and I think also the one before that (so 126.96.36.199 - 188.8.131.52 and 184.108.40.206) have behaved very different from before.
1. Runnning kinstall.exe as administrator and going for option 1 or 2;2. Kinstall then ends up asking for a reboot, something we 'never' used to get;3. After the reboot, about half the Kaseya services won't start;4. I then run a Reapply Database Schema - a sort of cure all for Kaseya woes;5. Finally I have to do a second reboot to fix the services not starting;I wonder if this chain of events sounds familiar or if we are the only ones experiencing this. A ticket was started for Kaseya, so will get input from them.
I can't say that I've run into that, however, my standard practice for patches has pretty much always been:
1.) Apply any pending windows updates and reboot.
3.) Run Kinstall and do the update.
3.) Run the reapply database schema
Back in the pre 9.x days, kinstall would pretty much always do the reapply schema at the end of an update, and based on that, and the fact that pretty much the first troubleshooting step with any issue is to do the reapply schema, I just got in the habit of doing it manually once the kinstall process stopped doing it automatically.
Then the reboot is just for "normal" cleanup purposes. Because of the nature and impact of having our Kaseya server out of commission, I normally only take the Kaseya server down for maintenance at most once a month, and sometimes only once every two months. So I combine all of this in one maintenance period.
I won't always do a Windows Update action before running kinstall, that depends upon the available window.
It has been pretty standard, having to do a Reapply Database Schema to complete a kinstall cycle. What threw me off, was the unexpected reboot request after running kinstall. If Kaseya wanted us to the Reapply before the reboot it should've been included in the prompt.
I had that problem also but I thought it was related to our database problems that occured after it was moved to a new mssql server.
The ticket with support didn't result in any possible cause and cure. I've asked for Kaseya log files to be examined, but they only looked at the Windows eventlog. I already knew there wasn't much of interest there and I wouldn't really expect it. I do expect some Kaseya logging would have caught the issue.
I was asked to start a ticket when we had the issue again (should be with patch 15), but we normally patch during the weekend, mostly on Sundays. So, creating a severity one ticket for it, wasn't really appreciated...
Last night I was in the quest for one of the best portal which can let me know about how to disable touch screen windows 10 suddenly my friend suggested me to try out this portal really it is working and provides all useful information.
For a while I had to reapply database schema for every patch I did, but I would say about patch 20 or so in 9.4 that stopped and I haven't had to do it since. (Well for a patch install) Requiring a reboot has happened on a couple patches before. I have expirenced those services not starting but usually after I reapply the schema I can start the services that are not started without a reboot.
kinstall.exe has always been a crapshoot. Services randomly not starting (or stopping), schema re-applies, reboot requests, prerequsite checks barfing on screen resolution (of all things!). you name it we've seen it.
The *** thing can't even give a success or fail indication on completion..it just....exits.
Worst. Installer. Ever. //comicbookguy
I know how you feel Craig Hart about the kinstall. It's less than perfect, I can only agree. I've seen all those things as well, but only recently the issues have gotten more extreme.
The lack of a fail or succes is a sorely missed part and should be easy to add. Unfortunately you, me and the rest of the Kaseya users would have to create tickets for it to make it important in the eyes of Kaseya. They seem to have formalized the things they want to fix, I'm hoping to learn more how, during the European Connect in a few weeks...