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
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.
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 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.
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.
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 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!
This monitor will return the number of available licenses in the result. I also made the Identity field report 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. This means that 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 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 be the stock "Create Ticket" alert. I would suggest this be changed to an alert template that generates email so that the notice can be sent directly to the person who manages agent licenses.
Unzip the attached file, and import into Control Center using "Tools -> Import -> SQL File". The Internal Monitor name will be "CWAutomate Agent Licenses Available".