Since the same issue occurred on various occasions, I will summarize it here.
It is quite common for applications to create user accounts to run services under. This happens for SQL Server, HyperV, and a bunch of other software. However the service may refuse to start with a "log on as a service" permission is missing.
This is due to domain policies i.e GPO policies that set this "Log On As A Service" policy which is then enforced on all computers of the domain no matter what. A workaround is to disable this policy at group level to let local computers handle it. Which they do better in all cases I've seen so far.
To do so:
- Log on to the domain controller
- Run gpmc.msc
- In the left pane of GPMC, click the domain name to expand it, select the policy you want to check, like Default Domain Policy,
- Right click it and select Edit, it will load group policy management editor console for this group policy object,
- Navigate to the setting: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\
- Verify the Log on as a service policy, if set then clear the "Define these policy settings" checkbox and apply
- You may want to check all GPOs to ensure there is not one enforcing the settings
On the client computer you can then run a gpupdate /force command. The local policy should kick in and set the correct users for the log on as a service policy.