Marc-André Moreau

Hi,

The AD domain name should normally resolve to all the DCs in the domain by default, like this:

ad.example.com. A 10.0.0.10 ← DC1

ad.example.com. A 10.0.0.11 ← DC2

ad.example.com. A 10.0.0.12 ← DC3

We recommend that customers use the DNS domain name like ad.example.com instead of hardcoding individual DCs. As for automatic fallback, I just checked, and we resolve the list of addresses, and pick the first one that responds to the TCP connection. We haven't had issues with customers about the fallback behavior, but we do know that many customer use multiple DCs, so I can only assume the current fallback logic has been sufficient.

Rather than hardcode a list of DCs to pick from, I would rather keep the current configuration where you put in a single DNS hostname that can resolve to 1 or multiple DCs, and work on hardening or improving the robustness and performance of the fallback logic if the outbound connection to the KDC fails.

Hi,

You can use DNS load balancing in front of the multiple domain controllers, and use that DNS name with the KDC proxy configuration. As far as I know, this is how it works with other applications in Active Directory too, not just with Devolutions Gateway.

Best regards,

Hi,

We've had experience running our own relay servers in the past for customers (the Wayk product that we retired years ago), and it's a heavy burden. Third-party services like ngrok or cloudflare do it well. I take note of your feature request, but I don't think we'll offer this kind of service again.

Best regards,

Hi,

The drain mode is there to stop sending new connections to a node in drain mode, without disconnecting previously active connections on that node. After a while, the number of sessions should be close to zero, unless you have very long-lived sessions. Actively transferring active connections to a different node is not a small feature request, but we'll take it into consideration.

Best regards,

Here's a status update:

We just started publishing early builds of the new devo cli that we intend to use for the SecretSpec integration. It's not listed or announced anywhere, just search for "Devolutions.Cli" in https://devolutions.net/productinfo.json and find the build for your platform.

You can call "devo help" to see all the commands. If you launch "devo provider" the executable will use the WIP IPC protocol from SecretSpec, but you need to build SecretSpec from a development branch, and the IPC protocol will change before being stabilized. I'm in touch with Domen from SecretSpec about the IPC interface, it will allow SecretSpec to integrate with the devo cli without making custom wrappers for the devo cli commands itself.

So, not yet ready for easy consumption, but we're unblocking part of it on our side, and we keep collaborating with SecretSpec on the integration

It is still ongoing, the plan is to leverage the new IPC interface from SecretSpec for the devo CLI integration. I'm hoping to publish a first beta of the new CLI in coming weeks, and I've been sending feedback to Domen from SecretSpec on gaps and little things to fix in his new IPC protocol for SecretSpec.

Hi,

I've got an internal prototype working, but it requires a currently unreleased revamped Devolutions CLI. I'm in touch with the SecretSpec developer and working towards getting Devolutions as a supported provider, but there are challenges ahead. Unlike other providers, we don't have an easy to reimplement interface, so the best solution is to wrap those interfaces inside the a neat CLI that SecretSpec can then interface with. I know SecretSpec is currently working on an IPC interface for easier integration with external processes, so this would likely be the way to go once it is stabilized. Stay tuned, within the next months I think we'll be able to release this and finally get Devolutions added to the supported providers in SecretSpec.

Hi,

Recording multiple monitors to video comes with many challenges, starting with how to record each monitor (separately, or merged into one video which is much harder to view). We'll take the feature request into consideration, but I can already tell you this one is difficult.

Best regards,

Hi,

I'm not making any promises, but PostgreSQL support in DVLS is something we are considering. There is no timeline for when it could happen though, but I understand why you're asking for it.

Best regards,

Hi,

You can use https://devolutions.net/productinfo.json - a nice JSON file with all the information you'd need, and it's easy to consume from a PowerShell script.

Best regards,

Hi,

If you manually change the group membership and then even after replication finishes between the DC, only FreeRDP and mstsc work until you restart the RDM process, then I'm afraid there's something out of our control in the Windows CredSSP implementation that doesn't get refreshed. FreeRDP doesn't use the system CredSSP implementation and is therefore not affected in the same way as the RDP ActiveX.

I'm not sure we can really work around this one, even with the MsRdpEx API hooking. I would suggest either restarting RDM (not ideal), or using FreeRDP or IronRDP for the embedded mode.

Best regards,

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,

I think we have hot reload supported for the configuration already, have you simply assumed that it would not reload the configuration and that it should require a restart? On Windows, the simplest is to use the certificate in the Windows certificate store, it should definitely pick up the new certificate. If you tell me how you're currently setting the certificate I ask internally to see if that specific method should have the certificate automatically reloaded without restarting the whole service.

Hi,

Can you elaborate on the reasons why you would like to restart the Devolutions Gateway service remotely, or on a schedule? There is a feature to do centralized updating of Devolutions Gateway already, which restarts the service during the update process, but nothing that can restart without updating.

Best regards,

Hi,

Unfortunately, the MSRDC deprecation in favor of Windows App means this is even less possible than it was before. We have an unofficial MSRDC integration that is mostly used with AVD (I do not recall if it was confirmed to work with Windows365). It can still be used if you take the time to copy MSRDC outside of the Windows App MSIX install location and point RDM to it, but it's really too impractical to be usable.

The new Windows App doesn't even support launching with a custom .rdp file, which is how we launched MSRDC in external mode. We've got our hands tied here - Microsoft doesn't have a solution for third-party connection launchers like ours.

I would suggest making the request to Microsoft. The more users complain about this, the better.

Now the "interresting" thing is that I have updated RDCM to the lattest version (3.1) and I can't seem to have scaling working anymore (with unchanged settings) !! The working version was (very old) v 2.7 and it is not anymore available for download :/

I wouldn't be surprised if RDCMan 2.7 was DPI unaware, which is why it worked in the first place. This would have also meant that connecting to modern Windows disabled DPI awareness in RDP, but it would have worked just fine with DPI-unaware versions of Windows like Windows 7

It just crossed my mind, in the Advanced tab, have you tried switching "RDP Version" to FreeRDP? It's been a while since I last tested DPI awareness in RDM but there's a chance it would behave differently than with the RDP ActiveX from Microsoft when connecting to Windows 7

Windows 7 does not support DPI scaling, which does make it difficult to support it properly from an environment where DPI scaling is supported. Can you check the current DPI awareness level of RDCMan which you say works? You can enable the "process awareness" column in process explorer to see. If it's dpi aware and correctly handles Windows 7, there just be an undocumented (or poorly documented option) to turn DPI awareness off inside the RDP session. I know there's a "/dpiUnaware" option to launch mstsc with dpi awareness turned off, but we can't do this inside RDM as it would make the entire process DPI unaware. However, we could possibly add an option when we launch mstsc in external mode, would that be sufficient?

Hi,

If you were to pick between DVLS and Devolutions Gateway for ACME support, which one would you rather have first?

I'm asking because automatic certificate renewal through ACME is normally done inside the reverse proxy, if there is one, but also because DVLS and Devolutions Gateway are two separate servers implemented in C# and Rust.

In your deployment, would it make sense to assume Devolutions Gateway is deployed in a way that the ACME protocol with the HTTP challenge could be used to automatically obtain certificates from letsencrypt? This would be the simplest to implement, but it requires public DNS with a public IP, and HTTP on TCP/80 accessible.

Otherwise we'd have to look into the ACME DNS challenge and that's an entirely different "challenge" given that it requires authentication with the DNS provider you are using to perform.

Please elaborate on the kind of ACME challenge you'd need to use, which CA (letsencrypt? Or a private CA that supports ACME?), and how you'd envision a complete ACME certificate fetching and renewal flow.

Best regards,

Hi,

The issue has been fixed in 2025.3.16.0, here's a screenshot showing the same kind of test you did with the version where it was broken:

Sorry for the inconvenience

Best regards,

Hi,

Devolutions Gateway and RD Gateway cannot be combined - you need to use one or the other. However, you can combine Devolutions Gateway with most generic VPNs. This is because the RD Gateway protocol is a special protocol which is not easy to combine with other solutions that work at a similar level, like Devolutions Gateway. It would be a lot of effort and the result would be disappointing, you are probably better off moving away from RD Gateway if that's an option.

Best regards,

Hi Bill,

Thank you for attending the MCP in Action webinar yesterday. We're taking note of this feature request to see how feasible it would be, but realistically, I think the MCP feature will only be possible inside RDM for the near future.

However, I will keep thinking about how we could make the MCP feature possible in the web in the future. It's bound to happen eventually, I just don't know when.

Best regards,

Hi,

You can configure Devolutions Gateway to use the ports you want, we just use TCP/8181 for RDP by default to avoid port conflicts with 443 which is normally used for HTTPS.

As for the web listener in Devolutions Gateway, it is easier to set up behind port 443 alongside other HTTPS/WSS traffic. However, the web listener is used by the RDP web client, not the RDP desktop clients in RDM which go through the TCP listener.

Is your request to make those port configurables, or to drop the requirement to have a TCP listener separate from the web listener? There would be performance penalties to forcing everything to go through a web listener, which is why we're using this approach.

Best regards,

Hi,

I don't think there's a good way to extract this kind of information from the Microsoft first-party client, but there are some community tools like Remote Display Analyzer that may be better suited for this: https://rdanalyzer.com/

Would this work?

Best regards,

Hi Joe,

Devolutions Gateway health checks are handled server-side, not client-side, and for a good reason in the case of a Devolutions Gateway Farm: the logic for selecting the Gateway is performed server-side, not client-side. Rather than have the client try multiple hosts, we try to provide the client with just something to connect to that will work. Otherwise, we'd have to perform a separate connection test before launching the real connection, which costs precious seconds right in the critical path. If we were to just connect and let it fail to try again, the problem is we don't have good ways to detect connection failures in all cases to quickly recover from it by re-launching the entire connection.

You should plan to deploy Devolutions Gateway in a way that makes it reachable to both RDM and DVLS

Best regards,