Option to change Windows Service-Account of Gateway Service

Hi!

We recognize the need for a better supported workflow here. As per internal discussions, we are looking into:

1. Updating the installer to ensure it does not overwrite a custom service account on updates.
2. Providing documentation about the required permissions for a custom Windows service account running the gateway.

We’ll keep you posted on any progress for official support and documentation.

Best regards,

Hello @stefannitsch-fitz

I've been looking at this issue and I had hoped to make some changes for 2026.1.3; I'm not sure if that's still feasible but I'll keep you posted and at the latest we'll probably be looking at 2026.2 (next month).

There are a few things I want to clarify with you, based on the work I've already done.

First, you wrote

everytime you modify the gateway-configuration from the server console (companion tab), the service-account automatically changes back to NETWORK SERVICE

Are you sure this is accurate? The reason the service account gets updated is that the Windows MSI treats every update as a "major upgrade" (versus a patch). In Windows Installer, this means that the existing product gets uninstalled and then the new version gets installed, rather than just replacing the updated files. So the service is recreated in this scenario and the user account customization gets lost.

The thing is, I don't see another path that can happen and it shouldn't happen by editing the configuration. Can it be that you actually mean this happens when updating Gateway by the console? Or perhaps when you noticed this, it coincidentally happened at the same time as an update? Please let me know, because if what you say is true then further investigation is needed.

Secondly, can I ask what kind of account you're using for Gateway? Is it a well-known account (e.g. LOCAL SERVICE), a virtual account, or maybe a gMSA / MSA? The key with those kind of accounts is that they don't need a password. If you're using a regular Windows / domain account (which as I understand it, would not be recommended) things are more complicated because it's harder to support an upgrade path without needing to re-specify the password on every upgrade (that may not be so bad for manual updates, but is much more complicated via DVLS or Agent).

I understand the problem with the other issues you've raised.

Please, let me know if something isn't clear

Kind regards,

Hi!

I can confirm that when just changing config the account does NOT change. So its only happening when updating as you mentioned!

The account is a regular local Windows account (server is not domain joined). This is required for SMB-Access to work because only with a windows account I can set username and password accordingly.

Kind Regards,
Stefan

Hi @stefan nitsch

Thanks for the confirmation.

I'm still thinking about this and trying to decide if it's an X-Y problem (i.e. the issue manifests at install time, but perhaps there is another way to make changes and provide what you need).

So I can clearly understand the business problem: the issue is that you want to have the recordings directory on a shared path, but you want to isolate the permissions to only specific user accounts. Granting a virtual or gMSA / MSA account is not suitable for you because it means granting permissions to the machine itself, rather than an account; right? Or is there another problem with using a virtual or managed service account?

Thanks and kind regards,

Hi!

It's not even about isolating permissions. The problem is, that I was not able to access the SMB share (non domain-joined NAS) from Windows Server 2025 without username/password. I was following various guides how it could work in theory but ultimately it only worked the classic way where you create identical username and password on both sides.

Kind Regards,
Stefan

Hello

Thanks a lot for clarifying. I agree that your reasoning is sound and in this case a virtual account or g/MSA would not help.

I've got a number of approaches we can take here but none of them is ideal. The simplest path is just to reacquire the service credentials on every upgrade, but there's no reasonable way we can do that and still support automatic updates (e.g. via DVLS / Agent).

We're discussing this internally and I will get back to you

Kind regards,

Hi Stefan

Sorry for the long delay. I have been working on this and have something to share.

As you've noted, it's possible to run the Gateway under a custom service account, but it requires post install customization. The customization will be lost on Gateway upgrades or repairs. That is still true as of 2026.3.0.

The next version of Gateway will support passing a service account (and optionally a password) to the installer at install or upgrade time. The installer will recognize that a custom account is being used and properly configure permissions and so on, instead of resetting to NETWORK SERVICE every time.

However, there are still rough edges when using a regular domain account (username and password). In this case:

• You'll need to provide the username and password for the service account on every upgrade or repair
  • This isn't currently supported by DVLS Console, although we'll add it in the future; right now you'll need to use msiexec
• Gateway upgrades via Devolutions Agent are not supported and will fail in this configuration. There's no path for the Agent to know the service account password at upgrade time.
• When upgrading, certain issues with the installation that forces a rollback may leave the service in broken state, this is unlikely but possible. In that case, it would need manual intervention to fix whatever caused the rollback before running the installer again to repair things

So, essentially if you use a custom account we would recommend something passwordless like a gMSA but I understand that doesn't seem possible in your environment. These improvements should make things easier for you, but it will require some extra care and attention when upgrading or performing maintenance and you lose the ability to update via Devolutions Agent.

I've drafted documentation around the current state of things (manual customization) as well as the incoming improvements and I'd encourage you to take a look. Ultimately not many people are using custom service accounts today, so there will likely need to be some refinement on our side; and once things seem stable enough we'll work on migrating the documentation to the official Devolutions portal.

Otherwise if you have any questions or comments, please don't hesitate to reply

Kind regards,