Change the session recording path - through Devolutions Cloud

Good Afternoon @Yoffstr

An internal ticket has been created for investigation. We will keep you informed here of any developments on this request.

Regards

Hi @Yoffstr

Thanks for splitting this out, and for explaining the underlying concern, that's the part that is most useful to us.

On the installer side: we agree it's reasonable, it's tracked internally, and it should land in a reasonable timeframe.

For this one, I would like to step back before we commit to a design, because I'm not convinced changing the path from the Cloud interface is the best answer to the problem you described:

• If the concern is the recordings filling the drive and bringing the server down, retention policy in Cloud/PAM service is I think the direct fix, and you already found the request for it. Once retention is in place, plus the ability to choose the path at install time, is there anything left that this request would solve for you?
• Note that changing the path doesn't move the existing recordings, so on a Gateway whose drive is already filling up, changing the path alone won't reclaim any space. You would still have to deal with what's already there.
• If there is a remaining scenario, I would like to understand it precisely. For example: an already-deployed Gateway where you've since added a disk or a network share and want to relocate. In that case, would a proper configuration tool running on the Gateway machine (interactive, no JSON editing, works on Windows and Linux) cover it, or do you specifically need to do this remotely without touching the server?

I ask because a Cloud-side solution and a Gateway-side solution are very different features on our end, and the second one would apply to every workspace type rather than only Cloud.

Kind regards

Hi @Benoit Cortier,

The two solutions proposed (cloud-side and gateway side) work for different scenarios. which I will list my reasons for the gateway side here in my other thread: Change the session recording path - through Gateway installer - so to keep the to conversation seperate as asked by the Devolutions team.

With regards to the Cloud, my secnario for this is:

If i am a MSP or a larger organisation that has multiple gateways and farm deployed. Majority of the time, my gateways are going to be standardised for ease of deployment and constancy. Now if i am wanting to be make the same adjustment to multple gateways, rather than logging into each one (RDP), using the (proposed) interactive tool, restarting the service and logging out.

Instead, you could make the config change in Devolutions cloud under the gateway module. Push the config change to the gateway/s, or gateway farm (which the cloud service could drain the updated gateway and then restart. once its back up then drain the next gateway in the farm and so on). Then the cloud could progressively update all the gateways without having to do it manually.

Hi @Yoffstr

The two solutions proposed (cloud-side and gateway side) work for different scenarios. which I will list my reasons for the gateway side here in my other thread: Change the session recording path - through Gateway installer - so to keep the to conversation seperate as asked by the Devolutions team.

Thank you for the detailed explanation, and my apologies again for initially posting in the wrong thread. I’ll quote the Cloud-related portion of your response here so that this part of the discussion remains in the appropriate thread. I also see a third, distinct workstream that may be worth tracking separately, which I’ll address below.

The two solutions proposed (cloud-side and gateway side) work for different scenarios. which I will list my reasons for the cloud side here in my other thread: Change the session recording path - through Devolutions Cloud - so to keep the to conversation seperate as asked by the Devolutions team.

With regards to the gateway installer, please see my answer to your questions below:

> If the concern is the recordings filling the drive and bringing the server down, retention policy in Cloud/PAM
> service is I think the direct fix, and you already found the request for it. Once retention is in place, plus the
> ability to choose the path at install time, is there anything left that this request would solve for you?

Answer: yes, i am sure this will address majority of the userbases requirements. Hwever, if someone misconfigures the recording location at install (by accident or lack of knowledge of what they are doing). Are they then going to be required to uninstall the gateway, in order to reconfig the recording location? my thought is if they can run a interactive program to reconfigure the gateway/recording path, that would be much easier.

> If there is a remaining scenario, I would like to understand it precisely. For example: an already-deployed
> Gateway where you've since added a disk or a network share and want to relocate. In that case, would a
> proper configuration tool running on the Gateway machine (interactive, no JSON editing, works on
> Windows and Linux) cover it, or do you specifically need to do this remotely without touching the server?

Answer: In this case, I believe a interactive tool would be most benifitical.

Agreed. We’ve been considering an interactive solution for editing the configuration after installation. Specifically: something graphical, rather than requiring users to edit the .json file manually or run a PowerShell cmdlet.

> Note that changing the path doesn't move the existing recordings, so on a Gateway whose drive is already
> filling up, changing the path alone won't reclaim any space. You would still have to deal with what's already
> there.

Answer: ok, so this raises a good point. If changing the path, wont bring the existing recordings over to the new location. will this cause integrity issues if someone was to bring them over to the new location (if they are wanting to keep consistancy - having all recordings in one location)? A suggestion, would be to prompt the user to see if they want the recording migrated to the new location or just left in the current location.

Hub maintains Gateway session metadata associating each recording with the Gateway on which it was created. The data source will continue routing playback requests to the associated Gateway, but the Gateway will no longer find recordings that remain under the old path. Offering to migrate the existing recordings as part of the interactive configuration workflow would make sense, and it is something we should consider.

I won’t expand further on the local configuration workflow here, because your latest example clarifies that the primary need behind this Cloud-side request is centralized configuration management for organizations operating multiple Gateways or Gateway farms.

If you would like to follow the separate graphical configuration tool workstream specifically, we could open a third feature request dedicated to it.

If i am a MSP or a larger organisation that has multiple gateways and farm deployed. Majority of the time, my gateways are going to be standardised for ease of deployment and constancy. Now if i am wanting to be make the same adjustment to multple gateways, rather than logging into each one (RDP), using the (proposed) interactive tool, restarting the service and logging out.

Instead, you could make the config change in Devolutions cloud under the gateway module. Push the config change to the gateway/s, or gateway farm (which the cloud service could drain the updated gateway and then restart. once its back up then drain the next gateway in the farm and so on). Then the cloud could progressively update all the gateways without having to do it manually.

Thank you for the input. For an MSP or a larger organization, updating each Gateway individually would require connecting to every server, changing the configuration, restarting the service, and verifying the result. Instead, you would like to make the configuration change from Devolutions Hub (EDIT: Cloud) and apply it to:

• multiple selected Gateways;
• all members of a Gateway farm; or
• potentially a broader group of standardized Gateways.

For a farm, you are also suggesting that the update be coordinated as a rolling operation: drain one member, apply the configuration, restart and validate it, and then proceed to the next member. This would avoid interrupting the entire farm at once.

This distinction is important. A basic remote configuration option would not fully address your scenario without bulk targeting and coordinated rollout.

I therefore see three progressively broader levels of scope:

1. Selecting the recording path during installation.
2. Providing a local, graphical and interactive post-install configuration tool.
3. Providing centralized, bulk configuration and rolling orchestration through Devolutions Hub (EDIT: Cloud).

The third level is significantly broader and more complex, but your last example clearly explains its value for MSPs and larger deployments.

Is that an accurate summary of the requirement?

Best regards,

Hi @Benoit Cortier,

that is an accurate summary of the requirement.

kind regards

Hi @Yoffstr

Thank you for confirming, I updated our internal ticket accordingly.

Best regards,