Kaseya Community

Customer Name

  • Within Kaseya, I am designing a naming convention for machine groups.

    However there doesn't appear to be a concept of the 'client'.

    What's the best way to assign machines to a client who has multiple sites ?

    Is there an advised format to follow ?

    Thanks for your help.

    Legacy Forum Name: Customer Name,
    Legacy Posted By Username: richardpcc
  • Use child groups with naming policies.

    Client1
    Client1.west
    Client1.east

    Legacy Forum Name: How-To,
    Legacy Posted By Username: cnwicsurrett
  • We go with the following arrangement; two-letter top-level designation, followed by the client name, followed by the site name. Some examples to clarify:

    cl.clientname - Machine Group ID for a client with a single site

    cl.client2.ny - Group for New York office of Client2
    cl.client2.sf - Group for San Fran office of Client2

    cl.client3.hq - Group for "Main" office of Client3
    cl.client3.remote - Group for traveling laptop users of Client3
    cl.client3.home - Group for personal home machines that we support for Client3

    Typically we will move machines into appropriate groups manually, rather than use IP-based naming policies; that way when the VP of the SF office is visiting NY, he still shows up in the correct place. We'll default all new machines into the "base" group and move them as needed.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: Matthew Bartels
  • Matthew Bartels

    Typically we will move machines into appropriate groups manually, rather than use IP-based naming policies; that way when the VP of the SF office is visiting NY, he still shows up in the correct place. We'll default all new machines into the "base" group and move them as needed.


    There is no reason to "manually" move agents into machine groups, the naming policies are there to automate that process. Depending on how many agents you are managing, tracking agents manually might be easy, but still un-necessary.

    Legacy Forum Name: How-To,
    Legacy Posted By Username: cnwicsurrett
  • Well sure, and for the most part, agents go to the right group based on the agent package that gets installed. Just moving them to the sub-groups is often-enough *not* automatable that we do it manually all the time. For instance - how would you use naming policies to automatically put all "Home users on DSL" into the cl.client2.home machine group? Easy enough to put all the "Office users on LAN" based on their checkin gateway, but home DSL checkin gateways are going to be all over the board - no way to set a single policy for that!

    Also, make sure your reply is scalable up to cl.client90... we manage a *lot* of agents, for a lot of totally distinct clients Smile

    Legacy Forum Name: How-To,
    Legacy Posted By Username: Matthew Bartels
  • we have a few bands of service.
    lets call them Gold Silver and Bronze (for lack of imagination)

    We group things in Band.Client.Location. The benefit is all the Gold clients can be easily grouped together and have scripts applied.

    Our tree shows:
    bronze.cust1.geelong
    bronze.cust1.melbourne
    bronze.cust1.sydney
    gold.cust2.perth
    etc...

    Being able to easily group all our gold, silver and bronze customers together helps us deploy customizations between the bands more easily

    Legacy Forum Name: How-To,
    Legacy Posted By Username: garry