Windows Admin Center (WAC) is a locally-deployed, browser-based management tool that provides you with the full control over your Windows Server environment. The nice thing is, it does not push you to Azure or any other cloud, so it works for you even if you do not feel that enthusiastic about public cloud.

What is WAC?

Let’s take a closer look at solutions allowing us to manage Hyper-V environments which existed before Windows Admin Center. Previously, starting with Windows Server 2003, we used Windows Server Manager to perform everyday tasks. It was not a truly cross-platform solution though. While VMware vCenter Server Appliance, starting with version 5, enabled us to connect remotely to an ESXi host even from a smartphone, Windows Server Manager did not provide this capability. Windows Server 2019 brought WAC – a full-blown browser-based solution which complements Server Manager (it was never meant to replace it) – allowing us to RDP to a remote host from any platform. Works both for servers and workstations.

Windows Server Manager

Windows Admin Center is a set of tools which is installed locally and provides great management capabilities. WAC enables you to manage any Windows host; no matter on which device it is running or whether it is running in public cloud at all. WAC also does not care on which OS version you open Management Console.

Management Console

How to install WAC

Now, as you know what WAC is, let’s jump to its installation in a failover cluster. I won’t highlight on boring stuff like OS installation, domain configuration, and so on. I will focus solely on WAC deployment in a failover cluster.

I will build an active-passive solution, meaning that only one instance is always up and running. Another instance will “wake up” if something happens to the active site, allowing for non-interruptive management experience.

For this article, I used the same setup as Bohmer while discussing how to set up a Windows Failover Cluster for a home lab. It is a 2-node fault-tolerant cluster (you can actually use more nodes). Its Cluster Shared Volume (CSV) is over 10GB. See, everything should work fine today’s setup.

WAC deployment process is pretty straightforward. Download the installer, download the archive with the script for WAC installation, and save them on the target server. It also is good to have a signed *.pfx certificate with a password. You do not need to install the certificate on cluster nodes as the script does that for you. Without that certificate, there will be a self-signed certificate generated which expires in 60 days.

Start the script with the following parameters:

  1. clusterStorage – the local path to the Cluster Shared Volume for WAC.
  2. clientAccessPoint – the name which is used as a subdomain for accessing WAC. If you start the script using the [clientAccessPoint contoso WAC] parameter, you will access WAC at https://contosoWAC.<Domain Name>.<TLD>
  3. staticAddress assigns one (or many) static IPs for accessing cluster service. It is an optional parameter.
  4. msiPath determines the path to the WAC msi package.
  5. certPath indicates the path to the .pfx certificate. It is an optional parameter.
  6. certPassword sets password for the .pfx certificate. It is an optional parameter.
  7. generateSslCert generates a self-signed certificate. It is an optional parameter.
  8. portNumber assigns a port for accessing WAC. If you do not enter this parameter, the service will be assigned to the 443 (HTTPS) port. If you want to use a different port, just enter its number. After you specify the port, WAC will be available at https: // <clientAccessPoint>: <port>.

Here is how you can install WAC with the existing certificate:

Here is how you can install WAC with a self-signed certificate:

To give you a clue, here is the command which I used to install WAC in my cluster:

Install WAС

Installation has run smoothly for me. Here is the screenshot from Failover Cluster Manager which proves that the role has been successfully installed:

Failover Cluster Manager

Open the web browser, type the domain name which you have specified as clientAccessPoint, and log in.

clientAccessPoint log in

If everything has run smoothly, you’ll be able to enter WAC.

Welcome to WAC

“What could go wrong?”

If something is wrong, say, you cannot enter WAC despite the fully-functioning role or there is something wrong with the role itself, you should provide WAC client with entry permissions. Here is how you can do that.

Open Active Directory Users and Computers. In the View tab, press Advanced Features.

Active Directory Users and Computers

See properties of the WAC client (in my case it’s called CL-WIN19-WAC).

See properties of the WAC client

Go to Security -> Advanced.

Go to Security -> Advanced

In the Advanced Security Settings for Computers window press Add.

Advanced Security Settings for Computers

In the Permission Entry for Computers window press Select a principal. Press Object types… afterward, check Computers, and hit OK.

Permission Entry for Computers

Type the object name to select (in my setup it was CL-WIN19-WAC).

Type the object name

In the Permissions list, check the Create Computer objects checkbox.

Create Computer objects

Finally, press OK in all windows to have the settings applied.

See if you can access WAC now.

WAC access