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,