DarrenWhite99

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

This monitor is designed to check the health of your DNS Server Forwarders. Copy "DNSForwarderCheck.vbs" to your LTShare\Transfer\Monitors\ folder. Import the SQL file in Control Center -> Tools -> Import -> SQL File. This will create a group monitor on the "Windows DNS Servers" group under "Service Plans\Windows Servers\Server Roles\Windows Servers Core Services". The monitor action will be "Default - Raise Alert". Here are a couple of examples of Servers with underperforming DNS Forwarders. Once you identify issues, use a tool like GRC DNS Benchmark to identify what your best server choices are. https://www.grc.com/dns/benchmark.htm

On Windows Agents, LabTech assumes that all volumes have a drive letter associated with them. Volumes mounted to a path (CSV volumes, etc.) are not reported in the drive listing. This is a solution that uses a Remote EXE Monitor to dynamically detect mounted volumes and alert if the free space is below a configurable value. The batch file is a powershell wrapper that queries for mounted volumes with no drive letter and returns a list of all volumes with less that 10 percent free space. The free space level can be passed as a parameter, so it is easy to monitor for 20%, 5%, etc. All volumes have the same threshold however, there is no support for different thresholds on different volumes. The powershell section could also be extracted and used directly. On systems with no matching volumes, the result "No Mounted Volumes detected." is returned. If there are mounted volumes with no drive letter, the output will either be "All Mounted Volumes have above $FreeThreshold% space free.", or "Mounted Volumes at or below $FreeThreshold% free space:" with a list of all volumes that met the criteria. This was implemented as a remote EXE monitor. SQL is included to import the monitor definition to an agent (configured for agent ID 1). See the MountedVolumesFreeSpaceMonitor-README.txt file in the attachment for more details. After importing, the Ticket and Report Category and Alert Template should be verified or assigned to valid values. The monitor command is 'MountedVolumeDiskCheck.bat 10', where 10 represents the free space alert threshold. You can change threshold this globally if assigned to a group, or override the monitor on a per-agent basis to use a different threshold. After importing and testing this monitor on an agent, the monitor can be added to an appropriate group so that Windows Servers will be monitored automatically. See "Configuring Remote Monitors" in the documentation: https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/070/160/040/020 Keywords: remote monitor free drive drives disk disks volume volumes mounted mount point no letter space percent percentage

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

The attached SQL will modify all dataviews that include the computer's local IP (Agent IP Address) to also include the DNS server information as "Agent DNS Servers". I started out planning to create a specific dataview, but I think it is better to make this column available in any dataview. I suggest copying one or a few of the stock Dataviews, and then running this. While it will update all dataviews, many will be flagged as having changes the next time Solution Center is ran and may be reset to original. The copied Dataviews should preserve the additional column. Save the file and import into Control Center using Tools -> Import -> SQL File. It will ask if you want to "Import 1 Statement into the database". If it says there are many statements choose "No", you have an older (buggy) Control Center and you will need to import using SQLYog or some other tool.

This solution will export customizations into a folder hierarchy based on each type of backup. It uses only Automate scripting functions so it is compatible with both Cloud Hosted and On-Prem servers. It is compatible with MySQL 5.6+ and Automate Version 11+. Script Backups will be placed in folders matching the script folders in your environment. Each time a script is exported, the last updated time and user information is included, providing multiple script revisions as it is changed over time. This script does not decode the scriptdata, so script dependencies like EDF's or other scripts will not be bundled in the XML export. But if you are just looking to undo a change, the script dependencies should exist already. Scriptlets will not be "versioned", but it will detect when they have changed and will only back up new or changed Scriptlets. Additionally, the following item types will also be backed up: Internal Monitors, Group Monitors, Remote Monitors, Dataviews, Role Detections, ExtraData Fields, and VirusScanners. The backups will be created at the folder identified by "@BackupRoot@", which you can provide as a script parameter when scheduling if you do not want to use the default path. Target the script against an online agent, and the script data will be backed up to that computer. Future runs will reference the saved "Script State" variable for that agent and will only include the scripts updated since the last successful backup. Backup verification is performed, if a script backup file was not created as expected, the backup timestamp will not be changed allowing the backup to be attempted again. The attached .zip bundle contains scripts actually backed up by this solution. Import the "Send Email" script first, and then import the "Backup" script. If there are any problems or you would rather import a script exported by Automate, the "Backup Automate Scripts (and More).xml" is included as well. You do not need to import all three files! Just schedule this to run daily against any agent to establish your script archive. script version revision archive backup

I used the stock PowerShell 2.0 update script, and modified it for PowerShell 3, 4, and 5. I attempted to cover pre-requisites checks to prevent installing on systems with incompatible applications or operating systems. The scripts will check if the KB is reported as installed after the update completes to determine status. This means that the script will report the update was successful even if a reboot is still needed. The attached .ZIP has 3 scripts, one for each version, in a single XML bundle. To import the Scripts, select Tools -> Import -> XML Expansion. After import the scripts should appear in the "__Examples" folder. This pairs nicely with the PowerShell Version Roles at https://www.labtechgeek.com/files/file/13-powershell-version-roles/

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.

The function Script "GetFile" is a simple way to always follow best practices for file downloads as well as enabling advanced functionality. A sample script showing how to use it is included, plus two Scriptlets to insert the script steps needed to use this in two clicks. Previously this script was known as GetLTFile. At its minimum, you can use this by defining two variables (the source and destination for the download) and calling the script. The script will test if the file already exists and skip downloading automatically. It will verify the target folder exists before attempting to download, and create it if needed. If a download fails it will try again by default, and will automatically enable verbose logging after two failures from the same script. Compressed file contents are automatically extracted (.ZIP under Windows, OSX, Linux if unzip is installed. .TGZ under OSX, Linux). By defining additional variables you can require that the file meets Minimum or Maximum size limits or verify the MD5 Checksum is valid (all three options supported under Windows, OSX, and Linux). You can require the file to always be re-downloaded, specify the number of retries allowed, and can even support automatic failover by specifying multiple sources. Supported download protocols are ones supported by the "File Download" function (LTShare\Transfer\*) and "File Download URL" function (HTTP, HTTPS for all agents plus UNC paths for Windows Agents). With the optional WINSCP binary, SFTP:// is also a supported protocol (Windows only). To import the Scripts, select Tools -> Import -> XML Expansion. After import the scripts should appear in the root Scripts folder. To import the Scriptlets, select Tools -> Import -> SQL File. The Scriptlets should be imported AFTER the scripts have already been added. For more instructions on Scriptlets see https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/070/240/050/020#Use_Scriptlets

This bundle will add the following Role Definition: PowerShell And the following Sub-Definitions: PowerShell 1 PowerShell 2 PowerShell 3 PowerShell 4 PowerShell 5 PowerShell 6 To import these Role Definitions, in the ConnectWise Automate main screen, go to Tools > Import -> SQL File. Browse to the relevant file, and OK the message about inserting 7 rows.

This bundle will create the following Role: HP Server And the following sub-roles: HP Server - Gen6 HP Server - Gen7 HP Server - Gen8 HP Server - Gen9 HP Server - Gen10 I don't do a lot with HP servers, so these roles are not heavily tested. If you see anything detected incorrectly, please let me know so that I can update the role detection definition. To import these Role Definitions, in the ConnectWise Automate main screen, go to Tools > Import -> SQL File. Browse to the relevant file, and OK the message about inserting 6 rows.

This bundle will create the following Role: Dell Server And the following sub-roles: Dell Server - 3G Dell Server - 4G Dell Server - 5G Dell Server - 6G Dell Server - 7G Dell Server - 8G Dell Server - 9G Dell Server - 10G Dell Server - 11G Dell Server - 12G Dell Server - 13G Dell Server - 14G Let me know if you find anything incorrectly detected, there are some odd ones prior to Gen10/11, and Gen14 is brand new so I have nothing in production to test against yet. To import these Role Definitions, in the ConnectWise Automate main screen, go to Tools > Import -> SQL File. Browse to the relevant file, and OK the message about inserting 13 rows.

This function script should be called right before and after the "Execute Script" function. It will catch the temporary script as it is written to the agent, preserve a copy, and check for Non-ASCII characters that can break script execution. When called a second time, it will retrieve the information gathered. The saved file and analysis log file are also left on the agent for additional investigation if needed.

This script will force the CWAutomate Agent to re-register with the server, hopefully with a new ID. It does this by clearing the current MAC and ID values on the agent, which should cause the agent to be detected as new. This can be used when multiple agents are sharing the same ID. This script supports Windows, OSX, and Linux. In the future, I plan to make a universal reset that issues the reset for all three OS types simultaneously, since the Agent OS detection is not reliable when two agents with different OSes are sharing the same ID. (Probably very rare) The reset commands used can also be pulled out and sent manually through a remote shell, or through the CWControl agent.

This bundle contains the three following scripts: FUNCTION - Check For Pending Reboot Checks to determine if a Reboot is needed. Sets "@RebootPending@=1" if a restart is required. "@RebootReason@" will contain the reasons a reboot was required, if any were found. If @RebootReason@ includes "!", the reboot is required. Process PendingFileRenameOperations This script will attempt to process pending file operations that would otherwise require a restart to complete. This may allow a reboot to be avoided. Perform Computer Restart* This script will execute a restart and sleep until the computer has restarted successfully. The script will wait 30 minutes before exiting with an error. Variable "@RebootPending@" used to return Reboot Status. @RebootPending@ = 0 if reboot successful @RebootPending@ = 255 if reboot failed

This bundle contains separate SQL imports to add the following Scriptlets: Check If Agent Is Online - Just checks if the agent has a recent contact timestamp, and branches based on the result. Check Script Execution Delay Before Continuing - Define how much time can pass between a script's SCHEDULED start time and it's actual start. For example: Allow a script to run only within 4 hours of the time it was scheduled. Check Script Execution Window Before Continuing - Define a start time and end time. If the script begins running outside of this window it will exit. The time is compensated for the agents timezone and supports wrapping past midnight. (Start at 23:00 and End at 03:00 is understood as between 11:00PM and 3:00AM) Confirm Contract Status - Checks that an Agent is Under MSP Contract, and is not Excluded From MSP Contract. Example Loop - A simple loop (Like in the Scripting Lab) to execute a loop repeatedly until it reaches the specified limit. Example SQL Loop - A more complex loop that uses the SQL Get Dataset function to retrieve a recordset and loop through the results. Exit If Not Windows OS - Basic 2 line script starter to abort if the agent is not running a windows OS. Lookup Password Credentials - Allows you to retrieve the Title, Username, Password, URL, Notes, and ExpireDate for a password by providing the ID. Includes a query to find the "best" user matching a name ranked by location and expiration date, or use your own logic to choose the ID. Pause Script Until Remote Commands are Retrieved - A OS Neutral command that guarantees that the script will halt until the agent picks up the command and returns the result. Useful for pacing some operations that can fail if executed out of order. In times past, not all remote commands would pause the script. A "Create Folder" and a "Copy File" command could be scripted one after the other, but both could end up queued at the same time, and the agent might start the copy before the folder has been created. Also useful after executing an agent restart or service restart, ensures that the agent is checking in again. The Script Wait allows additional time to pass before continuing the script execution. Process Text One Line at a Time - Takes a variable with multiple lines of text (like output from a command) and loops over it one line at a time (like the SQL Loop does with rows). Run Temporary Batch or Shell Script - Largely replaced by the Execute Script function for Windows, but still useful for OSX/Linux. (And still works fine with Windows). This scriptlet generates a random filename, writes the script contents to the file, executes and then removes the script from the agent. To import a scriptlet, just use the Tools->Import->SQL function in Control Center (Or load the file contents into a Query Editor in SQLYog). To use the "Run Temporary Batch or Shell Script" refer to the screenshots below showing how to edit for Windows or OSX/Linux use. (Or both in one script if you are supporting multiple OS types!) Windows Batch Script: OSX/Linux Shell Script: