How to define distinct sub-classifications

A forum for general discussion of any MSP topic.

10/19/2018 12:27:02 PM
Gravatar
Total Posts 2

How to distinct sub-classifications

We have scenarios where we'd like to distinct between sub-classifications under a parent site.  For example,  under ClientXYZ's houston location, we'd like to distinct classifications such as "Lab" or "Testing" or "PC/Mac"

Is there a clean and/or best practice way to handle this under the MSPbuilder model?

 

Thanks in advance!

Michael

10/19/2018 1:22:41 PM
Gravatar
Total Posts 8

Re: How to define distinct sub-classifications

Michael,

We pretty strongly recommend a machine group format of "org.class.type.site". "Class" is always "unm" for unmanaged (break/fix) customers, and this prevents most automation from applying. Pretty much any other code can be used to distinguish the type of organization, but we use a simple "m" to represent "managed". You can create both "m" and "unm" roots for customers with both types of assets. We've also used this to separate different parts of a single entity, which are all in a single location. A municipal or city government is a good example of this. Instead of "m", we us "co" for "City Offices", "pd" for "Police Department" and "fd" for "Fire Department".

"Type" is one of "servers", "wkstns", or "special". We create the server and workstation groups so we can apply logic based on the role of the system instead of the operating system. This lets us treat a Windows 7 system as a Fax "server" and get additional monitoring and attention that a typical workstation wouldn't. The "special" group is only used in managed groups, and moving an agent there disables all of the automation. It's a good place to move an agent to suspend automated actions, such as when you're doing platform upgrades. We've also moved the accountant's workstations there during tax season!

The "site" represents the physical location of the assets - we use the UN LOCODE standard for this to simplify deciding on the name.

With this structure followed, we can apply custom actions based on the class, type, or even the site because they are consistently defined. Working from least to most specific, we know there are always four (or more) fields, but the first four are always the same. Which leads (finally) to your answer:

We'd suggest that you add a final category group after the site group. PC, Mac, Lab, Test - whatever makes sense. My only caution would be to think about what you need and create things with consistent names, and don't create groups more deeply than this.

Glenn