How to fix "The WinRM client cannot process the request because it received an HTML error packet."

Description

This error occurs when you try to establish a remote management session using Windows Remote Management (WinRM) or PowerShell Remoting. It indicates that the WinRM client initiated a connection expecting a valid XML-formatted WS-Management response, but the target server, an intermediate proxy, or a local security application returned a standard web page (HTML) instead.

This usually happens because the request was intercepted, redirected, or blocked. Common root causes include:

• Proxy Server Interference: A local proxy configuration is routing the internal WinRM traffic out to the internet or a proxy server that cannot authenticate it.
• URL/Port Conflicts: Another web service on the target machine (like IIS, Skype, or Apache) is using the same port configured for WinRM (default is 5985 for HTTP and 5986 for HTTPS).
• WinRM Service State: The WinRM service is either stopped, misconfigured, or has corrupted listeners.
• Network Security Software: Firewalls, antivirus programs, or VPN clients are blocking or inspecting the traffic, disrupting the communication protocol.

Step-by-Step Fixes

Follow these solutions in order until the issue is resolved. You must run PowerShell or the Command Prompt as an Administrator for all steps.

Step 1: Bypass the Proxy for Local Traffic

The most common cause is your system attempting to send WinRM traffic through a proxy server.

1. Open PowerShell as an Administrator.
2. Check your current WinRM proxy setting by running:

   netsh winhttp show proxy

3. If a proxy server is listed, check if it bypasses local addresses. If it does not, or if you want to test without it, temporarily reset the proxy settings by running:

   netsh winhttp reset proxy

4. If you are using internet options proxies, open the Run dialog (Win + R), type inetcpl.cpl, and press Enter.
5. Go to the Connections tab and click on LAN settings.
6. Check the box that says "Bypass proxy server for local addresses".
7. Click OK, then click Apply.

Step 2: Restart and Quick-Configure the WinRM Service

Refreshing the service files and checking the listeners can fix misconfigurations.

1. Open PowerShell as an Administrator.
2. Restart the WinRM service to clear temporary glitches:

   Restart-Service WinRM

3. Run the automated configuration tool to repair listeners and firewall rules:

   winrm quickconfig

4. Press Y (Yes) if prompted to make changes or create listeners.

Step 3: Check for Port Conflicts

If another application uses port 5985, WinRM will fail and return HTML data from that conflicting application.

1. Open Command Prompt or PowerShell as an Administrator.
2. Check which process is listening on the default WinRM HTTP port (5985):

   netstat -ano | findstr :5985

3. Note the Process ID (PID), which is the number at the far right of the output line.
4. Check what application owns that PID by running (replace YOUR PID with the actual number):

   tasklist /fi "pid eq YOUR PID"

5. If the application is something other than System or wsmprovhost.exe, you must stop that conflicting application or change its port configuration.

Step 4: Add the Destination to the TrustedHosts List

If you are connecting to a remote machine outside your active directory domain, your client machine will reject the connection unless the target is explicitly trusted.

1. Open PowerShell as an Administrator.
2. Run the following command to trust the specific target computer (replace IP OR NAME with the remote machine's IP address or hostname):

   Set-Item WSMan:\localhost\Client\TrustedHosts -Value "IP OR NAME" -Force

   Note: You can use `` as the value to trust all hosts for testing purposes, though this is not recommended for permanent production use due to security risks.*

3. Restart the WinRM service again to apply the changes:

   Restart-Service WinRM

Step 5: Verify the SPN (Service Principal Name) Settings

If you are in a Domain environment, Kerberos authentication might fail if the SPN is missing or duplicated.

1. Open Command Prompt as an Administrator.
2. Test if the Service Principal Name is registered correctly for the target computer by running (replace TARGET COMPUTER NAME with the name of the server you are trying to reach):

   setspn -L TARGET COMPUTER NAME

3. Look for entries starting with WSMAN/. If they are missing, you may need to register them or contact your network domain administrator to sync the Active Directory objects.