Kaseya Community

Managing machine onboarding / offboarding - it's chaos!

  • We are struggling to manage machines that are coming in to Kaseya, and also the ones that should be removed from Kaseya. How are you people managing this?

    The Kaseya download link is public, and many of our clients know the URL. We see new machines popping up all of the time. I get an e-mail about new machines, but I'm too busy to act on them. Should we raise a ticket for these?

    When machines are retired, we're not always informed, and we suddenly find that we've been running maintenance on machines that have been given to staff to use at home. I've created an Agent Procedure that will uninstall Kaseya for machines that match a list of serial numbers. This is useful *if* we've been told that the machines should be offboarded.

    Any ideas?

  • We removed all of our download links from the public page and if they want to have Kaseya on it they have to call us. OR We have lan watch set up on clients that want machines automatically added to Kaseya if they don't have it installed. The scan times vary based on client needs.

    I don't know how excatly you charge your clients but we have a built in charge per machine basis.  If they don't tell us a machine is being retired, that is on them and they will continue to be charged for the maintence of the machine. So don't really "worry" about that.  

  • We charge per machine per month so if people want to add systems or take computers home with the agent still on, I am happy to bill them for that.....but we have not had a big problem like you are describing.

    Twice in the 12 years we have been using Kaseya I have seen a random machine added to our VSA by unknown people so we now turn off all install links that aren't actively in use.  That could help half your issue.

  • Hello Lothario,

    I would recommend removing the packages from showing on the download page.

    You can then share the links to specific packages when required and just recreate the same packages over time to create new links so that they are not passed around.

    This way you are controlling who downloads the package.

    Click the package name in Manage Packages will give you the specific link for that.

  • The way I have set up Kaseya is that all of our customers are Organizations (and their ID is their customer number), and their respective Machine Groups are machine types, be it application server (app), SQL servers (sql), management servers (mgt), workstations (con for console), etc.  In that way, all machines in Kaseya belong to specific customers at the organization level, not just whatever they're named.  

    Then, all of our download links use generic mycompany.root org/group definitions, so when new machines get added, they'd have to be renamed and grouped by us and added to customer sites.  In that way, we don't really do anything to machines with generic names, they mostly just get ignored.  I use policy based monitoring that looks at these machine group types (like "app" servers) and those get specific monitors applied, and so on and so forth for each machine type.  So the generic machines don't get any policy treatments.  

    In that way, you could control how new machines come in when they do, and always go through the list of generically added machines and delete/uninstall the ones where you have no idea what they are.  

  • 1. NO download URLs are made public.

    2. Clients that use VSA have access to group-specific agent installer links in the System menu. They are told not to download and install from saved copies or to use GPO-based installers. Customers without VSA logins can't install agents.

    3. We use automation to onboard the agents - install apps, audit, auto-apply monitors, updates, etc. with virtually zero manual effort. The audits detect what's installed and apply the proper monitor sets, with automated, daily checks to add/remove configurations. Agents are organized consistently by customer.type.class.location, even if they have only one class of system or one location. Easy to organize, find things that don't belong. No "where's Waldo" games!

    4. We bill monthly for agents and agent management - if someone gives a PC to a home user, they have to tell us or they keep paying. We also report any agent that hasn't checked in for 45 days to the client for Keep/Retire decisions - we keep billing until 90 days without a check-in or told otherwise. We're now usually told otherwise! :) Agents cost money, we tell them, so it's in their best interest to be forthcoming with equipment retirement notices.

    4a. While we don't have many break/fix clients, the 30 or so agents in this classification still have a monthly charge to "allow remote support on demand" that more than covers the cost of the agent. If you give it away, it has no value.

    5. We have an official off-boarding process that wipes any proprietary or confidential data from the machines before removing the agent. It also resets the local admin password. We explain to the clients that failing to do this can leak sensitive information into the public or create unwarranted risk. Most are now thrilled to go through the decommissioning process.

    6. Agents that "appear" in a non-customer group (audit, builds, unnamed) are removed without notice. We have sub-groups for Audit that allow multiple client audits to occur, so machines in the root audit group are considered invalid.

    It's about order, structure, rules - and following them. Without it, you have chaos.


  • - You've got a good set of rules, which matches our own, more or less.

    Define what you want, tell customers what you do and how you bill and that ensures you don't end up losing money. And I like rule 5 about the local administrator account, considering the new GDPR rules it's a good safeguard to leaking information and it ensures a clear transition in authority.