Advanced Groups
From LabTech
Overview | Creation | Auto Group Population | Templates | Managed Services | Advanced Groups
Contents |
Introduction
The default MSP settings within LabTech are designed to provide a simple 'out of the box' deployment solution. The default group layout is designed to give advanced MSPs a baseline and a jumpstart to those just starting out. You will notice many Monitors with disabled Alerts because they tend to flood new systems and/or are not needed when first implementing the MSP. Please review Appendix A below to learn about the logic used to implement monitoring and alerting in the default MSP setup. The default configurations included in the MSP setup are:
- Group structure under RMM All Clients
- Internal monitor timing and settings adjusted to reduce out of the box alarm rate
- Internal monitors applied to that group and sub groups in a way that implements SLA and Monitoring rules
- Alerts and autofix actions on internal monitors that line up with service level
- Basic set of scheduled scripts on Service Plan clients
- Agent monitor configuration for all service plan groups for critical items
- Service monitor for standard services on 2003 SBS Server, 2003 Standard Server R2, and 2003 Standard Server
Requirements
If you have an existing system, and would like to revert to the default MSP structute that is provided in the current LabTech Release, please follow the requirement instructions.
- Important!
- First you must backup/export all custom scripts/searches and Monitors.
- This process will removed and replace most items.
- Removing Existing Scripts, Searches and Monitors
- From the Control Center, on the LabTech Server, logged in as Admin.
- Click Tools on the Main Menu and select MYSQL Prompt.
- Type the following...
- Delete From Scripts;
- Delete From Scriptsteps;
- Delete From Agents;
- To remove all Searches, also type this command
- Delete From SensorChecks;
- Close the Mysql Prompt.
- Importing the Default Settings
- Opening the Control Center on the LabTech Server as the Admin account.
- Click on Tools.
- Select Import then SQL Script.
- Browse to the Program Files\Labtech\Setup\ Folder.
- Select DBaseAdvGroups.sql.
- Click OK to execute Lines.
- Repeat the process for the following files.
- DBaseScripts.sql
- DBaseSeaches.sql
- DBaseMonitors.sql
- Finally, Restart the Control Center.
Service Plan Groups and Configurations
|
If you double click on a group, up comes a screen that displays multiple tabs. The behavior of LabTech for all of the computers in the group are controlled using these tabs. The subsections of this heading describe the default settings in each of these groups for the purposes of marketing and understanding the automation included. |
RMM All Clients
RMM All Clients is designed to hold any actions that you want to be performed regardless of client service level. In the default setup, the only things that are assigned to run are the Interal Monitors listed on the Internal Monitor tab of the Monitors screen. This is implemented by assigning most of these monitors to the RMM All Clients group. By assigning them to this group, these monitors will not be accessible in other groups not below the RMM All Clients Group.
- The purpose of enabling all of the Internal Monitors in this group is to allow for auditing of all client systems for the purposes of driving hourly labor and appointments. Notice that the Internal Monitor tab has no Script or Alert actions and the Remote Monitor tab does not have any monitors listed:
- The easiest screen for executing this audit process is the Overview tab of the Dashboard Screen. Be aware that the counts in the overview are derived from the last time the Internal Monitor has ran.
- When you click on a number in the dashboard, the current status of the monitor for that client will be displayed below. As an alternative to the dashboard, the Monitors screen can be used to audit. To do this, sort so that detected monitors show on the top. Double click the monitor, then hit the Build and View Query Results button. This will show all systems under RMM Clients that show the error conditions.
Service Plans Group
The service plans group is design to hold a group for each of your service levels. The tabs of the Service Plan group should be set to include the services offered to your LOWEST plan. In our default setup, this is the Bronze group. Since settings are inherited down the groups, anything setup here will be applied to Bronze, Silver, Gold and Platinum Groups.
LabTech automation included in the Service Plans group are:
- Basic Notifications of Internal Monitors
|
- Basic Remote Monitors with Alert Actions
|
- Windows HotFixes
- Windows HotFix configurations are not included in the default install.
- To enable windows hotfixes please refer to Hotfixes
Service Plans → Bronze
The Bronze group simply inherits all the settings from the service plans group. It does this is a very similar fashion that the Unsubscribed Clients group inherits everything from RMM All Clients Group.
|
To enable your basic Bronze service on computers or clients, Right Click on the Group and select Add Clients or drag and drop a Client into the group: |
Once this is done, a plus symbol will be displayed next to the group and the client group will be created under Bronze. All computers in that group will automically inherit all settings from RMM All Clients, Service Plans, and Bronze. You can tell what is inherited because it has the word inherited before the scripts, internal monitors or remote monitors.
Service Plans → Silver
The Silver group adds a number of services that require a little more maintenance time on the part of the MSP. In order to offer blacklisted application and process monitoring, maintenance of blacklisted processes and applications is required. In order to managed the advanced service monitors on the server, the servers need to be standardized with the proper services Disabled if not needed on the server. Simply stated, Silver is a more advanced monitoring and maintenance package and should be sold at a higher rate because the MSP has to do more.
As stated earlier on inheritance, all items setup in the RMM All Clients and Service Plans are automatically inherited by the Silver Group.
The items included in the Silver Group do not create an overwhelming amount of alerts. MSPs can obviously add monitors and alerts to this list and it is highly recommended. LabTech recommend that testing procedures mentioned in Appendix A be performed before modifying the groups. Here is a list of items that are included in Silver that are not included in Bronze (actually implemented with the settings in Service Plans Group to prevent duplication):
- Scripts
- The only script added is the Disk Cleanup Script
- Internal Monitors
- This list was chosen as a good starting point because they typically do not create an overwhelming amount of alarms and tickets.
- Blacklisted Process and Application Alerting
- Server reboot cycle monitor alerting
- Drive failures or predictive monitors create tickets instead of alerts because it should be urgent enough to perform without client approval
- Unexpected Shutdown Alerting
- Server Scheduled Reboot Maintenance Alert
- Windows Startup Overloaded Monitor Alert. By default it is set to alert if 15 or more items are in the startup list.
- Remote Monitors
- The Server Service Monitors are included in the Silver Group. They simply create alarms when they fail. The Service Monitors are a list of services that are running on 85% or more of servers for that server operating system. To view the list, edit the associated VBS script in L:\Transfer\Monitors. LabTech only included server operating system that represented a large enough portion of our sampling of server service data. If a server is alarming on this monitor, the problem should be fixed or if the service is not supposed to be running should be disabled.
- Note
- If you find that you would not like a service included in the monitor even if it is not disabled, you must edit the vbs file.
Service Plans → Gold
Gold adds two main items to Silver. Notice that is not a subgroup to Silver. You could make these plan levels subgroups to completely prevent duplication of entry, but making them separate allows you to do different Remote Monitor settings because they do not inherit as nicely as the Internal Monitor settings. The main items that are added to the Gold Plan are in the Internal Monitor tab and are as follows:
- Blacklisted event notifications
- Autostart Services not starting – If you have services that you do not want to monitor on this, add them to the exception list in the main Internal Monitor
- Service Level Agreement Ticket Escalation Emails and alerts for new tickets 6 hours old that have not been updated.
- Ticket escalation to secondary contact if more than one day old
- Note
- It is recommended that the audit procedures for Non-Urgent, but important, items, such as antivirus status, be audited on a weekly basis for gold clients.
Service Plans → Platinum
The Platinum group is designed to be your managed service clients. All the previous monitors that have created alerts are changed to create tickets instead, because the resolution of those tickets and the time that it takes to complete them does not require the client approval. Additionally, automatic fix scripts are run for various conditions. Internal monitors are very similar to Gold except they create tickets and some call scripts:
- 1 hour ticket notification
- 6 hour ticket notification – if used, this is designed to make an additional contact or manager be alerted upon 6 hours of aging. More complex rules can be enabled
- 1 day ticket notification
- Autoservices stop call the Restart service script and that script alerts if it fails to start the service
- Drive – Disk Cleanup checks the temp directory and calls a cleanup script if it is too large
- Drive – Free space checks for too little space and runs a cleanup script
- Drive – Fragmentation automatically defragments if it is too fragmented
The Shutdown – WKS 2 Weeks Since looks at workstations that have been running more than a week. It is recommended to enable the Autofix\Prompt for Shutdown script as an action. This is not enabled by default because it can confuse the end user without proper notification. LabTech created some notification scripts under messaging that may help with that process.
Appendix A
Monitoring Logic Overview
- Why do we need to monitor?
- The need to monitor our customer’s networks is based on the premise that knowledge is power. By using technology to monitor your customer’s servers, networks, and workstations, you gain the ability to initiate corrective actions very quickly, as well as the ability for forecast and prevent problems for your customers.
- What is the best approach?
- The technology of monitoring is easy. There are several thousand tools on the market already. Just like in the building trades, there are hundreds of hammers out there – purchasing the best one does not teach you how to build a house. If you forge ahead with setting up your monitoring solution with an unstructured plan, you will fail - it is easy to overwhelm yourself with so much information that it is impossible to react, much less read through.
- The recommended approach is to start simple, start small, and prove your process.
- Start simple – only pick a few BASIC items to monitor
- Prove the technology works by testing your monitors
- Setup alarms based on your monitors
- Prove the alarms work by testing
- Develop your process to respond to the alarms
- Prove you can respond. If you cannot respond to these simple alarms – what will happen when you monitor everything you want?
- The recommended approach is to start simple, start small, and prove your process.
- What to monitor?
- This is the tricky part. As engineers, we want to know it all. Event log error’s heck ya, I want know. What about warnings? What about Event log warnings not only on your servers, but on all of your workstations? Technically, they are probably something you should know about and fix. However, if you start here you will generate thousands and thousands of alarms. Speaking from experience this is a little overwhelming.
- Types of Monitors
- System monitors – Monitors that run locally on a system that check local items. Requires a service agent to be installed.
- Database monitors – Monitors that read the monitoring system database that search the database for specific information and report on those.
- Remote port monitor – A monitor that is typically run on a remote machine, and checking another machine via a TCP or UDP port. Note: technically, a remote monitor can monitor a local port using the loop back ip of 127.0.0.1. Operationally it is still treated as a ‘remote’ monitor as it can tell you a lot if it doesn’t respond locally either.












