When attempting to add a new Windows Server 2012 R2 member server (srv003) to Server Manager from a domain controller (srv001), you might encounter the perplexing Kerberos error 0x80090322. This occurs despite successful domain join and functional PowerShell remoting using Kerberos authentication.

The error suggests a breakdown in Kerberos authentication during Server Manager's metadata retrieval process. Key observations:

• Remote PowerShell sessions work flawlessly with Kerberos
• The server has all expected SPNs registered
• Both machines reside in the same domain
• Domain admin credentials are being used

Let's examine potential culprits through these diagnostic steps:

# Verify SPN registration for the target server
setspn -L srv003

# Check Kerberos ticket availability
klist

# Test WinRM connectivity
Test-WSMan -ComputerName srv003

While the server shows correct SPNs, Server Manager might be attempting connection through alternate names. Try adding these variants:

setspn -S HOST/srv003 srv003
setspn -S HOST/srv003.rwwilden01.local srv003
setspn -S WSMAN/srv003 srv003
setspn -S WSMAN/srv003.rwwilden01.local srv003

Verify the WinRM service configuration on both machines:

# On both srv001 and srv003
winrm get winrm/config

# Ensure proper listener configuration
winrm enumerate winrm/config/listener

If SPN adjustments don't resolve the issue, consider these methods:

# Option 1: Add to TrustedHosts (temporary measure)
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "srv003" -Force

# Option 2: Force PowerShell-based management
$server = Get-Server -Name "srv003"
$server | Add-ServerManagerUser -Domain "rwwilden01" -User "Administrator"

Examine these critical logs for deeper insights:

• System logs on both client and server
• Security logs for authentication failures
• Microsoft-Windows-WinRM/Operational logs

For persistent cases, enable detailed Kerberos logging:

# Enable Kerberos logging
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" 
    -Name "LogLevel" -Value 1 -PropertyType DWORD -Force

Remember to restart the server after making registry changes.

After implementing fixes, validate the configuration:

Test-WSMan -ComputerName srv003 -Authentication Kerberos
Get-Server -Name "srv003" | Test-ServerConnection

---

When encountering Kerberos error 0x80090322 during server registration in Server Manager while PSRemoting works perfectly, we're typically dealing with subtle authentication configuration mismatches rather than complete Kerberos breakdown. Let me share my investigation process and solution.

Before diving deep, we should confirm basic Kerberos operations:

# Check ticket-granting ticket status
klist

# Test explicit Kerberos authentication
Test-WSMan -ComputerName srv003 -Authentication Kerberos

# Verify SPN registration
setspn -L srv003

The fact that PSRemoting works confirms that fundamental Kerberos authentication is functional. This narrows our focus to Server Manager-specific requirements.

Server Manager has stricter requirements than PSRemoting regarding:

• Delegation constraints
• SPN registration completeness
• Time synchronization tolerance
• DNS resolution consistency

Kerberos is extremely time-sensitive. Run these checks on both servers:

# Check time difference between servers
Test-Connection -ComputerName srv003 -Count 1 | 
    Select-Object @{n='SourceTime';e={Get-Date}}, 
                  @{n='DestinationTime';e={$_.ReplyTime}}

# Validate time sources
w32tm /query /status

Differences >5 minutes will cause authentication failures.

Server Manager performs reverse lookups during registration. Verify:

# Check forward and reverse resolution
Resolve-DnsName srv003.rwwilden01.local
Resolve-DnsName -Type PTR [IP_ADDRESS]

# Confirm SRV records
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.rwwilden01.local

While basic SPNs exist, Server Manager may require additional registrations:

# Add missing SPNs that Server Manager checks
setspn -S HTTP/srv003.rwwilden01.local srv003
setspn -S HTTP/srv003 srv003
setspn -S MSSMSrv/srv003.rwwilden01.local srv003

Server Manager operations often require constrained delegation:

# Check current delegation settings
Get-ADComputer srv003 -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object -ExpandProperty PrincipalsAllowedToDelegateToAccount

# Configure constrained delegation (if needed)
Set-ADComputer srv003 -Add @{
    'msDS-AllowedToDelegateTo' = @(
        'HTTP/srv003',
        'HTTP/srv003.rwwilden01.local',
        'WSMAN/srv003',
        'WSMAN/srv003.rwwilden01.local'
    )
}

Server Manager uses WinRM with specific requirements:

# Verify WinRM listeners
Get-WSManInstance -ResourceURI winrm/config/listener

# Configure for Server Manager compatibility
winrm set winrm/config/client '@{TrustedHosts="srv003"}'
winrm set winrm/config/service/auth '@{Kerberos="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'

Server Manager uses additional ports beyond standard WinRM:

# Check required firewall rules
Get-NetFirewallRule -DisplayName "Windows Remote Management*" | 
    Select-Object Name, DisplayName, Enabled

# Example of adding required rules
New-NetFirewallRule -DisplayName "Server Manager Additional Ports" -Direction Inbound -Protocol TCP -LocalPort 5985,9382 -Action Allow

After implementing these changes, perform comprehensive validation:

# Test Server Manager prerequisites
Test-NetConnection -ComputerName srv003 -Port 5985
Test-WSMan -ComputerName srv003 -Authentication Kerberos

# Clear cached credentials
klist purge

# Attempt server registration again
Add-Computer -Server srv003 -Credential (Get-Credential)

These steps should resolve the 0x80090322 error while maintaining security best practices. The key is understanding Server Manager's additional requirements beyond basic Kerberos authentication.