Kaseya Community

Machine Group Best Practices

This question is answered

I'm working on migrating us from a bare bones LabTech setup (monitoring of servers only) to a much more proactive approach in Kaseya. I really want to be applying policies on machine groups to make sure that things are working correctly. I also want the machine groups to be clear about what's happening there for my co-workers.


My Plan thus far:

  • rename the "root" group to "unassigned"
  • build 4 primary groups for each client with subgroups like so:
    • Workstations
      • sub groups for different sites and/or departments
    • Servers
      • sub groups for different sites
    • Home-PCs
      • this will be used for PCs placed in home offices for some clients, most wont even have this group.
    • Probes
      • These are machines owned by us not the client that were classically used for network monitoring. I plan on using these as the LAN Cache machines etc. I may move them into the servers group, but I also don't really care heavily if these machines go offline and don't want to apply the same monitoring rules to them.

This gives me a typical machineid of [computername].[site].[primarygroup].[org] and allows me to easily apply policies to servers or workstations for an entire organization. Keeping the new additions of computers to an "unassigned" group is so that we can make sure policies such as patching don't apply to a machine incorrectly before it is moved to the correct group.

So my question is if this plan is going to cause me to hit problems with any specific module(s) and should be changed in anyway?

Thanks!

-Greg

Verified Answer
  • Hello GMikesell,

    In addition to the good comments from Craig (we also divide our groups by "asset main location")

    here is what we do:

    Depending on location size we create a sub-group to identify departments in each location.

    Example:

    alessandro.dimarco.finance.hq.cosl

    It helps us to quickly understand which application we need to install (or expect to find) as different departments within the company may have different requirements (different share, default printers, different software etc)

    If the location is small, I avoid breaking down departments and keep it "simple"

    Our agent names are generally named with the user the asset is assigned to

    Example:

    alessandro.dimarco.dubai.cosl

    john.smith.singapore.cosl

    todd.toddler.thailand.cosl

    This way, I know who is responsible for the Asset, where he normally works and a quick idea of their timezone.

    For servers we prefix the agent name with an "_"  so they always appear on top of each "group" location.

    Example:

    _server_rigname.cosl

    Note we are not an MSP, so our practices are for our own IT Management.

    Best Regards

  • Hi,

    Over past several years working in many industries from manufactory, adverting agencies, banks and then using Kaseya at my MSP business, working with those same industries and then becoming a Kaseya Professional Services Consultant in Brazil, providing implementation services, consulting and training, I've been faced with a variety of requirements, concerns and needs. From simple data organization for better view up to productivity and security matters.

    Why it is important as a introduction? We have to handle many different requirements, concerns and needs with a simple tool. When we get access to such powerful tool like Kaseya, we think initially to automate things (and yes, this is the main advantage of having it), and increase our productivity and profitability. But we have have to take care of all aspects of ours services and responsabilities. And we don't do it alone, we have collaborator and don't know the tool and may be do something wrong (by intention or not), like this poor guy

    That said, to accomplish it all, a have defined a process myself (of course, using many sources of standards and best practices)

    1. Think atomic (keep it simple)
    2. Execute in small fases and steps (keep it simple)
    3. Create standards and patterns, do not just try to... (for team work will be much better and scales much easer)
    4. Respect the standards
    5. Apply the standards
    6. If the standard doesn't handle something, redefine it instead creating exceptions (otherwise, become a total mess)

    Regarding ours question, I think we have to think mainly in two scopes: Productivity and Security

    Organization Groups are the main resource for access control after scopes and roles, then, if you have concerns about access rights, you have to think about security matter when creating orgs and suborgs or groups.

    What I do is: <company>.<division>.<building>.<group>.<subgroup> (always)

    if a company doesn't have a division it will be something like this:

    • acme.main.hq.srv.ldc (Acme Inc . Main Division, Headquarter, Servers, Local Datacenter)
    • acme.main.hq.wrk.g (Acme Inc . Main Headquarter, Workstations, General)
    • acme.main.hq.wrk.r_law (Acme Inc . Main Headquarter, Workstations, Restrict - Lawyers)

    In this case, was a customer that had lawyers in different areas and the access to their computers should me very restricted.

    if a company does have divisions and spread over the country or world it will be something like this:

    • acme.holding.hq.srv.ldc (Acme Inc . Holding, Headquarter, Servers, Local Datacenter)
    • acme.software.hq.wrk.g (Acme Inc . Software Division, Headquarter, Workstations, General)
    • acme.hardware.bra_sao.wrk.r_law (Acme Inc . Hardware, São Paulo Brazil, Workstations, Restrict - Lawyers)

    With these organizations I'm able to control almost every aspect of access control for local and remote technician, managers, etc.

    A more specific access control can be done by using inventory data, mainly custom fields and view with lots of work and some limitation.

    All other things related to productivity and automation, use inventory data, custom fields, views, agent procedures and tie all together with policies.

    To make it work, you have to have a very good organization skills, logic and programming. Most of the things can be accomplished using the concept of "tags/labels" in custom fields, some of then you can create scripts to collect from inventory data or data that are in the machines/environment some other you might create/put there.

    I have created custom fields for Identify/Control :

    • When, what and how to automate
      • Basic_Defaulf_Config - every single machine must have exactly the same (, Level, Scope)
      • Basic_Credential - define and check periodically credentials for the agent
      • Automation_Management (Enabled/Disabled)
      • AM_BasicTools (with a list of basic management tools need to manage the machine and the status of it health)
      • AM_Apps_Required (with a list of applications that must be installed)
      • AM_Apps_Prohibited (with a list of applications that is not allowed)
      • AM_Settings
      • AM_Monitoring
      • AM_Security
      • AM_Backup

    • Status of machine - tags like New, Upgraded, Old, Slow, Fast
    • Stage of automation - tags like LabTest_Workstation, LabTest_Server, LabTest_Server_SQLServer, Production_Server

    With all those data, I've create agent procedures and some external resource from simple txt files to database queries and code with lua script, vbs, powershell, etc to handle the automation and views and policies to everything happens without anyone have to click on "run" button.

    Unfortunately, it is not so easy to visualize, much less put into practice.

    Hope that it helped.

    Bests,

    Tutume 

     

All Replies
  • The mobile management module is designed so that it's one ORG per customer. This is incompatible with our system, which has one ORG system-wide, and we have each client under their own machine group.

    I see no value in going nuts with multiple machine groups - we use views to filter down the required machines. Th only exception to this is multi-site clients, there is value in machine one machine group per site, as you can't easily filter by the machine's physical location [although I suppose you could make a custom filter based on IP address or a custom field?]

  • Hello GMikesell,

    In addition to the good comments from Craig (we also divide our groups by "asset main location")

    here is what we do:

    Depending on location size we create a sub-group to identify departments in each location.

    Example:

    alessandro.dimarco.finance.hq.cosl

    It helps us to quickly understand which application we need to install (or expect to find) as different departments within the company may have different requirements (different share, default printers, different software etc)

    If the location is small, I avoid breaking down departments and keep it "simple"

    Our agent names are generally named with the user the asset is assigned to

    Example:

    alessandro.dimarco.dubai.cosl

    john.smith.singapore.cosl

    todd.toddler.thailand.cosl

    This way, I know who is responsible for the Asset, where he normally works and a quick idea of their timezone.

    For servers we prefix the agent name with an "_"  so they always appear on top of each "group" location.

    Example:

    _server_rigname.cosl

    Note we are not an MSP, so our practices are for our own IT Management.

    Best Regards

  • We break out as many subgroups as needed per site. We use alot of policies and this is the most efficient way to maximize their use. We have several types of machines, all with different needs/policies, so this method works well for us.

    Examples: root.org.site.servers.application, root.org.site.servers.dc, root.org.site.wks.public...

  • Hi,

    Over past several years working in many industries from manufactory, adverting agencies, banks and then using Kaseya at my MSP business, working with those same industries and then becoming a Kaseya Professional Services Consultant in Brazil, providing implementation services, consulting and training, I've been faced with a variety of requirements, concerns and needs. From simple data organization for better view up to productivity and security matters.

    Why it is important as a introduction? We have to handle many different requirements, concerns and needs with a simple tool. When we get access to such powerful tool like Kaseya, we think initially to automate things (and yes, this is the main advantage of having it), and increase our productivity and profitability. But we have have to take care of all aspects of ours services and responsabilities. And we don't do it alone, we have collaborator and don't know the tool and may be do something wrong (by intention or not), like this poor guy

    That said, to accomplish it all, a have defined a process myself (of course, using many sources of standards and best practices)

    1. Think atomic (keep it simple)
    2. Execute in small fases and steps (keep it simple)
    3. Create standards and patterns, do not just try to... (for team work will be much better and scales much easer)
    4. Respect the standards
    5. Apply the standards
    6. If the standard doesn't handle something, redefine it instead creating exceptions (otherwise, become a total mess)

    Regarding ours question, I think we have to think mainly in two scopes: Productivity and Security

    Organization Groups are the main resource for access control after scopes and roles, then, if you have concerns about access rights, you have to think about security matter when creating orgs and suborgs or groups.

    What I do is: <company>.<division>.<building>.<group>.<subgroup> (always)

    if a company doesn't have a division it will be something like this:

    • acme.main.hq.srv.ldc (Acme Inc . Main Division, Headquarter, Servers, Local Datacenter)
    • acme.main.hq.wrk.g (Acme Inc . Main Headquarter, Workstations, General)
    • acme.main.hq.wrk.r_law (Acme Inc . Main Headquarter, Workstations, Restrict - Lawyers)

    In this case, was a customer that had lawyers in different areas and the access to their computers should me very restricted.

    if a company does have divisions and spread over the country or world it will be something like this:

    • acme.holding.hq.srv.ldc (Acme Inc . Holding, Headquarter, Servers, Local Datacenter)
    • acme.software.hq.wrk.g (Acme Inc . Software Division, Headquarter, Workstations, General)
    • acme.hardware.bra_sao.wrk.r_law (Acme Inc . Hardware, São Paulo Brazil, Workstations, Restrict - Lawyers)

    With these organizations I'm able to control almost every aspect of access control for local and remote technician, managers, etc.

    A more specific access control can be done by using inventory data, mainly custom fields and view with lots of work and some limitation.

    All other things related to productivity and automation, use inventory data, custom fields, views, agent procedures and tie all together with policies.

    To make it work, you have to have a very good organization skills, logic and programming. Most of the things can be accomplished using the concept of "tags/labels" in custom fields, some of then you can create scripts to collect from inventory data or data that are in the machines/environment some other you might create/put there.

    I have created custom fields for Identify/Control :

    • When, what and how to automate
      • Basic_Defaulf_Config - every single machine must have exactly the same (, Level, Scope)
      • Basic_Credential - define and check periodically credentials for the agent
      • Automation_Management (Enabled/Disabled)
      • AM_BasicTools (with a list of basic management tools need to manage the machine and the status of it health)
      • AM_Apps_Required (with a list of applications that must be installed)
      • AM_Apps_Prohibited (with a list of applications that is not allowed)
      • AM_Settings
      • AM_Monitoring
      • AM_Security
      • AM_Backup

    • Status of machine - tags like New, Upgraded, Old, Slow, Fast
    • Stage of automation - tags like LabTest_Workstation, LabTest_Server, LabTest_Server_SQLServer, Production_Server

    With all those data, I've create agent procedures and some external resource from simple txt files to database queries and code with lua script, vbs, powershell, etc to handle the automation and views and policies to everything happens without anyone have to click on "run" button.

    Unfortunately, it is not so easy to visualize, much less put into practice.

    Hope that it helped.

    Bests,

    Tutume