bild675

The RDM tool System Information report takes forever to return great information. Please consider improving the performance of this tool, providing a method to schedule the run of this report, and save the results in the DVLS database, where available, to allow for this great information to be available quickly.

The RDM tools should be able to use the gateway for access to servers when the gateway is available. Tools that rely on any of the protocols that the gateway supports should be able to use the gateway instead of failing because the protocol is blocked.

My assumption would be that people who are user RDM are connecting to servers and all our server connections user the gateway. But I have a difference in the RDM licenses that were auto assigned and the Gateway licenses that were auto assigned. It would be great to have a license report that would have all licenses, RDM, PAM, Gateway, and DVLS Cal so we could easily see the license usage by user.

Please consider adding a disallow security setting for a group or user and allow us to set the order of precedence to provide for the disallow to override an allow that was found further down the list of permissions. This would allow us to keep the default allow for the majority of our folders for view and execute, but disallow vendor groups that we don't want to be able to see the full list of entries in the vault.

After reviewing the info, it appears that this assumes that the SQLserver is on the same server as the DVLS web and scheduler. This is not the case for our configuration.

Please update if this isn't the case and this feature is able to determine that the SQLserver always on listener is available.

We have had issues where out always on SQLserver database connection was not available when the webserver and the scheduler service started after a webserver restart. Please consider adding some retries or some automation that would attempt to restart the scheduler service. We really like the high availability for the scheduler, adding restart automation would be a useful addition as we had a case where all three scheduler instances were not running.

Please consider enhancing the vmware dashboard:

1) add vmware tags to the dashboard.

2) add the commands to manage snapshots

3) add the flexibility to manage the columns that are displayed on the dashboard.

4) add Devolutions based security as an option for which VMs and which commands are available.

5) add the vcenter folder structure to the dashboard.

6) check the commands that the user has available in vcenter and grey out those commands that are not available.

Thanks

Bill

thanks for the update, it would certainly help to standardized when running on windows and using other SNMP services. Our use case is one component in replacing another application that does network monitoring and has SNMP walk features. This would provide the SNMP walk feature and complete the set as we already have the monitoring covered.

Please consider supporting the windows snmp features alone for the snmp report tool. Since the net-snmp needs to have the windows snmp features installed, per the readme, is it possible to just use the windows snmp features, so I don't have to load another feature and potentially impact the other windows apps that could use the windows snmp, but will not be able to, since it's disabled as part of the net-snmp install.

thanks

Bill

On gateway servers with multiple network interfaces, provide a configuration that would allow for all the server connection traffic to be sent to one interface, all other traffic to the DVLS server and the RDM user can use whatever interface that the server routing indicates.

Our use case, we have a network configuration that allows for the production networks to be deployed behind a firewall, so recovery testing can be done without impacting production operations. The gateway server has network interfaces on the production and the recovery networks, normal routing will not handle the duplicate network addresses. So interface specific routing allows for the server connections on the recovery network.

Please consider additional security for PAM accounts that will not allow DVLS admins to see the passwords on PAM accounts without some workflow approval, much like the PAM approval process. Our PAM users and our Security team would like to see additional security on these privileged accounts. PAM reporting of any access requests would be an additional feature to assist in audits.

I am looking for the same thing, I hope there has been some progress in the last 7 months and this will be available soon.

We have an additional use case where we would like to show the account status as out of compliance if the password has not changed in the required period. I know that for PAM, most/all passwords would be changed by automation of several kinds, but the compliance team wants to trust and verify that all the automations are in place and working as expected.

Many of our Devolutions users are only occasional users and could just use the web interface and not need to have RDM deployed to their workstation, but they use service accounts to get privileged access to many servers to do things like patch remediation. If there was a way to have them select the credentials to be used for the web connection without deploying an entire set of server connections with the default credentials being the service account, then they could just use the web connection feature and we would not have to maintain the RDM client on all their machines.

Please consider adding this feature to the web connection capabilities.

It would be really helpful if there was a way to add the manager from AD to the user report,

As an additional enhancement, adding the disable / enable status of the AD account would make the management of users more automated as the new subscription model requires managing the users more closely.

Consider adding inheritance to playlists so that the path to a server entry and be specified in one location and changed more easily.

Our current use case for this involves migrating playlists for our team folders where the play lists are used by the teams to select the servers that they manage.

We are migrating from SSH VPN to gateway based VPN, so we have server entries in different folders.

We will need to update every play list to use a different path to get to the new server path.

If we had inheritance, we could make one update to each playlist to use inherited path and then move one team folder at a time

Please consider adding a 180 day option for this report that would allow for a report for 180 days be scheduled.

We see that there is a custom option where we can specify the start and end dates, but that would not work for a scheduled report.

Our compliance team would like to see a single report that has the password rotation schedule, the last modified date, the last accessed by, and the last accessed date.

This info is currently available on the two reports for PAM, but running two reports and combining them when we are looking at over 10k accounts as we consider adding our service accounts to the PAM vaults, is not an easy task. A single report would be a lot better, or perhaps some custom reporting features.

Please also note that the notification for a password synch failure would also include the reason for the sync failure. In particular, if the account was locked.

thanks

that is a good start, but that means that the directory needs to have info on where local accounts may be. Perhaps having the scan feature scan ldap servers for those that have the local account would be a way to target those servers. One issue we are attempting to address is locating new local accounts that may have been created by installation of software or application team deployments that are not under management and oversight.

One of the issues we see with password changes on multiple servers, we change the password in the AD account and before all the servers can be changed, the unchanged servers make enough attempts to lock the account for invalid password attempts. Having a feature at the end of the list of servers to unlock the account and verify that it is unlocked would help remove one more manual step from the process.

It would be ideal to have a local windows provide be

able to reference a folder of server entries, so that the existing sync process

would be able to keep the list of servers updated, and the provider would be

able to reference the list.

I really don’t want to manage 2000 providers, and

since this is part of the migration from CyberArk, we need to have something

similar in Devolutions where a provider has list of servers with an PAM account

to change and a PAM account for access.

We have two different use cases, one where the

password needs to be different for every server/endpoint, and the other where

the password needs to be the same.

We are going towards the password being different, and

with PAM that seems possible, but that brings up another dimension for a PAM

account where there is a password per endpoint, instead of just one password

for all endpoints.

The other option would be to have the scan provide a list of servers that had the local account and have that stored in a vault/folder to be referenced.

Consider allowing the addition of custom tags or user types so that we can identify accounts that are not associated with a users. these service accounts are used for admin access to the console for DVLS, to run the scheduler and IIS app pool, and the connect to the database. We also expect to have at least two accounts per user, with domain admins having at least 2, to as many as 4 additional accounts.

Setting a tag or user type will allow easy tracking of the actual users for management of licensing and authentication.

Please provide any updates on the roadmap for syncing servers from Azure.

Hi,

Since the synch succeeds on the next scheduled attempt, I am thinking there is a transient issue, some additional logging for the error would help us find the issue.

Retrying the synch after a small delay would probably be successful and reduce the synch errors we are seeing.

thanks

Bill