DarrenWhite99

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.

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'.

This script is intended to be used as a function script, but is flexible and can be ran manually. The script generates a random InstallerToken value for the location and installer type requested, valid for a variable length of time. These can be used to create installer download links valid for more than 24 hours that can be given to clients, or used in deployment scripts. They can also be issued for shorter periods specifically for on-demand agent installation (such as reinstalling an Automate agent through Control). The expected use case is for scripted creation of batch (or powershell) agent deployment scripts that download the agent installer at run time. Another script can call this one to generate a token, and then write that token into the deployment script. This is an improvement over deployment solutions that require the server password to be stored as the installertoken can expire or be selectively revoked at any time with very little impact, but a server password reset impacts all installers for all clients.

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

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.

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.

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.