ANAVEM
Languagefr
Windows server administration workspace showing PowerShell and Event Viewer for WinRM troubleshooting
Event ID 11707ErrorMicrosoft-Windows-WinRMWindows

Windows Event ID 11707 – Microsoft-Windows-WinRM: WinRM Service Configuration Error

Event ID 11707 indicates Windows Remote Management (WinRM) service configuration errors, typically occurring during service startup or when authentication settings are misconfigured.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 202612 min read 0
Event ID 11707Microsoft-Windows-WinRM 5 methods 12 min
Event Reference

What This Event Means

Event ID 11707 represents a critical failure in the Windows Remote Management service initialization process. The WinRM service acts as the foundation for PowerShell remoting, Windows Remote Shell (WinRS), and various Microsoft management tools including System Center and Windows Admin Center.

When this event occurs, the WinRM service fails to start properly due to configuration inconsistencies, missing dependencies, or authentication provider errors. The event typically includes detailed error codes that point to specific failure points within the service startup sequence. Common scenarios include corrupted WinRM configuration, missing or expired certificates, disabled authentication providers, or conflicts with third-party security software.

The impact extends beyond basic remote connectivity. Modern Windows environments rely heavily on WinRM for Group Policy application, Windows Update deployment, and security monitoring. When Event ID 11707 appears, these critical functions may fail silently, leading to compliance issues and security gaps.

In Windows Server 2025 and Windows 11 24H2, Microsoft enhanced WinRM's dependency checking and error reporting, making Event ID 11707 more informative but also more frequent during configuration changes. The event now includes additional context about which specific authentication provider or configuration element caused the failure.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • Corrupted WinRM service configuration in the registry
  • Missing or disabled authentication providers (Kerberos, NTLM, Certificate)
  • Expired or invalid SSL certificates for HTTPS listeners
  • Firewall blocking WinRM ports (5985 HTTP, 5986 HTTPS)
  • Service dependency failures (HTTP.sys, RPC Endpoint Mapper)
  • Group Policy conflicts affecting WinRM settings
  • Third-party security software interfering with WinRM operations
  • Insufficient permissions for the WinRM service account
  • Network adapter configuration issues affecting listener binding
  • Windows Update installation requiring WinRM reconfiguration
Resolution Methods

Troubleshooting Steps

01

Check WinRM Service Status and Dependencies

Start by verifying the WinRM service and its dependencies are running correctly.

  1. Open PowerShell as Administrator and check service status:
    Get-Service WinRM, HTTP, RpcEptMapper | Select-Object Name, Status, StartType
  2. If WinRM is stopped, attempt to start it:
    Start-Service WinRM -Verbose
  3. Check for dependency failures:
    Get-WinEvent -FilterHashtable @{LogName='System'; Id=7000,7001,7034} -MaxEvents 20 | Where-Object {$_.Message -like '*WinRM*'}
  4. Navigate to Services.mscWindows Remote Management (WS-Management)Dependencies tab to verify all required services are running
  5. If HTTP service fails, restart it:
    net stop http /y
    net start http
Warning: Restarting the HTTP service affects IIS and other web services on the system.
02

Reset WinRM Configuration to Defaults

Reset WinRM to factory defaults to resolve configuration corruption.

  1. Stop the WinRM service:
    Stop-Service WinRM -Force
  2. Reset WinRM configuration:
    winrm quickconfig -force
    winrm set winrm/config/client '@{TrustedHosts="*"}'
  3. Restore default listeners:
    winrm delete winrm/config/listener?Address=*+Transport=HTTP
    winrm delete winrm/config/listener?Address=*+Transport=HTTPS
    winrm create winrm/config/listener?Address=*+Transport=HTTP
  4. Verify configuration:
    winrm enumerate winrm/config/listener
    winrm get winrm/config
  5. Test WinRM functionality:
    Test-WSMan localhost
Pro tip: Use winrm get winrm/config -format:pretty for human-readable configuration output.
03

Investigate Authentication Provider Issues

Check authentication providers and certificate configurations that may cause WinRM failures.

  1. Examine authentication settings:
    winrm get winrm/config/service/auth
    winrm get winrm/config/client/auth
  2. Check for certificate issues in Event Viewer:Event ViewerApplications and Services LogsMicrosoftWindowsWinRMOperational
  3. Verify Kerberos functionality:
    klist tickets
    klist purge
  4. Test NTLM authentication:
    winrm set winrm/config/service/auth '@{Basic="true";Kerberos="true";NTLM="true"}'
  5. For certificate authentication, check certificate store:
    Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like '*' -and $_.NotAfter -gt (Get-Date)}
  6. Regenerate self-signed certificate if needed:
    New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My
04

Examine Registry Configuration and Group Policy

Investigate registry corruption and Group Policy conflicts affecting WinRM.

  1. Check WinRM registry keys for corruption:
    Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN'
    Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\*'
  2. Examine Group Policy settings:
    gpresult /h GPReport.html
    Get-GPResultantSetOfPolicy -ReportType Html -Path WinRMPolicy.html
  3. Check for conflicting policies in registry:HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM
  4. Reset WinRM registry if corrupted:
    Remove-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN' -Recurse -Force
    Restart-Service WinRM
  5. Force Group Policy refresh:
    gpupdate /force
    Invoke-GPUpdate -Force
  6. Verify policy application:
    Get-WinEvent -FilterHashtable @{LogName='System'; Id=1502,1503} -MaxEvents 10
Warning: Removing WinRM registry keys requires service reconfiguration and may affect domain-joined systems.
05

Advanced Troubleshooting with Network and Firewall Analysis

Perform comprehensive network and firewall analysis for complex WinRM issues.

  1. Check firewall rules for WinRM:
    Get-NetFirewallRule -DisplayGroup 'Windows Remote Management' | Select-Object DisplayName, Enabled, Direction
    Get-NetFirewallPortFilter -Protocol TCP | Where-Object {$_.LocalPort -eq 5985 -or $_.LocalPort -eq 5986}
  2. Test network connectivity:
    Test-NetConnection -ComputerName localhost -Port 5985
    Test-NetConnection -ComputerName localhost -Port 5986
  3. Enable WinRM detailed logging:
    wevtutil set-log Microsoft-Windows-WinRM/Analytic /enabled:true
    wevtutil set-log Microsoft-Windows-WinRM/Debug /enabled:true
  4. Monitor network traffic:
    netstat -an | findstr :5985
    netstat -an | findstr :5986
  5. Check HTTP.sys configuration:
    netsh http show urlacl
    netsh http show sslcert
  6. Analyze detailed event logs:
    Get-WinEvent -LogName Microsoft-Windows-WinRM/Analytic -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
  7. Reset network stack if necessary:
    netsh winsock reset
    netsh int ip reset
Pro tip: Use Wireshark or netsh trace to capture WinRM traffic for deep protocol analysis.

Overview

Event ID 11707 fires when the Windows Remote Management (WinRM) service encounters configuration errors that prevent proper operation. This event typically appears in the System or Applications and Services logs when WinRM cannot initialize due to authentication provider issues, certificate problems, or service dependency failures.

WinRM is critical for PowerShell remoting, Windows Admin Center connections, and enterprise management tools. When this event occurs, remote management capabilities become unavailable, impacting system administration workflows. The error often manifests during system startup, after Windows updates, or following security policy changes.

This event requires immediate attention in enterprise environments where remote management is essential. The underlying causes range from simple service dependency issues to complex authentication provider failures. Understanding the specific error details within the event description is crucial for effective troubleshooting.

Frequently Asked Questions

What does Event ID 11707 mean and why does it occur?+
Event ID 11707 indicates that the Windows Remote Management (WinRM) service failed to start or initialize properly due to configuration errors. This typically occurs when authentication providers are misconfigured, certificates are invalid or expired, service dependencies fail, or the WinRM configuration becomes corrupted. The event prevents PowerShell remoting, Windows Admin Center connections, and other remote management tools from functioning correctly.
How can I quickly determine what's causing my WinRM Event ID 11707 error?+
Start by checking the detailed event description in Event Viewer under System logs or WinRM Operational logs. Look for specific error codes or authentication provider names mentioned. Run 'Test-WSMan localhost' in PowerShell to get immediate feedback about WinRM functionality. Check service dependencies with 'Get-Service WinRM, HTTP, RpcEptMapper' and verify firewall rules with 'Get-NetFirewallRule -DisplayGroup "Windows Remote Management"'. The event description usually contains the specific component that failed.
Can Event ID 11707 affect domain-joined computers differently than workgroup machines?+
Yes, domain-joined computers face additional complexity with Event ID 11707 because they rely on Kerberos authentication and Group Policy settings for WinRM configuration. Domain machines may experience this event due to expired computer certificates, Kerberos ticket issues, or conflicting Group Policy settings. Workgroup machines typically encounter simpler authentication problems related to local certificates or basic authentication settings. Domain environments require checking 'klist tickets' and 'gpresult' output for comprehensive troubleshooting.
Is it safe to reset WinRM configuration to defaults when troubleshooting Event ID 11707?+
Resetting WinRM to defaults using 'winrm quickconfig -force' is generally safe but will remove custom configurations including trusted hosts, custom listeners, and authentication settings. In enterprise environments, document current settings with 'winrm get winrm/config' before resetting. After reset, you'll need to reconfigure any custom authentication methods, HTTPS listeners, or specific security settings required by your organization. Always test the reset on non-production systems first.
How do I prevent Event ID 11707 from recurring after fixing it?+
Prevent recurrence by implementing regular monitoring of WinRM health using 'Test-WSMan' in scheduled tasks, ensuring certificates are renewed before expiration, maintaining consistent Group Policy settings across the domain, and avoiding manual registry modifications to WinRM configuration. Set up proactive monitoring with 'Get-WinEvent -FilterHashtable @{LogName="System"; Id=11707}' in monitoring scripts. Keep Windows updates current as they often include WinRM improvements, and document any custom WinRM configurations for quick restoration if needed.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...