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,