14-10-2019, 08:53 PM (This post was last modified: 14-10-2019, 08:59 PM by rqpartners.)
Everything was working just fine last week, but now I'm noticing that some folders/connections won't let me configure protocol options. No permission changes were made as far as I'm aware, nor would I have the patience to edit some but not all folders.
As a test I checked each of the folders I've made under the "Connections" section - 20% of them work while the other 80% don't, including the root.
Working:
Not Working:
Permissions on my security group for both folders tested:
Could someone point me in the right direction, or have any clue on this?
If it helps I'm on ASG-RemoteDesktop 2019, version 12.0.6469.1.
Oliver - you're a wizard, that was it! It turns out that the "working" folders were not inheriting from the root and instead had their own checkboxes checked for the roles. All the other non-working folders were inheriting from the root, which had all the roles unchecked.
For our own curiosity, any ideas whatsoever how this could have happened? As you can tell we didn't even know about this section, let alone know enough to go in and mess around with it. Was it something with the latest patch and having some options reset/cleared?
No - the roles were implemented with version 2015 :-) Before everything was visible on all objects - but right now we have several plugins and we think users just need to see what they are using…
Perhaps anybody "removed" it mistakenly on the root object
Chasing up on this old issue, it looks like it has popped up twice already - once two weeks ago and again today. We've had no changes with regards to upgrades or account management (honestly we try not to change anything if it's already working the way we like it).
Is there anything automated or otherwise you guys suggest we could check to understand why the roles/protocols keep getting reset/removed?
Oliver - thank you for the insight. I reviewed the change log for this recent incident as well as the past two or three. I can clearly see the "roles" being re-added which matches the timeline when things were "fixed", but there are no entries for the roles being removed.
These are what the "fixes" look like:
Role 'Ext. Application' was added to object 'Connections'.
Role 'SSH' was added to object 'Connections'.
Role 'Telnet' was added to object 'Connections'.
Role 'ICA' was added to object 'Connections'.
Role 'VNC' was added to object 'Connections'.
Role 'HTTP/S' was added to object 'Connections'.
Role 'RDP' was added to object 'Connections'.
Role 'Credentials' was added to object 'Connections'.
Though I could not find any events specifying how the roles are removed, one common theme I found is that between all the incidents there is a string of events:
Standard properties 'General=>General' of item 'Views' was changed.
Standard properties 'General=>General' of item 'Layouts' was changed.
Item of type 'Folder' with name 'Favorites' was created.
Item with name 'Favorites' was deleted.
Item of type 'Folder' with name 'Ext. Applications' was created.
Item with name 'Ext. Applications' was deleted.
Item of type 'Folder' with name 'Connections' was created.
Item with name 'Connections' was deleted.
Item of type 'Folder' with name 'Credentials' was created.
Item with name 'Credentials' was deleted.
Although it lists the user account next to these events, I can guarantee none of the actual users have deleted and re-added full copies of these folders (I doubt they even know how!)
Does anything come to mind that might explain why these top-level "folders" (not sure what else to call them) are re-created? It sounds like the permissions are stripped during each recreation, but I'm just guessing at this point.
Oliver - FYI it happened again today. I asked the person of the account the changes were registered to and he said he vaguely remembered ASG reporting a lost connection but he was able to reconnect shortly. Not sure if that helps but no one else reported a connection prompt, so we didn't think it was a problem with the database.
Ok - can you please check if the following option is enabled:
Settings=>Permissions=>Show root items for all users
On startup of application there is a check if the root items exists in the database - if not they will be created (to ensure everything will work) - this is the only place where root items can be created so I guess it has something todo with your issue - but nobody else reported issues like this until now so it really strange...
Oliver - understand, thanks so much for entertaining our weird issue.
Our ASG administrator searched for the setting you mentioned and found it enabled already. He unchecked it so I guess we'll see what happens in another two weeks.
15-04-2020, 11:56 PM (This post was last modified: 15-04-2020, 11:57 PM by rqpartners.
Edit Reason: attaching screenshot
)
Oliver - sorry for the lack of response but since we didn't have any new information to reply with we were in a holding pattern on this.
We've been trying to note the circumstances that lead up to this problem and we are definitely circling in on this database disconnection event.
It looks like when one of us has our ASG open for an extended period of time (could be a day, could be a few days) we might get a notification from the software that it couldn't reach the database server and it's working in offline mode. After a few minutes the session is restored and we're prompted to "sync" changes. I attached a screenshot.
We've tried to see if this disconnection is present on the systems involved, but neither workstation nor server show any trace of a network disconnect. Any ideas?
Not easy - but SQL connections are managed by .NET framework - I don't know if a connection will be dropped after some time - normally .NET / SQL Client should connect again
The offline mode is only starting after a "Test-stored proc" in sql could not be executed anymore - we do this as a connection test before the command we want to execute on the database - if this stored proc call runs in a time out - the program tries to switch to Offline Mode
On my VDI I have ASGRD sometimes open over the weekend and I can go on monday morning without any issues - so it seems not be a common issue...