When attempting to establish PowerShell remoting between a Windows 8 client and a non-domain joined Windows Server 2008 R2 (same subnet), we encounter authentication failures despite having valid credentials. The key error message indicates:

The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, 
or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination 
machine must be added to the TrustedHosts configuration setting.

In a workgroup environment (non-domain), PowerShell remoting defaults to NTLM authentication rather than Kerberos. This requires either:

• HTTPS transport with valid certificates
• Explicit TrustedHosts configuration

Here's the proper sequence to establish the connection:

# On the TARGET SERVER (Win2008R2):
Enable-PSRemoting -Force
Set-Item WSMan:\localhost\Service\AllowUnencrypted -Value $true
Set-Item WSMan:\localhost\Service\Auth\Basic -Value $true

# On the CLIENT MACHINE (Win8):
winrm set winrm/config/client '@{TrustedHosts="10.10.106.2"}'
$cred = Get-Credential -UserName "administrator" -Message "Enter password"
Enter-PSSession -ComputerName 10.10.106.2 -Credential $cred -Authentication Negotiate

For more secure communication, configure HTTPS:

# On the server:
$cert = New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My
New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $cert.Thumbprint -Force

# On the client:
$sessOption = New-PSSessionOption -SkipCACheck -SkipCNCheck
New-PSSession -ComputerName 10.10.106.2 -Credential $cred -UseSSL -SessionOption $sessOption

• Verify WinRM service is running: Get-Service WinRM
• Check firewall rules: netsh advfirewall firewall show rule name=all | find "WinRM"
• Test basic connectivity: Test-WSMan -ComputerName 10.10.106.2

The Get-WinEvent cmdlet uses different protocols (DCOM/RPC) rather than WinRM, which explains why it succeeds while PSSession fails. This inconsistency actually helps confirm the issue is specifically with WinRM configuration.

When attempting to establish a PowerShell remote session between a Windows 8 client and a non-domain joined Windows Server 2008 R2 machine on the same subnet, we encounter authentication and transport layer issues. The key symptoms include:

• WinRM connectivity failures with Kerberos authentication errors
• TrustedHosts configuration challenges
• HTTPS/SSL transport requirement for non-domain scenarios

Before diving into solutions, let's verify these fundamental requirements:

# On the TARGET SERVER (2008 R2):
# 1. Basic WinRM setup
winrm quickconfig -force

# 2. Enable PowerShell remoting
Enable-PSRemoting -Force

# 3. Configure firewall rules
netsh advfirewall firewall add rule name="WinRM HTTPS" dir=in action=allow protocol=TCP localport=5986

1. TrustedHosts Configuration (Client Side)

The proper way to configure TrustedHosts when direct WinRM commands fail:

# Alternative method when winrm set fails
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.10.106.2" -Force
Restart-Service WinRM

# Verify configuration
Get-Item WSMan:\localhost\Client\TrustedHosts

2. HTTPS Listener Setup (Server Side)

For non-domain environments, HTTPS is mandatory. Here's how to create a self-signed certificate:

# Generate certificate
$cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName "server.domain.local"

# Create HTTPS listener
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="server.domain.local";CertificateThumbprint=$cert.Thumbprint}

# Verify listener
winrm enumerate winrm/config/Listener

3. Establishing the Session

With HTTPS configured, the connection should succeed:

$cred = Get-Credential -UserName "Administrator" -Message "Enter password"
$sessionParams = @{
    ComputerName = "10.10.106.2"
    Credential = $cred
    UseSSL = $true
    SessionOption = New-PSSessionOption -SkipCACheck -SkipCNCheck
}

$session = New-PSSession @sessionParams
Invoke-Command -Session $session -ScriptBlock { hostname }

WinRM Service Verification

Check the WinRM service state and configuration:

# Check service status
Get-Service WinRM

# Verify WinRM configuration
winrm get winrm/config

# Test basic connectivity
Test-WSMan -ComputerName 10.10.106.2 -UseSSL

Firewall Considerations

Essential firewall ports for different scenarios:

For production environments, consider these additional steps:

# Configure WinRM for persistent operation
Set-Service WinRM -StartupType Automatic
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "LocalAccountTokenFilterPolicy" -Value 1 -Type DWord

# Enable CredSSP if needed (for multi-hop scenarios)
Enable-WSManCredSSP -Role Client -DelegateComputer "10.10.106.2"