A Windows Admin Center deployment outside Active Directory produced a long chain of failures:
- the gateway URL returned
ERR_CONNECTION_REFUSED; - the installer logged
WacPort must be outside of ServicePortRangeStart and ServicePortRangeEnd; - managed PCs returned “The client cannot connect to the destination” from
Test-WSMan; - WinRM warned that its firewall exception would not work on a Public network;
- Network List Manager Policy prevented changing that profile to Private;
- the system worked temporarily, then failed again after a restart.
The mistake was treating every symptom as one WinRM problem. There are two separate paths to test: browser to gateway, and gateway to managed node. Authentication and policy come only after both listeners are reachable.
The two connections
Windows Admin Center uses:
administrator browser → HTTPS → Windows Admin Center gateway
Windows Admin Center gateway → WinRM/WMI → managed Windows node
Microsoft’s Windows Admin Center FAQ states that browser-to-gateway traffic uses HTTPS and gateway-to-node management uses PowerShell and WMI over WinRM.
If the browser gets connection refused, changing a target PC’s TrustedHosts cannot help. If the gateway opens but adding one PC fails, reinstalling the gateway certificate is unlikely to help. Test the failing segment directly.
Phase 1: prove the gateway works locally
On the gateway machine, record the URL and port selected by the installed build. Then check:
- the Windows Admin Center or
ServerManagementGatewayservice exists and is running; - the service startup type is appropriate;
- the configured TCP port is listening;
- the local gateway URL opens on the selected HTTPS port;
- the Windows firewall permits the intended remote administrator sources;
- the certificate matches the name administrators use.
Use:
Get-Service *WindowsAdminCenter*, ServerManagementGateway -ErrorAction SilentlyContinue
Get-NetTCPConnection -State Listen | Sort-Object LocalPort
Test-NetConnection -ComputerName localhost -Port <PORT>
Service names vary by Windows Admin Center generation, which is why the first command discovers rather than assumes. Microsoft’s troubleshooting guide likewise tells administrators to verify the gateway service and test its selected port.
Treat the installer port error as authoritative
If the log states that WacPort overlaps the internal service port range, the requested configuration did not apply cleanly. Do not cycle through folklore ports such as 6516, 6600, 8443 or 44300 until one appears to work.
Read the active installation parameters and choose a port outside the ranges reported by that installer version. Confirm that it is free before reinstalling or changing the endpoint, then verify the listener after the operation. Preserve the installer log; a mostly successful install can still contain the one failed action that explains the browser error.
Phase 2: prove WinRM reachability
Once the gateway is reachable, test each node from the gateway host:
Test-NetConnection -ComputerName <NODE> -Port 5985
Test-WSMan <NODE>
The first test asks whether TCP reaches the default HTTP WinRM listener. The second performs WS-Management negotiation. Their outcomes narrow the problem:
- TCP fails: route, name resolution, network profile, firewall or listener.
- TCP succeeds but
Test-WSManfails: listener configuration, protocol or authentication. Test-WSMansucceeds but WAC fails: credentials, authorization, gateway identity or tool-specific delegation.
On the managed node, use an elevated console to check:
Get-Service WinRM
winrm enumerate winrm/config/listener
Get-NetConnectionProfile
Get-NetFirewallRule -DisplayGroup 'Windows Remote Management' |
Select-Object DisplayName, Enabled, Profile, Direction, Action
Do not enable Remote Registry merely because WinRM fails. It is a different service and is not a prerequisite for proving the WS-Management listener.
Public network profiles and firewall scope
Windows client disables PowerShell remoting by default, and the firewall treats Public networks more restrictively. Microsoft documents Enable-PSRemoting for managed Windows clients and explains that connections from outside the local subnet may require an adjusted WinRM firewall rule.
Change a network to Private only when it really is a trusted private network. If Network List Manager Policy locks the category, identify whether the policy is local, domain-managed or MDM-managed. Change the policy at its source or ask its owner.
Do not delete policy keys or edit the network profile registry to defeat an enforced GPO. The block is evidence of an administrative decision. Bypassing it creates configuration drift and the policy may simply return at refresh or restart—which matches the observed “worked, then failed” behavior.
If a Public profile must remain Public, scope the WinRM firewall rule to the gateway’s exact address or management subnet instead of opening it to Any.
TrustedHosts is not a list of permitted clients
In a workgroup, Kerberos is unavailable, so the gateway cannot automatically authenticate a target through the domain. WinRM TrustedHosts tells the client which remote names or addresses it is willing to trust when mutual authentication is otherwise unavailable.
It is not an inbound allowlist, and * means trust every destination. Microsoft’s guide permits a wildcard as a convenience but warns that setting the value overwrites existing entries. A safer configuration saves the current value and lists only managed nodes:
$old = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
$old | Out-File C:\Admin\TrustedHosts-backup.txt
Set-Item WSMan:\localhost\Client\TrustedHosts `
-Value 'pc-01,pc-02,192.0.2.25'
Use real FQDNs or addresses; the example address above is from the documentation-only range. Restore the previous value when testing is complete.
Do not enable unencrypted Basic authentication as a shortcut
Workgroup does not mean Basic authentication must be enabled. Windows Admin Center can use Negotiate with explicitly supplied local administrator credentials and TrustedHosts. Enabling Basic expands credential exposure, and changing both client and service authentication settings obscures the original failure.
Keep AllowUnencrypted disabled. If a product integration specifically requires Basic, use WinRM over HTTPS, scope it narrowly, document the need and test certificate validation. It should not be the first response to a failed TCP connection.
Local administrator token filtering
A local administrator connecting remotely may receive a filtered token. Microsoft’s UAC remote-restrictions documentation explains the LocalAccountTokenFilterPolicy behavior, and the WAC workgroup guide documents cases where a non-built-in local administrator needs the full remote token.
Changing this policy increases the reach of local administrator credentials. Before doing so:
- use a unique managed local administrator password per device;
- limit WinRM at the firewall to the gateway;
- avoid reusing one administrator password across every workgroup PC;
- log remote administrative activity;
- prefer domain, Entra/MDM or a purpose-built management identity when the fleet grows.
Apply the policy only after network and WSMan tests prove that authorization is the remaining failure.
What Windows Admin Center does not provide
WAC can expose processes, services, events, devices, updates, PowerShell and other management surfaces depending on the node and installed extensions. It is not a web-browsing surveillance system and does not natively provide a reliable per-user list of visited sites. DNS filtering, secure web gateways and endpoint security products solve different problems and require policy, privacy and legal review.
Likewise, WAC is not automatically a software-deployment platform for a fleet. PowerShell can perform installations, but repeatable deployment needs package detection, rollback, logs and desired-state reporting.
Windows 10 status in 2026
Standard Windows 10 support ended on October 14, 2025. Microsoft’s end-of-support notice recommends upgrading eligible devices, replacing incompatible hardware or using an applicable Extended Security Updates path.
Do not invest in a new long-term workgroup management design around unprotected Windows 10 endpoints. Use this troubleshooting process to stabilize a migration or supported ESU environment, then move the managed fleet to a supported client version.
The reliable order is gateway listener, node listener, firewall scope, WSMan negotiation, identity and finally authorization. That order avoids turning a single blocked port into a collection of unsafe exceptions that still disappear after the next policy refresh.
