Azure Local - Windows Admin Center won't start

Pn 55 Reputation points
2025-04-30T04:26:59.8+00:00

After installing Windows Admin Center via Azure portal either at the Cluster or Node level, the WindowsAdminCenter service on each node is setup to run with Network Service account. This account doesn't seem to have permissions to run services. As soon as the Log On As is changed to Local System, the service runs without issues.

This is on the latest build 11.2504.1001.19 but we experienced the same issue with the last few builds (fresh deployments, no modifications to stock configuration).

My understanding is that Network Service should always be allowed to run services. Is there something I am missing here ?

Azure Local
0 comments No comments

Answer accepted by question author

Arko 4,180 Reputation points Moderator
2025-05-15T08:37:32.95+00:00

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.

vm1

Install WAC via the Azure Portal by enabling the “Windows Admin Center” extension.

vm2

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

vm3

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

Was this answer helpful?


0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.