Kaseya Community

Is it a bug, or...

  • We have 12 security roles in our VSA, from level 0 that allows an admin assistant or accounting team member to run reports, to level 9 that allows Master-like access (but blocks agent administration). Level 1 and 2 are for the engineers that allow agent management. There are 4 level 5 "specialist" roles that permit administration of specific VSA functions (patching, Auth-Anvil, and such), and two level 9 roles, one that allows security management. We then have 3 customer-access roles - Remote Desktop, L1, and L2 with increasing access levels.

    We have two Dev VSA platforms, one on-prem and one in SaaS, and two prod VSA platforms. We develop in Dev On-Prem, test in Dev SaaS, and then deploy to Prod. Each VSA platform has the same configuration, right down to the roles and role names.

    I have nearly 300 views, about half for either MSP-only or general use (all users, including clients), and the other half are used for policy control. As views are created, they are shared appropriately. The MSP-only views get the 9 MSP roles; the General Use roles get 9 MSP and 3 Customer roles, and the policy control views have no additional access.

    Here's the issue:

    • I export the views from Dev and import into any other platform, and none of the share settings are preserved. Well, even though the Role names are the same, the RoleID values are different, so I accept that these can't be translated. Probably some security concept, which is odd because any change to VSA (product add) grants full access to all roles, but hey, I digress..
    • To insure that the role IDs and Names match the target system, I create a fake view on the target system, assign all custom roles to it, and export it. The resulting XML file contains the Role Name and Role ID values from the target. I extract these into a configuration file. I run a script on the exported XML file that finds each Role Name, looks up the target value in the config file, and replaces the Role ID with that from the target system. Thus, all Role Names and Role IDs should match the target, and the import should work.
      Alas, it does not. If the roles were not imported at all, I'd figure that security settings were ignored during import of the views. This is not the case, in fact, SOME of the roles are imported properly, while the rest are ignored. Hmm, I must be overlooking a setting somewhere.. let's try something else.
    • I create a view, assign ALL the custom roles and export the view. I delete the view and import the just-exported view back into VSA. Again, only SOME of the roles are imported back into the original machine. I opened a support ticket, because this is clearly a bug..

    The support engineer replicates this issue and escalates to engineering. Engineering says "this is by design" and I should open a Feature Request. I decline and ask to escalate. I think that if this was "by design" that either ALL or NONE of the security roles would be imported, but having SOME imported is not by design. If that were the case, how would the decision be made as to which role is imported and which is excluded? Digital dice roll, perhaps? I've gone round and round with this for the past month in support, PSE, and engineering, so - I figure I'd put it to the community:

                Is this a BUG or BY DESIGN??

    Let me know your thoughts.


  • We had a similar issue and have also been told the same thing - that it is by design. I think that just means that they accept that it's an issue but can't be bothered to do anything about it.

  • If you run this on your SQL Server then you can bulk add perm's to view

    Update ksubscribers.dbo.viewDef

    Set readWrite = 1 , shareAll = 1

    where viewName like '%WhatEverViewNamesYouWantToUpdate%'

  • Thanks, Paul.

    I'm pressing the issue because it needs to work in SaaS. I rewrote a bunch of our tools to eliminate the SQL queries we use to get around other such bugs, but we've got no control over this one.

    Asking for SQL queries in SaaS is pointless.. I opened a ticket for the Managed Variable bug that crashes the procedure when you reference an undefined value. Kaseya PSE provided a SQL query almost identical to what we had. I tested and verified it would work, then submitted a ticket for them to deploy it in our SaaS environment. They said they needed to review and approve it. (really? you gave it to me!) It's going on 8 weeks now - I gave up and developed a workaround that doesn't require the SQL query.