I have a managed variable that I use for setting the password on systems inside a procedure, however it seems that I have to constantly go in an babysite this variable to add it to new groups or organizations.
Shouldn't this public global variable be just that...available for all groups without needing to go in and set it for each subgroup (kinda like in programming) where global varibles can be used by all functions if desired, although you can create local variables that only work for that particular function.
Sucks to find out that the reason your account doesn't work is because a new ORG was created and someone had to go manually apply the password to the new org and typo'd it...
Lol...turned into discussion...and fixing a title that looks like I was drunk...
Obviously your making a statement and not asking a question. you're of course right though. i also stopped using them cos it was a pain to manage
Here is a SQL script to automatically Clear Overrides
A better way to deal with this is create a Custom Field in the Organization. You only need to do this once so just make it part of your org setup process.
Then you can reference the Custom field via your script running against any machine within that org.
The advantage of this method is any groups etc added will be by default a part of this org .. and therefore the custom field will be valid for any machine referencing it irrespective of the group. So once created it essentially self manages
Paul Haaker (paul@mspassist.co.nz)
how do you handle if you need to make a change to that password...do you have some script that can update all the custom fields with a different password?
Hi Mark ... you just make the change by going to System / Manage ... select the Org and then in the Custom Fields tab just edit the custom field and enter the new password.
Or ... yes you could write a script to do a "global" password change for all org's
Thanks..will have to give it a try...we like to try and change the password quarterly and in event someone leaves...I want to be sure we can lock them out...
Here is a link that is related to this post; community.kaseya.com/.../66367.aspx
I still think this is a core improvement issue, Managed variables is treated like a Legacy feature and I still see great value in it and want the interface to it improved to match level of editing Custom Fields at least. Something else I think that needs to be added is the ability to set a value at the top level (Organization or Primary Machine group) and using the sub machine groups to set overriding values.
The interfaces to modify the Managed Variables and Custom Fields should be merged into one and be object orientated interface allowing you to filter the type of object similar to what you can do in the Network Discovery Module's objects and set the values. I know n-Able can do this and its a great let down that Kaseya can't or just don't care to. Thinking about it the Policy Manager Module could actually make a reasonably good vehicle for this as from what I have seen the Policies works very well with custom fields (Hint) so it would make sense to add this to that module.
Something related to this is around populating Custom Fields, Procedure Variables and Managed Variables with passwords, as it is it not secure at the moment. I would like to see the ability to hash-out sensitive information like this so that you can set it but not see it and have it encrypted the Kaseya database.