Kaseya Community

Best Practice - Parent-Child for Org, or just Sub-Machine Group?

This question has suggested answer(s)

Good day,


Most of our customers are relatively small - one or two offices, couple dozen to 150 agents.  Each customer is their own scope and org, with machine group root renamed to  "main" and department group renamed to "dept".  We'll throw Servers into a sub-group, and Workstations into another subgroup.
Locations are typically under Servers or Workstations - we've not had any issues with site-specific needs (Patches / Scripts / Policies / etc...).

Example, using Machine Groups to identify location:

We have a customer which has a separate site, which they'd like to deal with differently.  We recognize that we can make policies / things happen differently thanks to views, however, we also know that an org can have a parent org.  As such, we're looking to see if we should have "location1" be a child organization of "customer", or if we should continue building on the "customer.main.[type].location1" mentality.

Example2, using Organizations / sub-organizations to identify locations:

Both will work, however, we're wondering if there's any real advantage to doing one vs the other.  With the first (Machine Group), we can apply things to all workstations across all locations, however I don't think we can really do that in the second.... At the moment, we don’t see the key differences or advantages of sub-organizations, or how this should be best implemented.  Which is best practice going forward?

Would very much like to ensure that we're not setting ourselves up for failure down the road.

Thank you!

[edited by: tkindree at 11:42 AM (GMT -7) on Oct 22, 2012] Minor change in wording for clarity
All Replies
  • why do you seperate workstations and servers in different groups? I use workstations and server in one group and use the 'view' option to get seperate views for them. That way it easy seperated, also when you want to apply settings. when u use policy management this is also needed.

    it makes the usage of subgroups or child-orgs easier, because you don't have to mention the type of system.

  • Unfortunately, a view isn't enough sometimes (and we have many views)

    We have some clients with desktop PCs, or VMs which run business critical software.  These systems cannot be migrated to a server due to various constraints (Specific hardware, software requirements, configuration is very specific, new hardware isn't available, cost prohibitive for the software/client, etc...).  Additionally, when using Service Desk, we have policies which associate machine groups with certain business policies.

    Views are great, and we have some fantastic ones, can get the job done, but for restricting access to specific users within our Kaseya instance, it's not an option.

  • Unless you plan to lock down your VSA access for your technicians by machine type creating server and workstation sub machine groups is a waste of time as your view filters are meant to be used to filter machine types.

    Personally I prefer a more simplistic machine group structure and I only create machine groups for different sites/geographic location, different networks, unmanaged end points and agent templates. The reason for this is once you get 10 or more customers creating superfilous machine groups like server and workstation starts taking up valuable screen real estate making it harder to find the machine group you want from the drop down list.





    The unamanged machine group is sort of like the recycle bin in Windows and is handy if you are using a 3rd party system like Connect Wise that can sync specified machine groups and for storing test machines or decommissioned machines that is no longer part of a SLA and don't want to show up under your PSA.  

    The templates machine group might become obsolete because of the Kaseya Policy Management module however agent templates still serve some value when you use them with Agent Deployment Packages.  

    View filters is a key part of Kaseya VSA however not many people knows how powerful they are and often neglect to use them to their full potential.