Kaseya Community

Important speed and reliability update for KLC on kservers running 6.2!

  • Hi.

    I think that should just be a bad plugin or old files remaining on your PC. Remove the plugins container and the KLC Plugins as per the KB knowledge base and you should be fine. I am reasonably confident if it works from inside your lan to remote agents, remote to remote agents should be fine as well, it's just a case of making sure your browser doesn't have any remnants.

  • Ok after reading  Brian Dagan post and having currently about 9000 clients in my system, I am NOT looking forward to install this patch and do the agent update. Can anyone from Kaseya please tell me how to approach this in the best way? Whats the deal,  do I need to schedule 10 at the time or can I go ahead and schedule 100 or 1000?

  • Whilst I agree with Brian that Kaseya should make it easier to get this list I don't think it'll be on top of their todo list.

    Yes, when scheduling in a load of *anything* in Kaseya you'll get timeout errors you need to split your data up into more manageable chunks.  I did servers first then broke workstations by type and if they were online and haven't had one error message, perhaps that's because I'm used to doing this with very large numbers of agents.

  • @Grape - I will echo Alistair's approach.  Doing things in phases will make any exceptions more manageable.  

  • Alistair Curran

    Whilst I agree with Brian that Kaseya should make it easier to get this list I don't think it'll be on top of their todo list.
    Yes, when scheduling in a load of *anything* in Kaseya you'll get timeout errors you need to split your data up into more manageable chunks.

    That's pretty much the response I got from Support... I won't copy the whole thing here, but key points are as follows:

    • Break up agent groups into chunks (per @Alistair and @Brendan Cosgrove)
    • Trial-and-error: Determine roughly how many you can schedule & divide your groups accordingly
    • The Scheduler isn't robust enough to handle that many schedulings at once
    • They will explore adding the KLCVersion attribute to the Advanced Filter options
    • They will explore alternate means to push the Agent Update (either make a more robust scheduler or something)

    So... to the Feature Request queue with you, ticket!

    In regards to adding my KLCVersion to the view, I think anybody can do that now (though you'll still have to run an Agent Procedure to populate that now-visible variable into a Custom Field before you can build a View based on it).  Similar approach to @Alistair without having to grab the text file, but really our approaches are six of one, half a dozen of the other.

    Happy Scheduling!  Stick out tongue

     

  • Just curious - has anybody implemented Alistair's "KLC Version Info" script as the "After update run agent procedure _____" option in the Update Agent function?  Or is "Deploy Live Connect" still the necessary script-de-jour for that setting?

  • I created a new procedure that runs Deploy Live Connect and also updates the custom field to save a little time and keep things up to date.

  • Cool, that's what I'll do.  But wait... maybe this has been answered before, but is Deploy Live Connect actually still required since the agent update updates KLC too?

  • Deploy Live Connect is no longer needed with the latest updates.  

  • Thanks for the info Brendan - will edit my procedures.

  • Brendan I don´t get it. Is this an official update or a Beta hotfix? If it is an official update shouldn´t I be able to trust the update/schedule functions in Kasyea and do this update in a stable and functional way? we have around 8000 clients and around 20 first line personal that daily uses the Remote control function to a large number of clients in Kaseya. This will hav a big impact on the daily business.

    I shouldn´t expect ANY errors at all when using a schedule function in kaseya what ever it is or dispite the amount of clients I choose to run it on.

    So my questions are still unanswered. HOW should I do this update on my 8000 clients without getting any problems?

    Br

    Anders

  • @Grape: Conclusion I've come to here is to just go group-by-group (client-by-client).  Yes, very time consuming, I know, and at the very least, Kaseya is aware of the problems with the scheduler's... shall we say... "capacity issues."  I've dug around in their code, and I definitely see why the scheduler, as currently implemented, can't handle more than 100-200 machines at a time (at least in my environment).  So ultimately, I'd say a re-architecting of the scheduler is definitely in order; however, at present (and I think this is also the response you'll get from Kaseya), you can work around the issue by using smaller groups.

    In regards to your 20 front-line personnel, the Agent being on "6.2.0.0" or "6.2.0.0 - 1.2.0.22" is largely irrelevant... they can still use the Remote Control function... the Live Connect patch is only a "speed & reliability improvement" (per my understanding), so they'll still be able to Live Connect to the 6.2.0.0 machines as well (albeit in a "slower" and "less reliable" fashion, whatever that entails Stick out tongue).  The lack of this patch does not "break" anything per-se.

  • Have to agree with Anders on this one.  Why are we having to install this fix manually?  OK it's a one off and I won't need to do it again.  Or will I when the next version comes out.  From the feedback in this thread it's obvious this fix has been received well by everyone.  Was this Kaseya's way of making sure we all knew they'd fixed the problem?  Had it gone on as an automatic update we likely would have noticed but perhaps not noticed how or why?

    I also don't think getting all your agents updated is that urgent.  Again perhaps Kaseya could help these updates to be applied over a period of time without crippling bandwidth and server capacity.  

  • This was an update that we wanted you all to have as soon as it was ready rather than wait for the next framework update.  That's a good thing right?   Because of the nature of the code changes it wasn't considered a hotfix so we called it an update, and because it was going to touch all agents we didn't want to push it automatically.  Bottom line is that we know that you know your endpoints and your kaseya machines groups etc better than we do, so we put the power in your hands to complete this update.  

    With thousands of customers it is sometimes very difficult to decide how we deliver updates, so we have to make decisions like this from time to time. Hopefully having the update and the write up on how to do it proved helpful for most.  There are always exceptions.  Always.  Support is here to try and help you through those if needed, and obviously bouncing ideas of folks here in the community is helpful for some too.  

  • We do want the update and it doens´t matter if it´s called update or hotfix don´t get me wrong. And it´s OK that you don´t push it out automatically and yes we do like to have control.

    But I can´t say that we have any control with this update considering what the other users on this forum has experienced with this update. If we hade a couple of hundred of agent then Yes this would be simple. But having to break up 8300 clients into groups of what 100, 200, 300, 400 ? That may take a while.

    With this said we will dig our hands in the dirt and do it anyway because it is good update.

    But I just want to say what has been said in the thread " Call for Kaseya to shift development focus...fix the core modules not add more modules"  many many times:

    We want the Core functionality to work, in this case the Agent update schedule!