Junyi Ou

Hi @mab2, it will definitely be in the next release. If everything goes well, the fix will be included in the next patch.

Hi Malthe,

Here's the benchmark, done with real RDM sessions recorded through Gateway at the default frame rate (1 fps).

RDP (1590×946)

Gateway records at up to 1 fps, but only stores a frame when the screen changes, so an idle session costs almost nothing.

- Active: ~20–24 MB/h

- Idle: ~2 MB/h (same when it sits in a background tab)

Web session (1024×768)

The page is captured every second, changed or not.

- Active: ~15 MB/h

- Idle: ~8 MB/h

However, we did find a way to significantly downsize web sessions. Playback still looks the same (1 fps, no loss in readability), but Gateway only stores the frames where something actually changed, like RDP already does:

- Active: ~8 MB/h (−44%)

- Idle: ~0.7 MB/h (−92%)

This will be implemented in the next version of Devolutions Gateway.

The frame rate can be raised up to 5 fps by an admin if you want smoother playback; an active RDP session then comes to about 45–50 MB/h.

If you have any more questions, please let me know. I hope this covers your use case.

Best regards,

Will the recording work for all sessions, including web?

Yes, as long as the website entries open embedded in RDM (not in an external browser) and are set to go through Gateway.

Regarding video recordings, the issue is that high fps videos take up a lot of space, while low fps videos can be finicky to play back in many players. Is there an internal tool that can properly play back videos, even at low fps?

Yes, RDM and DVLS both have a built-in player. Our recordings are also standard .webm files, so modern players and browsers like Chrome, Edge, and Firefox can play them too.

Is the whole RDM recorded continuously at once, or is each session recorded individually?

Each session is recorded individually.

I understand your concern is about size and recording quality. We will have a ticket to improve both aspects and will bring back a benchmark shortly to see if it would work for your use case.

Hi Lars, thanks for reaching out, we indeed has the plan to support picking specific agent for traffic routing, we are looking forward to add support to it to the next version of Devolutions product. Best!

Thanks for the detailed input.

We already have several building blocks in RDM, Devolutions Gateway, and DVLS that cover much of what you described.

• Gateway recording is activity-based. For RDP sessions recorded through Devolutions Gateway, video is written mainly when the screen changes. A static session therefore produces little additional recording data. This differs from local timer-based recording, which still records at regular intervals.

• Mandatory recording is already supported. Recording can be set to Required at the vault root, folder, or entry level. Child entries can inherit the setting, and users without permission to change the recording settings cannot disable it. If required recording cannot start, the connection is blocked.

However, we do not currently record only the active session or support screenshot-on-click recording. A possible improvement would be to add activity markers, such as mouse or keyboard events, so reviewers can quickly skip inactive periods and find the relevant parts of long recordings. Would that solve your problem?

We can also look into ways to further reduce recording sizes. In fact, counterintuitively, video may sometimes result in smaller files because it can store only the differences between frames, while screenshots generally need to store each image as a complete frame.

Hi Malthe,

Thanks for the extra detail. Before we think about implementation, I want to make sure we're designing against your actual constraint rather than against the shape of your current tooling — so a few questions, and I'll be upfront that the answers could change what we'd propose.

1. Who consumes this evidence? Is it (a) evidence you retain for your own ISO 27001 surveillance audits, (b) a deliverable you contractually hand to customers, or (c) something you only produce on demand when a change is disputed? Each of those implies a quite different artifact.

2. Is "screenshot on every click" a control you wrote yourself in your ISMS, or something your certification body or auditor specifically mandated? Put differently: if we could satisfy the same control objective with a different form of evidence, would you be free to adopt it, or are you locked to screenshots?

3. On the M365 / Azure / DNS work — are those opened as website entries inside RDM, or in a normal browser on that server, outside RDM? This matters more than it might seem. Devolutions Gateway records the remote access protocol stream, so anything that doesn't traverse Gateway as an RDP/VNC/SSH session can't be captured that way at all.

4. You'd like to move RDM onto technician workstations. Today TS Monitor runs on a server your technicians don't administer, so they can't switch it off. If capture ran locally inside RDM instead, what's your requirement on tamper resistance — must a technician be unable to disable, pause or delete their own capture, and does that need to survive auditor scrutiny?

5. How do you retrieve evidence in practice? If you can, walk me through the last time you actually had to produce some: what did you search on (customer, date, ticket, hostname), and how long did it take?

6. Two numbers would really help us size this: your retention period, and roughly how much storage TS Monitor generates per technician per day.

One last thing worth separating: "don't record inactive sessions" and "screenshots instead of video" are two independent asks. An idle session compresses to almost nothing. If capturing all open sessions cost you very little storage while they were idle, would recording them still be a problem — or is storage the whole of the concern?

Best regards,