How to Manage Workgroup PCs with Windows Admin Center Safely

Windows Admin Center can manage Windows PCs and servers without installing an agent, and it can operate without an Active Directory domain. In a workgroup, however, the gateway loses Kerberos-based identity and central policy. You must deliberately configure trust, credentials, firewall scope, local elevation, and recovery after reboot.

The secure goal is not to make every PC trust everything. It is to allow one known management gateway to reach a defined set of machines, with a different administrative credential on each endpoint.

Know What Windows Admin Center Replaces—and What It Does Not

Microsoft describes Windows Admin Center as a browser-based tool for servers, clusters, Windows PCs, and Azure VMs. It consolidates many administrative views and remote actions. It does not become Active Directory, Intune, an employee-monitoring product, or a full remote-support platform merely because it can connect to a PC.

Use WAC for authorised administration: event logs, services, devices, storage, firewall, updates, PowerShell, local accounts, and supported extensions. If the requirement is central application deployment, compliance policy, unattended remote assistance, or user-session observation, select a purpose-built management platform and define privacy rules separately.

Use a Dedicated Gateway

For more than a lab, install the current Windows Admin Center gateway on a supported Windows Server with a static IP, stable DNS name, restricted administrative access, and a CA-trusted TLS certificate. Microsoft’s current installation guide uses the Windows Admin Center v2 executable and notes that installer-generated self-signed certificates are for testing.

On Server Core, the documented unattended flow is:

$parameters = @{
    Source      = 'https://aka.ms/WACdownload'
    Destination = '.\WindowsAdminCenter.exe'
}
Start-BitsTransfer @parameters
Start-Process -FilePath '.\WindowsAdminCenter.exe' -ArgumentList '/VERYSILENT' -Wait
Start-Service -Name WindowsAdminCenter

Verify the current download URL and installer options in Microsoft documentation at deployment time. Production installation should specify the intended HTTPS port and trusted certificate rather than accepting unknown defaults.

Prepare One Test PC First

On an authorised Windows 10 or Windows 11 endpoint, open an elevated PowerShell session:

Get-NetConnectionProfile
Enable-PSRemoting -Force
Set-Service WinRM -StartupType Automatic
Get-Service WinRM
winrm enumerate winrm/config/listener

Enable-PSRemoting configures WinRM listeners and firewall rules appropriate to the current network profile. Do not silently change a legitimately public network to Private. Fix the network classification only when the adapter is actually on a trusted private network.

Scope the WinRM firewall rule to the gateway address. Replace the documentation address below:

$GatewayAddress = '192.0.2.25'
Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP' -RemoteAddress $GatewayAddress

If the named rule does not exist, inspect the enabled WinRM rules before creating anything:

Get-NetFirewallRule | Where-Object DisplayGroup -eq 'Windows Remote Management' |
    Get-NetFirewallAddressFilter

Microsoft’s workgroup troubleshooting guidance calls out WinRM TCP 5985 for workgroup machines on another subnet. Permit it only from the management source or subnet, not from arbitrary networks.

Configure TrustedHosts Explicitly

In a domain, Kerberos authenticates the remote computer. A workgroup connection often needs the WAC gateway’s WinRM client to trust named targets. Inspect the current value first:

Get-Item WSMan:\localhost\Client\TrustedHosts

Then set an explicit comma-separated list on the gateway:

$ManagedHosts = 'pc-01.example.lan,pc-02.example.lan,192.0.2.41'
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $ManagedHosts -Force

Do not default to *. Microsoft warns that setting TrustedHosts can overwrite the existing value and that trusted computers might not be authenticated. Keep an inventory, use stable DNS where possible, record changes, and review the list when a PC is retired.

TrustedHosts is not encryption, authorisation, or proof that a reused local password is safe. Browser-to-gateway traffic uses HTTPS, while gateway-to-node security depends on WinRM configuration and authentication.

Handle Local Administrator Elevation Deliberately

Use an administrative account dedicated to remote management, not the everyday user. The credential must be a member of the target PC’s local Administrators group; some tasks can also use Remote Management Users with reduced capability.

Windows applies remote UAC restrictions to local accounts. Microsoft documents this setting for a non-built-in local administrator in a workgroup:

$RegistryPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
New-ItemProperty -Path $RegistryPath -Name LocalAccountTokenFilterPolicy -PropertyType DWord -Value 1 -Force

This enables a full administrative token for qualifying remote local-account connections. It increases the consequence of stolen credentials, so combine it with unique passwords, a dedicated management network, limited firewall sources, endpoint protection, and auditing. Do not deploy the same local administrator password to every PC.

Windows LAPS is the preferred Microsoft mechanism for rotating local administrator passwords, but its secure backup targets are Microsoft Entra ID or Windows Server Active Directory. Microsoft’s Windows LAPS overview makes those join-state requirements explicit. A pure workgroup therefore needs another protected, audited password-management process or a move to Entra/AD management.

Add and Test the PC

In WAC, add a Windows PC connection using its stable FQDN or address and choose the dedicated local credential for that endpoint. Before diagnosing the UI, test transport from the gateway:

Test-NetConnection pc-01.example.lan -Port 5985 -InformationLevel Detailed
Test-WSMan pc-01.example.lan

These tests separate DNS, routing/firewall, and WinRM failures. If they succeed but WAC authentication fails, check username format, group membership, UAC token filtering, clock, and saved credentials.

Make Reboots Predictable

After onboarding the test PC, restart it and verify each layer:

Get-Service WinRM
Test-NetConnection pc-01.example.lan -Port 5985
Test-WSMan pc-01.example.lan

On the gateway, confirm the current WAC service and HTTPS port:

Get-Service WindowsAdminCenter,ServerManagementGateway -ErrorAction SilentlyContinue
Get-NetTCPConnection -State Listen | Where-Object LocalPort -in 443,6516

The older gateway service name can appear on previous WAC generations; current WAC v2 uses WindowsAdminCenter. Check the installed release rather than repeatedly restarting a service name copied from an old guide.

When connectivity disappears only after a restart, inspect:

  • gateway and endpoint services and startup types;
  • changed network profile or firewall-rule profile;
  • DHCP address or DNS changes;
  • expired or replaced gateway TLS certificate;
  • WAC HTTPS port conflict;
  • a cleared or overwritten TrustedHosts list;
  • endpoint WinRM listener and event logs.

Microsoft’s WAC troubleshooting page recommends testing the gateway HTTPS port and ensuring WinRM runs on both gateway and managed node. Capture the failing layer before changing registry, firewall, or certificate bindings.

Scale Without Turning the Workgroup into a Shared-Password Domain

For a handful of isolated lab PCs, an explicit inventory and manual credential vault may be acceptable. As the fleet grows, workgroup administration becomes fragile: no central group policy, no Kerberos, limited group-based WAC access across untrusted boundaries, and difficult password rotation.

At that point, evaluate Microsoft Entra join with Intune, a Windows Server AD domain, or another supported endpoint-management system. WAC can remain a useful administrative console, but it should not carry identity, software deployment, compliance, remote support, and password management by itself.

The safe workgroup pattern is narrow and testable: one protected gateway, explicit hosts, source-scoped WinRM, unique local credentials, deliberate elevation, and a reboot validation checklist.

Related Guides