WinGet release channels / version branches for RDM and Devolutions Server compatibility

1 vote

Published 2 days ago

Hello Devolutions Team,

we are deploying Remote Desktop Manager for Windows centrally through Microsoft Intune and WinGet.

The current WinGet package ID is:

Devolutions.RemoteDesktopManager

This works very well for installation and upgrades.

However, there is one challenge for enterprise environments using Devolutions Server:

According to the RDM / Devolutions Server compatibility model, the first two version segments need to remain compatible. For example, when our Devolutions Server is on the 2026.3.x release branch, we need to keep all RDM clients on the 2026.3.x branch as well.

We would like to automatically deploy maintenance releases such as:

2026.3.10
→ 2026.3.12
→ 2026.3.13
→ 2026.3.x

but prevent an automatic upgrade to another release branch such as:

2026.4.x

or:

2027.x.x

With the current WinGet package ID, there is no straightforward way for an enterprise administrator to define:

"Always update to the latest available 2026.3.x release, but never automatically cross the 2026.3 branch boundary."

This makes automated update mechanisms such as WinGet AutoUpdate difficult to use safely with RDM when Devolutions Server compatibility must be maintained.

Would you consider providing an officially supported release-channel mechanism for WinGet?

Possible approaches could be:

1. Separate WinGet package IDs for supported release branches, for example:

Devolutions.RemoteDesktopManager.2026.3
Devolutions.RemoteDesktopManager.2026.4

or

2. Another officially supported mechanism that allows enterprise administrators to pin RDM to a release branch while still automatically receiving maintenance releases within that branch.

Our ideal enterprise workflow would be:

Devolutions Server: 2026.3.x

RDM clients:
Automatically update to the latest 2026.3.x version.

When Devolutions Server is deliberately upgraded to the next compatible branch, the administrator would then move the clients to the corresponding new RDM release channel.

This would make RDM much easier to manage through Microsoft Intune, WinGet, WinGet AutoUpdate, and similar enterprise software-management solutions while maintaining the required server/client compatibility.

Thank you for considering this request.

Thank you.

Best regards, Johann

All Comments (1)

Hubert Mireault

Published 2 days ago

Hello Johann,

Thanks for the detailed write-up, the use case makes sense. The good news is you may not need a separate package ID for this. The point you mention about pinning is the appropriate solution here. A gating pin with a wildcard keeps a package inside a version range and still lets it take updates within that range:

winget pin add --id Devolutions.RemoteDesktopManager --version 2026.3.*

With that pin in place, winget upgrade and winget upgrade --all move RDM to the newest 2026.3.x and skip 2026.4 and later. The upgrade logic walks the available versions from newest down, skips anything outside the gated range, and installs the newest one that fits.

When you move DVLS to the next branch, you swap the pin:

winget pin remove --id Devolutions.RemoteDesktopManager
winget pin add --id Devolutions.RemoteDesktopManager --version 2027.1.*

There are two things to watch out for in an Intune / WAU setup:

Pins are stored per profile, not per machine. WinGet keeps them in its local state folder under the current user profile. A pin you add from your own admin session won’t apply to upgrades that run as SYSTEM, which is how Intune and WAU usually run. Deploy the pin with a script that also runs as SYSTEM, for example an Intune platform script or a remediation. Under SYSTEM you’ll likely have to call winget.exe by its full path under C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*, since it isn’t on PATH there.
WAU’s install fallback can bypass the pin. WAU builds its update list from winget upgrade and then runs winget upgrade --id …, and both respect the pin. But if that upgrade fails, or the installed version doesn’t match what WAU expected, it retries with winget install --id … --force. --force deliberately ignores pins, so in that failure case WAU could install the latest version and leave the 2026.3 branch. It only happens when an upgrade fails, but keep it in mind, and it may be worth raising with the WAU project.

To be transparent, I haven’t tested this end to end myself. Based on the WinGet docs and the source code, it looks like a promising approach that should cover what you described without anything changing on our side. Please let us know if it ends up working well for you.

Regards,

Hubert Mireault