Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

How to install Windows Admin Center in a Windows Failover Cluster

  • September 11, 2019
  • 9 min read
IT and Virtualization Consultant. Dmitriy is specializing in Microsoft technologies, with a focus on storage, networking, and IT infrastructure architecture.
IT and Virtualization Consultant. Dmitriy is specializing in Microsoft technologies, with a focus on storage, networking, and IT infrastructure architecture.

 

INTRODUCTION

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 Admin Center

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:

Here is how you can install WAC with the existing certificate

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

Here is the screenshot from Failover Cluster Manager

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

clientAccessPoint

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

If everything has run smoothly, you’ll be able to enter 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).

 WAC client (in my case it’s called CL-WIN19-WAC)

Go to Security -> Advanced.

Security -> Advanced

In the Advanced Security Settings for Computers window press Add.

Advanced Security Settings for Computers window press Add

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

 

Permission Entry for Computers window press Select a principal

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

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

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

Permissions list, check the Create Computer objects checkbox

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

See if you can access WAC now.

See if you can access WAC now

Found Dmitriy’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!