Hello Pn,
You're absolutely right that the Network Service account is expected to have permissions to run services like Windows Admin Center (WAC). When WAC is installed via the Azure portal either at the cluster or individual node level it sets the WindowsAdminCenter service to run as NT AUTHORITY\NetworkService by default.
I was trying to test your case from my end, and immediately after installation (build 11.2504.1001.19), the service was present but would not start. There were no modifications or domain policies in place this was a clean, standalone deployment in Azure.
After RDPing into the VM and inspecting the service settings (services.msc), I observed that switching the Log On As user from Network Service to Local System allowed the service to start successfully. This behavior was consistent across multiple attempts.
The root cause here appears to be that although Network Service is a built-in account with limited privileges, in some Azure-based or cloud-init provisioning contexts (even for standalone nodes), it doesn't get the necessary “Log on as a service” right applied automatically. This may be due to baseline security templates, the default local security policy, or how the WAC MSI gets invoked by the Azure extension agent.
How to fix it?
Assuming you have already created a VM (in this example I have used Windows Server 2022 VM Win2022Datacenter) in Azure.
Install WAC via the Azure Portal by enabling the “Windows Admin Center” extension.
Change the service account to LocalSystem using this PowerShell command:
$svc = Get-WmiObject -Class Win32_Service -Filter "Name='WindowsAdminCenter'"
$svc.Change($null, $null, $null, $null, $null, $null, "LocalSystem", $null)
Restart-Service WindowsAdminCenter
The service will start, and the WAC portal loads without issues.
In short, you're not missing anything. Your understanding is correct in theory, but in practice, the Network Service account may lack the necessary rights under certain WAC installation paths, especially those triggered through Azure. Switching to Local System is a valid and safe workaround unless a GPO or security baseline is enforcing something more restrictive.
reference document- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/log-on-as-a-service
