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.