πŸ‡¬πŸ‡§ | πŸ‡©πŸ‡ͺ | πŸ‡«πŸ‡· | πŸ‡ͺπŸ‡Έ | πŸ‡¨πŸ‡³ | πŸ‡ΈπŸ‡¦
We don't have DLL but we have:
Windows File Analyzer & Online Fast Antivirus

A minimalist interface featuring quick search, convenient uploading, and a clean section structure.

πŸ›‘οΈπŸ” Fast verify your file, just drop on this page.
Virus check, hashes, sign verify, architecture, AI info.

Fix for WinRM Error: HTTP Redirect Status Code Not Supported

Description of the Error

This error occurs when a Windows Remote Management (WinRM) client attempts to connect to a remote server or endpoint, but the target server redirects the traffic (usually via an HTTP 301, 302, or 307 status code) to a different URL or HTTPS port. By default, the WinRM protocol treats HTTP redirects as a security risk and explicitly forbids them. Because WinRM refuses to follow the redirect link, the connection fails immediately. This issue frequently happens when administrators configure global IIS redirects on a server, use load balancers that automatically force HTTP traffic to HTTPS, or type the wrong address block into their automation scripts.


Step-by-Step Fixes

Method 1: Bypass Redirects by Connecting Directly to the HTTPS Endpoint

The most secure way to fix this issue is to avoid the redirect entirely by targeting the final HTTPS URL directly.

  1. Open your PowerShell console or management script.
  2. Locate the command causing the error (usually Enter-PSSession, New-PSSession, or Invoke-Command).
  3. Change the connection protocol parameter from HTTP to HTTPS, and explicitly add the correct HTTPS port (default is 5986).
    • Example of a bad command causing a redirect:
      New-PSSession -ComputerName "Server01"
    • Example of the corrected command:
      New-PSSession -ComputerName "Server01" -UseSSL
  4. If you are using a specific Connection URI, ensure it explicitly starts with https:// and includes the correct domain name to match the server's SSL certificate.

Method 2: Modify IIS Redirect Rules on the Target Server

If you control the remote server, a global HTTP redirect rule in Internet Information Services (IIS) is likely breaking WinRM. You must exclude the WinRM virtual directory from the redirect rule.

  1. Log into the remote Windows Server causing the error.
  2. Click the Start Menu, type IIS Manager, and open it.
  3. In the left Connections pane, expand your server node and click on Sites, then select the website hosting your redirect rules (usually the Default Web Site).
  4. In the middle pane, double-click on HTTP Redirect.
  5. Look at your redirect configuration. If it redirects all requests to an HTTPS site, you need to add an exception for the WinRM path.
  6. To do this using web.config configuration rather than the GUI, open the website root folder (usually C:\inetpub\wwwroot) and open the web.config file.
  7. Add a <location> path rule to disable redirecting for the PowerShell or wsman paths:
    <location path="PowerShell">
        <system.webServer>
            <httpRedirect enabled="false" />
        </system.webServer>
    </location>
  8. Save the file and restart IIS by running iisreset in an administrative command prompt.

Method 3: Enable the "Allow Redirection" Flag in PowerShell Sessions

If you must allow redirection because of your network infrastructure or load balancer setup, you can explicitly instruct your WinRM client session option to permit redirects.

  1. Open your PowerShell script or console.
  2. Define a new WinRM session option object and set the AllowRedirection property to true.
    \$SessionOptions = New-PSSessionOption -AllowRedirection
  3. Pass this option object into your connection command using the -SessionOption parameter.
    New-PSSession -ComputerName "Server01" -SessionOption \$SessionOptions
  4. Note: WinRM will only follow the redirect if you are using an explicit Connection URI format or explicit credentials alongside this option.

Method 4: Update SPN and Kerberos Settings

If the redirect error is a misleading symptom of a Kerberos authentication failure routing through a generic DNS alias, setting a Service Principal Name (SPN) can resolve it.

  1. Open a Command Prompt as an Administrator on your Active Directory Domain Controller or management machine.
  2. Check the existing SPNs for your target server by running:
    setspn -L Server01
  3. If the server uses a DNS alias or a custom host name, register the WSMan SPN manually to bind it properly to the computer account:
    setspn -S WSMAN/Server01 Server01
    setspn -S WSMAN/://yourdomain.com Server01
  4. Restart the WinRM service on the remote machine by running Restart-Service WinRM in PowerShell.
ERROR_WSMAN_SERVER_DESTINATION_LOCALHOST | ERROR_WSMAN_UNKNOWN_HTTP_STATUS_RETURNED | ERROR_WSMAN_HTTP_REQUEST_TOO_LARGE_STATUS | ERROR_WSMAN_HTTP_SERVICE_UNAVAILABLE_STATUS | ERROR_WSMAN_HTTP_NOT_FOUND_STATUS

There may be some errors. Learn Microsoft