Windows · Admin Center

Windows Admin Center

A practical guide to Windows Admin Center, the browser-based management gateway that replaces Server Manager and MMC for administering Windows Server and Windows clients remotely.

Quick idea: Windows Admin Center is a single browser-based gateway that replaces the old scatter of MMC snap-ins, Server Manager, and RDP sessions with one console for managing Windows Server and Windows clients remotely.
Gateway

The service that runs Windows Admin Center and reaches out to target machines using Remote PowerShell and WMI over WinRM.

Extensions

Modular tools — Server Manager, Certificates, Firewall, Storage, Virtual Machines — that plug into the gateway and can be added or removed independently.

Role-Based Access

Lets non-administrator users manage specific aspects of a server through a Just Enough Administration endpoint, without full local admin rights.

What Is Windows Admin Center?

Windows Admin Center is a locally deployed, browser-based tool set for managing Windows Server and Windows client machines — physical, virtual, on-premises, or in Azure — without sending anything to the cloud. It is the modern evolution of tools administrators have used for two decades: Server Manager, MMC, and the collection of snap-ins that came with them.

Think of Windows Admin Center as a single reception desk for a building full of servers. Instead of walking to each room with its own separate key — an RDP session here, an MMC console there, a PowerShell window for something else — you check in once at the desk, and it hands you whichever tool the room you are heading into actually needs.

It has two main parts: the gateway, a lightweight service that does the actual connecting to target machines, and a set of extensions — modular tools like Certificates, Firewall, Local Users and Groups, Processes, Registry, Roles and Features, and Storage — that run inside it. Microsoft ships the core extensions, and both Microsoft and third parties can publish more through the extensibility SDK.

Important: Windows Admin Center complements System Center, RSAT, Intune, and Azure Stack rather than replacing them. It is built for managing one server or one cluster at a time, not for fleet-wide monitoring or patch orchestration across thousands of nodes.

How the Gateway Works

The gateway manages Windows Server 2016 and later, and Windows 10/11, by using Remote PowerShell and WMI, both carried over WinRM. No agent gets installed on the target machine — WinRM and PowerShell remoting already ship in the box. The gateway itself is a single .msi package, and the current (“modernized”) gateway runs on a .NET 8 backend with an ASP.NET Core Kestrel web server, replacing the older Katana-based backend. That switch also brought HTTP/2 support, which reduces latency through multiplexing and server push.

Internally, the modernized gateway uses a multi-process, microservice-based architecture. A single process manager starts when the gateway launches, and it spins up additional subprocesses on demand as you use different tools — a change from the earlier single-process model, intended to make the gateway more resilient (one misbehaving extension subprocess is less likely to take the whole gateway down).

Installation type Where it runs Best for
Local clientA Windows 11 PC, reached at https://localhost:6516Quick start, testing, ad hoc, small scale
Gateway serverA designated Windows Server, reached by any browser with network access to itLarge-scale, shared, multi-admin scenarios
Managed serverInstalled directly on the server or cluster node being managedDistributed, self-contained scenarios
Failover clusterDeployed across cluster nodes in an active-passive modelProduction environments needing gateway high availability
Key rule: Windows Admin Center cannot be installed on a domain controller. Manage domain controllers by connecting to them from a gateway installed elsewhere.

Why Active Directory Cares About the Gateway

Windows Admin Center is not itself an identity system, but its gateway sits directly on top of your identity model. When the gateway is domain-joined, it authenticates users against Active Directory or local machine groups by default, and gateway administrators can instead point it at Microsoft Entra ID to get conditional access and multi-factor authentication for free. In a workgroup — no domain at all — you fall back to local accounts on both the gateway and every target machine, and WinRM’s default restrictions become something you have to actively work around.

Access to the gateway itself is a separate question from access to a given target server. A user can reach the gateway but still needs credentials with administrative rights on whichever machine they try to manage — the gateway does not grant permissions on its own, it only provides the console.

Practical note: In a workgroup, if you connect with a local account that is not the built-in Administrator, the target machine needs LocalAccountTokenFilterPolicy set to 1 before WinRM will honour that account’s admin rights remotely.

Installing Windows Admin Center

Before installing, you need admin rights on the target machine and, optionally, a TLS certificate with the Server Authentication EKU (1.3.6.1.5.5.7.3.1). If you skip bringing your own, the installer generates a self-signed certificate valid for 60 days — fine for a lab, not for production.

On the desktop experience, the installer walks you through Express setup (network access and port chosen automatically) or Custom setup (you choose the port, the TLS certificate, the endpoint FQDN, and whether WinRM runs over HTTPS). On Server Core, or when you’d rather script it, use PowerShell instead:

# Download the installer to the local machine
$parameters = @{
    Source      = "https://aka.ms/WACdownload"
    Destination = ".\WindowsAdminCenter.exe"
}
Start-BitsTransfer @parameters

# Install silently, specifying the HTTPS port and certificate thumbprint
.\WindowsAdminCenter.exe /VERYSILENT /HTTPSPortNumber=443 /CertificateThumbprint="1234abcd4567efgh"

# Start the gateway service if it did not start automatically
Start-Service -Name WindowsAdminCenter

A local-client install listens on https://localhost:6516 by default. A gateway-server install typically binds to port 443, which is also why an old, stuck certificate binding on that port is the most common reason a reinstall silently fails to bind — see the troubleshooting table below.

Managing Access — Role-Based Access Control

By default, a user needs full local administrator rights on a target machine to manage it through Windows Admin Center — the same as logging on locally. Role-based access control exists for the case where someone needs to do part of that job without getting full admin rights on the box.

RBAC works by configuring each target server with a PowerShell Just Enough Administration (JEA) endpoint. When a limited-access user connects, Windows Admin Center creates a temporary local administrator account behind the scenes to carry out the actions their role permits, then removes it automatically once they disconnect.

Role Intended use
AdministratorsMost Windows Admin Center features, but no Remote Desktop or PowerShell access — a good fit for jump-server scenarios.
ReadersView server information and settings; cannot make changes.
Hyper-V AdministratorsChange Hyper-V virtual machines and switches; everything else stays read-only.

RBAC currently only covers the Server Manager and Failover Cluster solutions, and limited-access users lose file upload/download in the Files tool, and lose the PowerShell, Remote Desktop, and Storage Replica tools entirely regardless of role.

Automating Windows Admin Center with PowerShell

For anything beyond a handful of gateways, the bundled PowerShell modules are worth knowing. ExtensionTools manages feeds and extensions across a gateway from the command line:

# Load the extension management module
Import-Module "$env:ProgramFiles\windows admin center\PowerShell\Modules\ExtensionTools"

# List every extension currently installed on a gateway
Get-Extension "https://wac.contoso.com"

# Install a specific extension from the default feed
Install-Extension -GatewayEndpoint "https://wac.contoso.com" "msft.sme.containers"

# Add a private extension feed (a network share, for internally built extensions)
Add-Feed -GatewayEndpoint "https://wac.contoso.com" -Feed "\\wac-share\our-private-extensions"

ConnectionTools handles bulk import/export of the server and cluster connection list, useful when standing up a new gateway or migrating away from an old tool like Remote Desktop Connection Manager:

# Load the connection management module
Import-Module "$env:ProgramFiles\WindowsAdminCenter\PowerShellModules\Microsoft.WindowsAdminCenter.ConnectionTools"

# Export the current connection list, including tags, to a CSV
Export-WACConnection "https://wac.contoso.com" -fileName "WAC-connections.csv"

# Import a connection list on a new or rebuilt gateway
Import-WACConnection "https://wac.contoso.com" -fileName "WAC-connections.csv" -AccessKey ""
Practical rule: You must be a gateway administrator to add, remove, or update extensions through PowerShell — gateway users can run the read-only cmdlets but not the ones that change state.

Troubleshooting Cheat Sheet

Symptom Likely Cause Fix
Browser shows This site can't be reached Gateway service stopped, wrong certificate selected on first launch, or trusted hosts cleared by an OS upgrade. Confirm the WindowsAdminCenter service (or ServerManagementGateway) is running, then test connectivity: Test-NetConnection -Port 443 -ComputerName wac.contoso.com -InformationLevel Detailed.
Can't connect securely to this page (TLS error) The browser machine is restricted to HTTP/2, which does not support the integrated Windows authentication Windows Admin Center uses. On the browser machine, set two registry values to disable the HTTP/2 restriction: New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Http\Parameters" -Name "EnableHttp2Tls" -PropertyType DWORD -Value 0 -Force (and the matching EnableHttp2Cleartext value).
Reinstall fails to bind, or nothing else can use the same port A previous install left a stale SSL certificate binding on that port. Clear the old binding: netsh http delete sslcert ipport=0.0.0.0:443 then netsh http delete urlacl url=https://+:443/.
Can connect to some servers but not others WinRM, network connectivity, or authorization issue specific to that target. From the gateway, run Enter-PSSession -ComputerName <name>. If that fails too, the problem is WinRM/network, not Windows Admin Center.
Cannot manage a workgroup machine on a different subnet The WinRM firewall rule only allows traffic from the local subnet by default. Widen the rule on the target: Set-NetFirewallRule -Name WINRM-HTTP-In-TCP-PUBLIC -RemoteAddress Any (Windows Server) or WINRM-HTTP-In-TCP (Windows client).
Workgroup connection rejected even with a local admin account The account isn’t the built-in Administrator, and LocalAccountTokenFilterPolicy hasn’t been set on the target. On the target: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "LocalAccountTokenFilterPolicy" -PropertyType DWORD -Value 1 -Force.

Final Thoughts

Windows Admin Center earns its keep by removing friction, not by adding features nobody asked for — one browser tab replaces a pile of MMC snap-ins, an RDP session, and a PowerShell window, all authenticated the same way you already authenticate everywhere else in the domain. The gateway model also means the actual protocol underneath is still WinRM and Remote PowerShell — nothing new to open on a firewall that a competent WinRM deployment wasn’t already handling.

Treat the gateway itself as infrastructure worth protecting: it’s a single point that, if compromised, has administrative reach into every server it manages. Put it behind role-based access control where full local admin isn’t warranted, and prefer Entra ID or AD group-based access over ad hoc local accounts wherever the environment allows it.

Key takeaway: Windows Admin Center is free, agentless, and runs over the WinRM and Remote PowerShell you likely already have working. Most connectivity failures trace back to WinRM, TrustedHosts, or a stale certificate binding — not the gateway itself.
Next in this series

Windows Admin Center leans entirely on WinRM and Remote PowerShell to reach its targets — the mechanics of that transport, and how to secure it, are covered in the PowerShell Remoting and WinRM post linked in the sidebar.