Kaseya Community

SQL commands in Kaseya Procedures (msg+++SQLCMD)

  • Just confirming, and have tested on my 6.3 system that we can still run our +++SQLCMD scripts

  • Awesome Smile

  • Another thought is do any of us use the +++SQLCMD to insert, update or Delete data .. or do we just use it to retrieve i.e. Select data from the database to then use in a variable within the remainder of the script ?

    I for one only ever use a select .... so how about Kaseya allowing only selects .. that way there is no danger of use corrupting the database

  • As all you guys are displaying the KCA badge (about to start mine) what are your thoughts on a very high level Kaseya course which would cover the database and some of the things that we probably all do on a daily basis?  It's been alluded above that these changes can be made to the database but what about an official Kaseya path for this?

  • I do insert values to suspend alarms as per Ben's suspend alarms step that unfortunately keeps breaking during Kaseya updates to the agent procedure module because it is not officially supported by Kaseya. The majority of the stuff I do are select queries, updating and inserting values could be handy if I had a better understanding of how the values in the tables worked together and if I could find valid reasons to do so.

    As for High level Kaseya course, some of the Kaseya boot camp guys 4-5 years back briefly showed these SQLCMD's and said that they where planning an advanced Kaseya Scripting course then about 2+ years ago they offered an Advanced Kaseya Scripting course which cost $1000 NZD and was a complete waste of time because the guy hosting it decided to go back to the basics since most of the guys attending did not have the basic skills required to do the advanced stuff.

    Does not look like the guys at Kaseya cares about us, 3days and counting...

    [edited by: HardKnoX at 11:55 AM (GMT -8) on Dec 6, 2012] typo
  • i use select, update, insert, delete, replace and i have never had a problem with accented deleting the wrong things

    i've been on 2 boot camps many years ago

  • Hi everyone. Direct access to the database (even for a master admin) opened up some nasty security issues that I won't go into here. We already knew about and are plugging this same security issue in Service Desk in its next release. However, I completely understand the value of this functionality to our power users. We are working though a solution that will give you back direct database access in both agent procedures and service desk procedures in the 6.3 release.  We have not completed the security audit of this approach yet so its not final. Once it is, I'll post a description here. I hope to have this done in the next week or so which gives you plenty of time to beat us up over it prior to the official 6.3 release. Stay tuned.

  • Sounds great as long as i can be a "PowerUser"

  • @Mark - This is excellent news. It feels great to not only be heard but have it acknowledged like this. Keep up the good work.

  • @Mark Sutherland

    This is good news and could have completely prevented this thread if it was communicated in advance!

    Thanks Yes

    Now back to the shadows with me planning my next grumpy community post...

    [edited by: HardKnoX at 7:00 PM (GMT -8) on Dec 6, 2012] typo
  • Back to calling your VSA "My Precious" there is it, knox?

  • HardKnoX
    Now back to the shadows with me planning my next grumpy community post...

    LOLRoll Eyes

  • Nice job Kaseya (Mark) not only do we get a response but it comes from on high.  I do love it when the community gets this sort of feedback directly from Kaseya.

  • ghettomaster

    Back to calling your VSA "My Precious" there is it, knox?

    Hey I'm all good just doing my bit for the community Cool 

  • Hi all. This is a follow up to my post from last week. In version 6.3, Kaseya will roll out a new technique to give procedures secure database access.  The following technique solves the security problems we closed by removing +++sqlcmd support from the procedure editor. We will designate a directory on the VSA server itself to contain an approved list of SQL commands (in XML files) made available to script writers. Anyone with direct access to the VSA server can add/edit these files. Typically this is the master admin but clearly someone with direct access to the VSA server is trusted. You can put any arbitrary SQL into these files that you like. Each entry in the XML file will contain the raw SQL plus a label. The procedure editor will add a couple new commands to use these SQL commands in scripts. Script authors will select the SQL command by label and never see the raw SQL. This should make it easy to use since you can clearly state what the SQL is supposed to do rather than depend on users figuring out what the SQL does.

    This will be available on both our SaaS hosted VSAs and on-premise VSAs. Each tenant in the SaaS environment gets their own directory so there is no chance of tenant A getting access to data from tenant B. Also, to use this on SaaS you have to submit your SQL to Kaseya since we are the only ones with server access. We will review the SQL to guard against malicious code and then post it to the directory for that tenant.

    Several people have asked me for an early look at this new feature. We will be hotfixing this out to all test pilot 6.3 systems so you will all get it at the same time (assuming you are in the test pilot program). I would expect this hotfix to go out in the next couple of weeks.