Screen recording for only current session, and in screenshots instead of low framerate video

I see on your roadmap that you plan on rebuilding the session recording engine. Perhaps this can be implemented alongside that?
I feel like this would benefit many customers, not only us. Especially in the EU where GDPR is important

Hi,

Help me understand your use case, as I'm not so sure. Right now, you're using RDM through Parallels Client, because Parallels has a session recording feature that you like, and this allows you to record everything done with RDM inside that Parallels session? You would like to replace this session recording feature by Devolutions Gateway, but since the recording is done for each session inside RDM, and not RDM as a whole, this means multiple video recordings, etc. You'd be happier if the recording could be done as screenshots instead of low frame rate videos due to storage concerns. Did I miss anything?

Best regards,

Hi Marc-André

Yes we are using RDM on a remote server through Parallels Client and on that server we are using SoftActivity TS Monitor to take screenshots of every click so we have documentation of all changes made. Since it takes screenshots of the entire app, it only records the active session, where as how i understand the native RDM recording feature will record every open session simultaneously even if they are not currently worked on.
This makes our current solution a lot more storage efficient, while also being easier to sort through since low fps videos that the RDM screen recording uses can often cause trouble during playback. And high fps video captures a lot more data than necessary. Especially if it also records inactive sessions. In our work flow we often have multiple sessions open that we use throughout the day, which would quickly congest the storage server.

If RDM could only record the current session in screenshots, either every second or two, we could use RDM natively and locally for hopefully much smoother performance than our current remote app solution - and maybe even take advantage of some other devolutions gateway features such as Entra SSO.

-Malthe

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,

1. In your example, it is both a and c. It is mainly audit related for our selves and our ISO 27001. However we also sometimes use it on demand as evidence or to see how a certain change was made.

2. We are not locked to screenshots per se. It's just the solution we found that encompasses a good mix of stability, storage space, and traceability - without a lot of empty documentation (since it only captures on click). If a superior alternative is found, we wouldn't mind switching.

3. They are all opened as embedded tabs inside RDM and thus they are screenshotted as well. We never use a server's browser to do work. When we connect to a server entry in RDM it is to manage something related to that specific server.

4. A technician shouldn't be able to disable or pause it. It must be controlled and configured centrally, and it needs to survive auditor scrutiny as it's important for our certifications and contracts.

5. Typically we check the logs in RDM itself from when a given user was logged onto a session, then we use this datestamp in TS Monitor where we can sort both on RDS server, username and of course time. There may be a lot of screenshots in this time period so sometimes we have to navigate back and forth before we find the right one. TS Monitor has a web interface where the screenshots are essentially shown in a gallery.

6. I'd say a typical operations employee (typically very often in RDM) is around 150 MB per day, ca. 1500 screenshots. It uses webp for compression.

One thing is the storage consumption of the video, another thing is the potential hours of inactivity which would cause needless clutter and be annoying to search through.

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.