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:
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?
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.
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
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.
Note we are not an MSP, so our practices are for our own IT Management.
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)
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:
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:
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 :
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.
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?]
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...