A few months ago Team Kaseya filter blocked the msg+++SQLCMD commands so that we could no longer use them in our procedures. Any existing procedures with these commands still worked however if we tried to edit them or import exported scripts with these commands they would fail making many of the procedures some of us shared in the Knowledge Exchange worthless.
I have figured out how to bypass this filter block without the need to make changes to Kaseya Portal's code and people have been asking how to do this. I don't want to share how I have managed to do this because if I do and Team Kaseya learns how I have done this they will find another way that might be more permanent for all of us.
The best thing I can think that we can do is ask the them why they are now preventing us from using something that we have had access to for so many years this very without providing us with alternatives. I understand that direct access to the Kaseya Database is a potential security risk however using a syntax filter block does not overcome this security risk and at the same time prevents most of us with legitimate reason to query values in the database.
I recently had a need to update the rebootPending value in the patchStatusTotals table for development reasons via an Agent Procedure and was told that “Direct manipulation of the database outside our application is not supported!”. How is using a Agent Procedure "outside of our application" and why then are people allowed to write modules for the Kaseya VSA that can “Direct manipulation of the database" and even add new tables?
What I want from this post is to get back access to the database via agent procedures for the hardcore coders without the need to go behind Kaseya's back to do what we need to do.
I second this. Kaseya stop fighting us and making our lives harder.
btw: 6.3 also removes access to the hidden button to view scripts from live connect.
+1 - it's absurd. There are so many other ways to manipulate the database this move was overkill.
I too have my own work-around for the SQLCMD issue and have the same approach as you on who I'll tell about it - mum's the word!
The question is do they work on 6.3. it seems to be more locked down than 6.2
Anyone wanna give us access to their 6.3 box so I can find out?
You probably all need to purchase the new Kaseya SQL Add-On Module - available to you all for a very reasonable price...
Totally agree with this. When Kaseya support give me a SQL Query to run to fix a database issue does my use of SSMS count as being outside the application? We've been told that nobody can create extra tables in the ksubscribers database yet I've stumbled across Symantec tables from when I was testing the BE add-on.
Or how about the "Execute SQL NON Query" Step in Service Desk .. which allows you to insert, update or delete from any table in the database
I liked the original idea where use of the +++SQLCMD was going to be restricted to Master Admins only ..... who more than likely have direct access to the SQL database anyway.
Just my 10 cents worth
Paul's idea of only master admins being able to use it would be a compromise that I could live with.
Not nice that they plan to remove the "hidden" view button, would be good if they could give us a reason why they have decided to do this.
6.3 has a new script editor, so I'm not sure if my workaround or any of my existing scripts that utilizes the SQL command would still work.
Your old scripts that use SQLCMD still work in 6.3 i doubt that will change as trillions of the system scripts use it
All the work around that i know of dont work in 6.3 but im not all knowing so there maybe a work around that works
I have been tossing up different options on how to deal this this issue.
This minute im going with two kaseya scripts that when run will ask me what script it want to modify and then it will change the +++SQLCMD: to something else. this means i can edit the script and once fished i run script two to change it back to +++SQLCMD:
This is all very frustrating, isn't it.
i actually think you guys shouldn't be bringing up the SD and i suggest you remove it from your comments as the MOST likely things Kaseya will do is remove the ability to do so !!!
And you are right you can still write a procedure (SQL or not) and run it against the Server if you want to poke it,
@Michael - How's that?
Not sure what you mean sorry
It would be good if Brendan Cosgrove can arrange for one of the guys at Kaseya that was involved in this to read our posts and understand that what they have done is not a good solution and that it does not really solve the problem that they intended to fix.
In fact I think it is going to create a whole bunch of new problems as many of us will now try and figure out away around what they have done which could in fact cause exactly what they did not want to happen.
I have never liked the idea of customizing the database or the web front end on my own because there is always a risk that if you do this that an update supplied by Kaseya could break it or worse the customizations breaking the patch or even Kaseya VSA after it is patched.
Some might say that I'm trying to cause trouble but I'm really trying to prevent it from happening in the first place and the only way we can do this is by being open and upfront about it.