Windows Admin Center - Couldn't configure PowerShell authentication error

Because WAC manages Hyper-V through PowerShell over WinRM, and uses CredSSP in some scenarios, a failure to configure either CredSSP or local PowerShell can produce exactly this type of message. Microsoft documents that WAC uses standard PowerShell/WMI over WinRM to managed servers, and that CredSSP is required in some cases and is configured automatically by WAC when needed.

Given that your hosts were disconnected from the network for 56 days, I would start with the basics below.

1. Check Windows Admin Center version first

There are known CredSSP-related issues in older WAC builds, and Microsoft recommends updating WAC if you hit CredSSP problems. In the known issues page, Microsoft specifically notes CredSSP issues and says to update Windows Admin Center to a newer release in affected cases.

2. Verify WinRM / PowerShell remoting on both Hyper-V hosts

On each Hyper-V node, run:

winrm quickconfig

Enable-PSRemoting -Force

Test-WSMan

Also verify the WinRM service is running:

Get-Service WinRM

If WinRM is unhealthy, WAC will fail when trying to open VM settings because that blade depends on remote PowerShell. Microsoft’s Hyper-V remote management guidance also calls out PS Remoting and CredSSP as required pieces for remote management scenarios.

3. Check CredSSP configuration

Even in a domain environment, CredSSP can get into a bad state after connectivity interruptions, policy changes, or patching drift.

On the WAC gateway machine and the Hyper-V hosts, check:

Get-WSManCredSSP

If needed, re-enable it.

On the server side (each Hyper-V host):

Enable-WSManCredSSP -Role Server -Force

If your WAC deployment is running in desktop mode or using delegated credentials, also confirm the affected admin account is allowed to use the WAC CredSSP endpoint. Microsoft notes that affected users may need to be added to the Windows Admin Center CredSSP Administrators group, then sign out and back in.

4. Re-test with “Manage as”

In WAC, reconnect to the cluster/hosts and explicitly use Manage as with a known domain admin or local admin on the Hyper-V hosts. Microsoft notes that gateway access alone is not enough; the connecting identity must also have administrative access on the target servers.

5. Check Kerberos / time / secure channel health

Since the hosts were offline for nearly two months, I would also verify:

w32tm /query /status

Test-ComputerSecureChannel

klist purge

and then reboot the nodes if needed.

Even if “domain health is fine,” an individual host can still have a stale Kerberos ticket cache, time skew, or secure-channel issue after a long isolation period. That is my inference from your timeline rather than a Microsoft-specific statement.

6. Look at WAC logs and browser session

Microsoft’s WAC troubleshooting guidance recommends checking known issues first and then general troubleshooting steps. I would also try:

signing out of WAC and back in

reloading the browser

removing and re-adding the cluster connection

checking the WAC gateway event logs / extension logs for the exact failing command

My likely root-cause shortlist

Based on your symptoms, I would suspect one of these first:

Older WAC build with a CredSSP-related bug

Broken WinRM / PS remoting on one or both Hyper-V nodes

CredSSP endpoint permission issue

Kerberos / time / secure channel drift after the 56-day disconnection

If Hyper-V and cluster operations otherwise work, this is probably a management-plane authentication/remoting issue rather than a VM or cluster resource issue.