Internal Monitors
10 files
-
RMM - Conflicting Programs or Services
Having other RMM products installed on your managed endpoints can cause poor performance or system instability. They also represent a potential risk as an external party has remote access/control over the system and may bypass other security safeguards. Foreign RMM products should be fully removed to ensure they are not active.
This is often uncovered while onboarding a new client. If this alert is raised for an established client it may indicate another MSP is taking over or is preparing to take over. If remote access tools must be used by other vendors, see if you can provide the necessary functionality using your (managed) tools instead.
Once you import the monitor you will need to make some adjustments to the first line in the "Additional Condition" section.
SET @PreferredRMMList='Automate,Control'; Set this to a list of RMM tools that you deploy and that are expected to work together. The names will need to match the RMM names assigned in the monitor. Hit "Build and View Query" to see sample results and identify additional preferred product names.
SET @ReportPreferredRMM=False; Setting this to True will include preferred products in the alert message of the "Conflicting" applications. Since the alert is basically saying "These are what you should remove" you may not want preferred products mentioned.
SET @RequirePreferredRMMInstalled=False; Setting this to True will only alert on an endpoint where a preferred RMM product was found in addition to a non-preferred product. Setting to False will alert even when only multiple non-preferred products are found. (This is probably useless since you wouldn't have any inventory if Automate was not installed, but the logic was already there from a similar monitor)
The monitor will import as a global monitor that targets all agents. You may want to select some groups to target instead, such as groups for computers under a service plan. This way you won't alert on agents that are not expected to only have your RMM products installed. If you are using the standard Control/ScreenConnect integration, the monitor will already identify your unique ID and will alert when other instances are found.
If you need to add a new product, copy the format of existing products matched by software or service name.
Tweaks
Secondary ScreenConnect/Control instances
I included a couple of placeholder Control instances. If you have a second ScreenConnect instance you can identify it as something other than "UnknownControl". You will need to specify the instance ID in 4 places.
The software table - Known Control Software Definition:
Update `SELECT 'Company1Control', appid FROM software WHERE ((`Name` LIKE 'ScreenConnect Client%' OR `Name` LIKE 'connectwisecontrol-%') AND INSTR(`Name`,'1234567890123456')>0) UNION` to be named what you want and with your servers ID. The software table - Unknown Control Software Definition Exclusion:
Update the `SELECT 'UnknownControl'` row with a clause like ` AND INSTR(`Name`,'1234567890123456')=0 ` with your servers ID. The services table - Known Control Service Definition:
Update `SELECT 'Company1Control', NULL, ServiceId FROM services WHERE ((`Name` LIKE 'ScreenConnect Client%' OR `Name` LIKE 'connectwisecontrol-%') AND INSTR(`Name`,'1234567890123456')>0) UNION` to be named what you want and with your servers ID. The services table - Unknown Control Software Definition Exclusion:
Update the `SELECT 'UnknownControl'` row with a clause like ` AND INSTR(`Name`,'1234567890123456')=0 ` with your servers ID. Alternate Remote Access Tools
The presence of alternate RMM products is a reality. Some clients will have their own remote tools and so there is a way to define allowed clients on a tool by tool basis. This works by setting the @AlternateRMMList and @AlternateRMMClients variables.
SET @AlternateRMMList='Automox,Dameware,GoToAssist'; This value is a comma delimited list of RMM tools that you want to specify an override. The order is important because the @AlternateRMMClients values MUST be in the same order.
SET @AlternateRMMClients='Automox,1,2,3:DameWare:GoTo,1,2'; This value is a colon delimited list of comma delimited client IDs, and should have the same number of items as the first variable. Since the ClientID is being checked against the list for the tool in the same position as the @AlternateRMMList value, you can freely throw the tool name in as the first element of the client list for each tool. This helps keep the value organized and updateable as otherwise the list would be like SET @AlternateRMMClients='1,2,3::1,2';, etc.
Explaining the example above:
I have three products I want to define as alternate RMM tools for clients: Automox, Dameware, and GoToAssist. Automox is first, so I am matching the first group of items: "Automox,1,2,3", which would match clientid 1, 2, or 3. Dameware is second, so I am matching the second group of items: "DameWare". This won't match any clientids because none were specified GoToAssist is third in the list, so I am matching the third group of items, "GoTo,1,2", which would match clientid 1 or 2. This example also demonstrates how the tool name in the RMMClients value doesn't matter, it is just included to help identify where you would list the clientids for a given tool. Help Out
Help identify unknown RMM products by sharing the Product name and Software and Service names that indicate the product is installed. I can update the file periodically with new product definitions.
28 downloads
(0 reviews)0 comments
Submitted
-
AV - Conflicting Programs or Services
A challenge when managing endpoints is identifying which computers still have legacy AV products present once you have your preferred AV installed. This monitor will match program and service inventories to known AV products and alert when multiple solutions are found. Once you import the monitor you will need to make some adjustments to the first line in the "Additional Condition" section.
SET @PreferredAVList='ProductName1,ProductName2'; Set this to a list of AV products that you deploy and that are expected to work together. The names will need to match the AV names assigned in the monitor. Hit "Build and View Query" to see sample results and identify your preferred AV product names. If you don't set this the monitor will just alert for every agent that has multiple products installed.
SET @ReportPreferredAV=False; Setting this to True will include preferred products in the alert message of the "Conflicting" applications. Since the alert is basically saying "These are what you should remove" you may not want preferred products mentioned.
SET @RequirePreferredAVInstalled=False; Setting this to True will only alert on an endpoint where a preferred AV product was found in addition to a non-preferred product. Setting to False will alert even when only multiple non-preferred products are found.
The monitor will import as a global monitor that targets all agents. You will want to select some groups to target instead, such as groups for computers under a service plan or groups for computers that should have a managed AV product deployed. This way you won't alert on agents that are not expected to have your preferred AV product installed.
If you need to add a new product, copy the format of existing products matched by program or service name.
Tweaks
If you want to alert when only 1 product is found but it is not a preferred product:
Change
HAVING COUNT(DISTINCT IF(FIND_IN_SET(innerdt.AVName,@PreferredAVList),'Preferred',innerdt.AVName))>1 To
HAVING COUNT(DISTINCT IF(FIND_IN_SET(innerdt.AVName,@PreferredAVList),NULL,innerdt.AVName))>=1 Help Out
Help identify unknown AV products by sharing the Product name and Software and Service names that indicate the product is installed. I can update the file periodically with new product definitions.
For Instance:
ESET - Application Names are like 'ESET Endpoint%' or 'ESET File%' or 'NOD32%'. Services have the Name 'ekrn' or 'ekrnEpfw'.
18 downloads
-
Automate Agent Licenses Available
This monitor will compare the number of available licenses to the value in Result. This value will be customized based on the number of agents you are currently licensed for, but you can change the value to be warned earlier or later. The Identity field reports the available agent licenses in increments of 10. This means that the monitor identity will be "50" when between 41 and 50 licenses remain, and "40" when between 31 and 40 remain. In this way a unique alert will be triggered each time the available count is reduced by 10 (or more). If you do not want new alerts as the remaining count continues dropping below the threshold, set the identity field to "computers.computerid" (no quotes).
The Duplicate Alert Frequency is set to Once per 7 days. So after 1 week another alert would generate even if the available count did not change. Set to "Send Fail After Success" if you do not want any repeat notifications for the same "incident".
The Alert Template should default to the stock "Create Ticket" alert. I would suggest this be changed to an alert template that generates an email so that the notice can be sent directly to the person who manages agent licenses.
NOTE: The monitor is designed to alert against the Automate Server (where the "LTAgent" service is Running). If you don't have an agent on your Automate Server, the monitor falls back to Computer ID 1. If you don't have THAT agent the monitor won't work. To change the fallback computer ID, edit the Additional Condition and update "IFNULL(MAX(computerid),1)", replacing "1" with whatever computer you want to generate the alert against.
Install Instructions: Unzip the attached file, and import into Control Center using "Tools -> Import -> SQL File". The Internal Monitor name will be "CWAutomate Agent Licenses Available".
371 downloads
-
Manage RoleDetections that are no longer Detected
Once a role has been detected for an agent, it will remain in the list of roles for that system even if the detection rule no longer applies. There are no timestamps recorded for role changes so it is impossible to know if the non-detection state is short term or permanent. This Internal Monitor named "Expire RoleDections Not Detected For 7 Days*" will identify inactive roles on an agent, which creates a separate active alert for each role on the agent with a timestamp for when the role was first found missing. The RAWSQL monitor is three queries in one. The first one checks for any role that was reported missing more than 7 days ago, and deletes the role from the agent (based on the alert timestamp). The second query deletes role alerts from the history if the role is found to be active, or no longer exists on that agent. The last query is what actually detects missing roles to generate alerts. With the expired roles and alerts removed from the agent by the first queries, the active alert in the monitor will clear (heal) for that role also.
The role must be continuously non-detected.. If it is ever found to be a detected role before 7 days has passed, the alert will clear (query #2) and the monitor will start the clock again the if the role becomes missing again. Manually assigned "Apply" and "Ignore" Roles are preserved, only automatically detected roles are candidates for cleanup.
If you want your roles to clear quicker, change the date adjustment in the first query from "-7 DAY" to whatever interval you believe is appropriate.
This monitor has been updated/improved since it was first released. The attached SQL should safely update any existing version of this monitor and it is recommended that you update even if you have this monitor in place and working as this specific configuration may not have ever been published before.
185 downloads
-
Domain Computers without Automate Agent
This RAWSQL monitor uses data from the Active Directory Plugin to check for active AD Computer Accounts with a Windows OS that have recent logon times, and that do not have an Automate Agent installed. This is helpful to identify computers that were joined to the domain without the proper procedure, or computers that your agent deployment has not succeeded in reaching. The alert will be targeted against a probe computer for each client, you will need to read the alert body (or subject) to find out the name of the computer without an agent. Because the alerting is "Probe" centric, be aware of the following:
If you enable group targeting, and your targeting excludes the probe computer for a client, no machines will be reported for that client.
If you have no probe at any location for a client, no machines will be reported for that client.
The alerts now are applied against the DC used for the AD information gathering, so it no longer generates alerts using probe agents.
If you Exclude or Ignore the "computer", you are really excluding the Probe AD Controller Computer, and if you do this no machines will be reported for that client.
There is no simple way to Whitelist machines that do not have an agent installed on purpose. You will just have to live with them being reported. To prevent a computer from triggering an alert if it should not have an agent, just update the computer description in Active Directory to have the word "Exclude". Examples: "Exclude From MSP Management" , "Excluded from Automate Agent deployment", etc.
To Import: In Control Center, open Tools -> Import -> SQL File. (System->General->Import->SQL File in Automate 12) Select the file, and you should be asked to import 2 statements. (Cancel if it tells you a different number). The Monitor will be named "Domain Computer Without Automate Agent", and it should run every 6 hours. If you already have this monitor, you can safely import and it will apply the updates to your existing monitor.
Keywords: active directory domain joined computer object account missing labtech automate agent machine monitor
552 downloads
-
CWA Agent Version Update Monitor
This monitor identifies the current agent version for OSX, Linux and Windows Agents. Every 5 minutes the monitor checks for agents that are below the current version and issues the Agent Update command to a small batch of online agents. It will only issue the command once per day for any particular agent, and only if there are no pending/executing commands already in the queue for the agent. It will dynamically calculate the concurrency limit so that it can process all of your agents in about 12 hours time. This spreads the load out while quickly bringing all agents up to date as soon as possible. Commands from before the agent was restarted are ignored, so it can update right away after a reboot even if it already failed to update within the past 24 hours.
The monitor will only report verified update failures, so you can use this monitor to generate a ticket or to run your own update remediation script since you know the self-update has failed. Even though only a small number will be asked to update each time it runs, the monitor will report ALL online, out of date agents. You do not need to run a script or generate a ticket or do anything else, the monitor is issuing the update commands directly in SQL. If you don't generate a ticket, you should check the monitor periodically and see which agents are reported since they are failing to update and will need some sort of manual intervention.
This file has been specially prepared to be safe for importing in Control Center through Tools -> Import SQL. The monitor will be named "CWA AGENT - Needs Update". If you have imported a previous version of this monitor, most of your customization's (Monitor Name, Alert Template, Ticket/Report Category, etc.) will be preserved but the necessary changes will be made automatically. Unlike prior versions of this monitor, you can safely "Build and View" and it will not continue to add more update commands.. Pending/In Process update commands will reduce the concurrency limit so that it never overloads the system with too many update commands at once.
FAQ:
My agent is outdated but the monitor doesn't show it. Why?
These are the criteria for an update command to be issued. Until the monitor tries to update an agent, it will never report it as failing to update. If any of these conditions are not met, this is why you aren't seeing the agent update command:
Is the agent version out of date? Is the agent online? (lastcontact within past 15 minutes) Are there no commands currently pending or executing? Have no update commands been issued within the past day for the current version? Have fewer than LIMIT (a custom value dynamically adjusted for your environment) update commands already been issued and have not completed? After answering YES to all of these checks, the monitor will issue the command to update the agent. It will only permit up to LIMIT update commands to be pending/executing at once, so if you have a large number of agents to update it might be awhile (up to 12 hours) before any particular agent is asked to update. Once an agent has been asked to update, the following criteria determines if the agent will be reported as failed:
Has an update command been issued within the past day? Is the agent online? (lastcontact within past 15 minutes) Did the update command report failure? OR has the update command been executing/completed for over 2 hours? Is the agent version still out of date? After answering YES to all of these checks the monitor will report that the agent has failed to update.
Why won't my agent update?
This can be caused by many reasons.
Some common ones:
Insufficient Agent resources (low ram/disk space/available cpu) Another software install is in progress. The agent is pending a reboot. A file cannot properly extract from the update. (Check for ReadOnly attributes or invalid file/folder permissions for "%WINDIR%\Temp\_LTUpdate") A file is locked and cannot be replaced. (LTSvc.exe, LTTray.exe, etc. might fail to stop. A .DLL might be open or locked by AV or a third party program.) Nearly all of these are resolved with a reboot, so that is a good troubleshooting step after checking the file attributes/permissions.
What alternative methods are available to update my agent?
Look for this section to be expanded on in the future.
LTPoSh has an Update-LTService function. Calling this function through Control is a highly effective way to resolve update failures for Windows agents. LTPoSh (or other solutions) can be used to reinstall the agent using Control, PSExec, or any other method as your disposal. (I have used ESET Remote Administrator to execute an install command for example).
update outdated out of date updated current agent version automatic automated internal monitor rawsql
724 downloads
-
Schedule Script to Run After Restart
This Internal Monitor allows you to schedule a script after the next restart of an agent. There is no official way to indicate this, so it works by looking for scripts with a distinct schedule. When you want a script to execute after a restart, simply schedule it to run 2 years from now. This monitor will report any scripts that are found waiting, and when the agent has restarted (and is online), any waiting scripts will be rescheduled to start immediately. No helper scripts or alert templates are needed with this solution. Because of the way the monitor works, even if the agent is in maintenance mode the script will still be scheduled right away after a restart. (If your script is not a "maintenance mode" type script it will still wait to start)
Thanks to @CTaylor for his original implementation at http://labtechconsulting.com/schedule-labtech-script-to-run-after-reboot/ which used a monitor+script solution.
97 downloads
(0 reviews)0 comments
Submitted
-
Sticky Tickets - Keeps tickets active until they are corrected
This is the "Internal Monitor For Automatic Resets on Ticket Status" (IMFARTS)
The tickets themselves aren't sticky, this is a solution for designating specific monitors so that if the ticket is closed without the monitor healing, the alert will be reset and a new ticket will be created. This is specifically for the scenario that exists for Internal Monitors that are configured to "Send Fail After Success". These monitors are useful because they do not continuously generate tickets or ticket comments. But issues can be lost if the ticket is closed without the monitor actually healing. If a monitor alert must be ignored, the agent should be excluded from the monitor instead of just closing the ticket. I am not saying that this should apply to every monitor (sometimes you may accept just closing the ticket). But if you have a monitor that you want to insure is not ignored, this monitor this can help.
The monitor works by searching for open alerts and tickets that have been generated by the all monitors. Any alerts found where the ticket has been closed but the alert is still active will be returned as a result. You do not want to alert (create a ticket or other action) on the result of this monitor. The results are only there to show you what alerts are currently not being watched because there is an active alert with no active ticket. Based on this, you can decide which monitors you want to enforce.
For monitors that you have chosen to enforce, if they are found to have no active ticket the previous alert will be cleared, allowing the monitor to generate a new alert (and ticket) the next time that monitor is processed. This monitor determines which monitors are being watched by a keyword in the other monitor's definition.
To enforce a monitor (so that it's tickets will be re-opened), you need to include the string "ENABLEIMFARTS" in the Additional Condition field. A simple way to do this is to add " AND 'ENABLEIMFARTS'<>'IGNORED' " to the Additional Condition field. This will always evaluate to TRUE, so it will not change the existing monitor's logic. You could also use computers.name NOT LIKE 'ENABLEIMFARTS', etc.. As long as the string is in the Additional Conditions, the monitor will be watched. It can easily be incorporated for regular or RAWSQL monitors.
An example: A Drive Monitor is reporting that under 2GB of free space exists for the "C" drive on AgentX. A ticket is created, and the monitor is configured for "Send Fail After Success". A technician accidentally closes the ticket. This Monitor detects that there is an active alert for AgentX on the "C" drive, but all tickets from that alert have been closed. If the string 'ENABLEIMFARTS' is found in that monitor, the current alert for AgentX "C" drive will be cleared. When the Drive Monitor processes next and it still finds that AgentX has an issue with "C", because there are now no active alerts this is treated as a new alert and a new ticket will be created.
To use: Import the attached SQL. I have prepared it to be safe for import using SQLYog or Control Center, and if you had added it previously it will safely update your current monitor.
Revision History:
2017-09-09 20:00:00 - Version 1 Posted.
2017-10-18 06:00:00 - Version 2. Adds support for ignored alerts (so it ignores that the ticket may be closed) and greatly improves the matches by catching alert tickets with customized alert subjects.
2018-12-11 03:00:00 - Version 3! Indicates when it resets status in the Alert History for any monitor it is acting on.
78 downloads
-
Alert When Agent Is Online
The Internal Monitor "Notify When Agent is Online" watches machines with the "Notify When Online" computer EDF configured. It will send an alert as soon as it finds that the agent is offline. (The offline notice is skipped if the agent was already offline when notifications were first enabled.) When the agent comes online again another alert email will be sent and the EDF will be reset.
This monitor can be used to notify when a lost computer comes online, or when that machine that is only online in the office every few weeks is back.
To enable notifications for an agent, you simply put your email address into the "Notify When Online" EDF. You can enter multiple addresses separated by ";". The contents of the agent's "Comments" will be included in the email also. (Helpful to remember why you wanted to be alerted, or what instructions should be followed after receiving the alert.)
When the agent returns online, the Network Inventory and System Info are refreshed. The recovery email will include the following details:
The last check in was at @AgentCheckIn@.
Public IP Detected: %RouterAddress%
Internal IP: %LocalAddress%
System Uptime: %uptime%
Last Logged in User: %lastuser%
This bundle includes a Script+EDF XML, and a SQL file with the Internal Monitor.
To import the Script and EDF, select Tools -> Import -> XML Expansion. After import the script should appear in the "\Autofix Actions" folder.
To import the Internal Monitor, select Tools -> Import -> SQL File. The monitor should be imported AFTER the script bundle has already been added.
After importing, verify that a valid Alert Template is selected for the monitor. The Alert Template MUST have the "Run Script" action enabled without any script specified in the template. (The script is set on the monitor)
Read the Script Notes for advanced control over the number of times a notification will be triggered.
1067 downloads
-
Active Directory Plugin Credential Status Monitor
The AD Plugin will not operate properly if credentials are missing or are not valid. This monitor will report any Domain Controller Infrastructure Master that does not have valid credentials associated with it. This is the same information available in the plugin, but you can be automatically notified when there is a problem instead of having to check it manually.
The monitor is configured to only match agents with the "Domain Controller Infrastructure Master" role, so you can leave the targeting to all agents. If you only want to monitor systems that are under a service plan, you may choose to target a group such as: "Service Plans.Windows Servers.Server Roles.Windows Servers Core Services.Domain Controllers".
Thank You to @Jacobsa for the suggestion!
159 downloads