Jump to content

Search the Community

Showing results for tags 'rawsql'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • MSPGeek
    • Announcements
    • The Geek Cast
  • ConnectWise Automate / Labtech
    • ConnectWise Automate / LabTech
    • ConnectWise Automate / LabTech - Development

Categories

  • ConnectWise Automate
    • Scripts
    • Plugins
    • SQL Snippets
    • Role Definitions
    • Automate PowerShell Code
    • Reports
    • Internal Monitors
    • Remote Monitors
  • ConnectWise Manage
    • API Interacting Code

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Location


Agent Count


INTERESTS


OCCUPATION


ICQ


WEBSITE


WLM


YAHOO


AOL


FACEBOOK


GOOGLEPLUS


SKYPE


TWITTER


YOUTUBE

Found 5 results

  1. We've all come to the forums at some point looking for a way to get more specific results from a monitor than is available with the default tools and options in CWA, and have stumbled across posts detailing the complex and arcane process of making RAWSQL monitors. These are basically where you take all the builtin logic that monitors do behind the scenes and recreate it manually with a query. The advantages of this are that you can get much more specific with your queries to a degree simply not possible in a regular monitor. There are downsides to RAWSQL monitors though. They require a lot more work up front. Regular monitors do a lot in the background, like returning a bunch of info that ties the results to the computers detected, and CWA assumes this data is returned so a monitor that doesn't do this will not alert properly. This can be done manually, mostly by joining the agentcomputerdata table in the query and returning values from that. Even if you do this properly, some features like ignoring agents or group targeting (according to Darren) have to be done manually in the query rather than from the simple GUI. There are also issues with supportability, if you ask a support person to help you with anything even somewhat relating to a RAWSQL monitor they will laugh you right off the phone. So, what if you want to do something a little more complex than a regular monitor can handle, but don't want to deal with the atrocity that is RAWSQL? I would use what I like to call a LazySQL monitor. A LazySQL monitor is one in which you let the builtin monitor functions handle most of the busywork, and you use the additional conditions field to limit the results to computers returned from an SQL query or queries that do all the complex selections and limiting and whatnot. Basically, you make a monitor that by default catches every computer (I make it look for "computerid notequals 0"), I will attach an example of a monitor where I do just that so you can visualize it more easily. As you can see, the basic monitor configuration is very simple and would match all computers, then I do the more specific stuff, like returning computers that have patches missing and an EDF checked, as subqueries in the additional conditions field. This field basically just tacks on whatever is in it to the end of the SQL query put together by the monitor. For a simpler use case, let's take one I just finished explaining to a user in the slack channel. He wanted to put together a RAWSQL monitor to return all computers that didn't have a specific software installed, for our purposes let's say firefox. Instead of making a complex RAWSQL monitor to do this somewhat simple thing, he could use a LazySQL monitor. Using the same basic settings as the above picture, simply adding "AND computerid NOT IN(SELECT DISTINCT c.computerid FROM computers c JOIN software s ON c.computerid = s.computerid AND s.name LIKE "%firefox%")" as the additional condition field made the monitor limit it's results from all computers, to only those whose IDs were NOT returned by the subquery, which returns all those that do have firefox installed. This monitor will have greater supportability, greater functionality because it fits into CWA better, and took about 5 minutes to make and deploy. Please note that I am aware the last example returning computers without firefox could be accomplished easily with a regular monitor by using the invert check function. LazySQL monitors shine when you need to match a bunch of disparate criteria because it's easy to gather the computerids that match in a subquery and just check for "computerid not in (subquery)". Try not to nest a bunch of subqueries inside each other, if you can, because that can be slow. If you have any questions, you can always try asking me in the slack channel -Slartibartfast of Magrathea
  2. This monitor identifies the current agent version for OSX, Linux and Windows Agents. Each hour the monitor checks for agents that are not at 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 update commands already in the queue. This has been moved to the File Download section. You can download it here: https://www.mspgeek.com/files/file/45-cwa-agent-version-update-monitor/
  3. Hi, I am trying to test an internal monitor I've created. I'm using a RAWSQL monitor. Unfortunately, when in the configuration window, if I go to the "Query Results" tab, the query seems to hang, and if I mouse over the results pane, it just displays the hourglass. Running the query in my DBMS works fine. More confusingly, another user can open the monitor configuration window and see the query results, so it doesn't seem to be an issue with the query. Does anyone have any ideas or experience with this issue? Thanks!
  4. I thought this one of mine was worth sharing, especially helpful if you need a method of mass generating alerts/tickets/warnings for clients running Office 2007 or earlier. https://gavsto.com/internal-monitor-rawsql-machines-running-office-2007-v12-or-earlier/ Instructions and download above!
  5. What started as an idea for assigning the "FriendlyName" for an agent by a script run one agent at a time, turned into a single SQL query that could update the FriendlyName for many agents at once. Wrapping that into a RAWSQL Internal Monitor allows you always have the data updated, and to flexibly control how it is applied. The Internal Monitor can have agents excluded or groups targeted to easily manage the scope of agent updates or to prevent any specific agent from possibly being updated. The name is updated to include the computer Model (computers.BiosName) string. If the FriendlyName is not blank and doesn't contain the model name, then it has been customized by someone else and will not be changed. This monitor sets the name to " ( - )". It also checks that the computer name doesn't already include the serial/svc tag, if it is present in the computer name it leaves it out of the FriendlyName. Because of the potential to change many systems at once, I left some safety checks in place you will need to remove. Specifically, the "AND c1.computerid IN (1,2,3)" limits the agent list to those specific agents. You can add a single computer or two here to test the monitor, and when you are comfortable remove that section of the query (in red). This is the monitor. If you do not specify a location or group for targeting, the query will fail. To resolve this, remove the section in orange. To allow computer exclusions to work, the AgentID number in the query must match the AgentID for the monitor (highlighted yellow). I tweaked the SQL import statement so this should be fixed for you, but you have been warned that the number must match your system AgentID for exclusions to work properly. If you want to change how the FriendlyName is set, the sections to modify are shown in green. I discovered some issues (Whitebox systems with a svc tag value of 'To be filled in by O.E.M.', and other odd values in my environment) so I have updated the query included in the attached .zip. The new query is shown below, when I have time I'll add the color markup and remove the outdated first image. The updated query still contains the "SAFETY" code limiting to computerid (1,2,3) or clientid(-1). Remove/Adjust those statements to test or deploy in production. AssignFriendlyNames.zip
×
×
  • Create New...