WinRM not working

Welcome Forums General PowerShell Q&A WinRM not working

Viewing 21 reply threads
  • Author
    Posts
    • #175048
      Participant
      Topics: 21
      Replies: 74
      Points: 354
      Rank: Contributor

      I have a Windows 10 Desktop VM

      PS C:\util> invoke-command -ComputerName tgkw004 -ScriptBlock {get-service nscp}
      [tgkw004] Connecting to remote server tgkw004 failed with the following error message : WinRM cannot complete the
      operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and
      that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM
      firewall exception for public profiles limits access to remote computers within the same local subnet. For more
      information, see the about_Remote_Troubleshooting Help topic.
          + CategoryInfo          : OpenError: (tgkw004:String) [], PSRemotingTransportException
          + FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionStateBroken
      
      
      From the workstation
      
      I run this
      
      PS C:\util> winrm quickconfig
      WinRM service is already running on this machine.
      WSManFault
          Message
              ProviderFault
                  WSManFault
                      Message = WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.
      
      Error number:  -2144108183 0x80338169
      WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.
      PS C:\util> Enable-psremoting
      WinRM is already set up to receive requests on this computer.
      Set-WSManQuickConfig : WinRM firewall exception will not work since
      one of the network connection types on this machine is set to Public. Change the network connection type to either
      Domain or Private and try again. 
      At line:116 char:17
      +                 Set-WSManQuickConfig -force
      +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
          + CategoryInfo          : InvalidOperation: (:) [Set-WSManQuickConfig], InvalidOperationException
          + FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.SetWSManQuickConfigCommand
      
      PS C:\util>
      
      
      PS C:\util> $PSVersionTable
      
      Name                           Value
      ----                           -----
      PSVersion                      5.1.16299.1146
      PSEdition                      Desktop
      PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
      BuildVersion                   10.0.16299.1146
      CLRVersion                     4.0.30319.42000
      WSManStackVersion              3.0
      PSRemotingProtocolVersion      2.3
      SerializationVersion           1.1.0.1
      

      I tried upgrading to powershell 6.2.2 but that did not make any difference

      Any ideas?

      Thank you

      Tom

    • #175057
      Participant
      Topics: 1
      Replies: 1635
      Points: 3,089
      Helping Hand
      Rank: Community Hero

      Did you actually read the messages? The solution is there ...

      Message = WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.

    • #175066
      Participant
      Topics: 21
      Replies: 74
      Points: 354
      Rank: Contributor

      Yes I saw that message

      But it does not inform you of which firewall rule to change

      Any ideas?

    • #175117
      Participant
      Topics: 0
      Replies: 115
      Points: 433
      Helping Hand
      Rank: Contributor

      Tom,

      This is not a firewall acl issue, but the fact you are using the Public firewall and not for a Domain or the Private firewall. The answer is in the error message as Olaf has already stated. You will need to enable to Domain or Public Firewall as well or have all three disabled. Disabling the firewall in Windows is not recommended unless you have a 3rd party firewall to replace it.

    • #175123
      Participant
      Topics: 21
      Replies: 74
      Points: 354
      Rank: Contributor

      Jason,

      I only use Microsoft Firewall no third party.

      I tried disabling the firewall that made no difference.

      It also does not tell you which rule is the issue

    • #175138
      Participant
      Topics: 1
      Replies: 1635
      Points: 3,089
      Helping Hand
      Rank: Community Hero

      You set up your Microsoft Firewall included in your Windows operating system with one of 3 network types – Private, Domain or Public. In one of them – Public – the Firewall exception does not work as you wich it to work. So you have to use either the Domain profile – what's recomended if your computer is a domain joined computer – or the Privat profile.

    • #175144
      Participant
      Topics: 21
      Replies: 74
      Points: 354
      Rank: Contributor

      All my computers/servers are domain joined.

      Is there a power shell command to list to rules example?

    • #175159
      Participant
      Topics: 1
      Replies: 1635
      Points: 3,089
      Helping Hand
      Rank: Community Hero

      With

      Get-NetFirewallProfile

      you can see an overview over the existing firewall profiles and with

      (Get-NetConnectionProfile).NetworkCategory

      you can see the active profile.

    • #175162
      Participant
      Topics: 10
      Replies: 117
      Points: 457
      Helping Hand
      Rank: Contributor

      I've run into a similar issue in the past that was caused by multiple network adapters being present on a domain-joined computer, which one was set to DomainAuthenticated and the other, Public. Because WinRM applies to all adapters by default, if just one is Public, you'll get an error enabling WinRM/PSRemoting.

      Get-NetConnectionProfile and Set-NetConnectionProfile are needed as stated in this article:

      https://www.paulligocki.com/how-to-setup-winrm-in-a-workgroup-non-domain-environment

    • #175165
      Participant
      Topics: 21
      Replies: 74
      Points: 354
      Rank: Contributor

      PS C:\util> Get-NetFirewallProfile

      Name : Domain
      Enabled : False
      DefaultInboundAction : NotConfigured
      DefaultOutboundAction : NotConfigured
      AllowInboundRules : NotConfigured
      AllowLocalFirewallRules : NotConfigured
      AllowLocalIPsecRules : NotConfigured
      AllowUserApps : NotConfigured
      AllowUserPorts : NotConfigured
      AllowUnicastResponseToMulticast : NotConfigured
      NotifyOnListen : True
      EnableStealthModeForIPsec : NotConfigured
      LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log
      LogMaxSizeKilobytes : 4096
      LogAllowed : False
      LogBlocked : False
      LogIgnored : NotConfigured
      DisabledInterfaceAliases : {NotConfigured}

      Name : Private
      Enabled : False
      DefaultInboundAction : NotConfigured
      DefaultOutboundAction : NotConfigured
      AllowInboundRules : NotConfigured
      AllowLocalFirewallRules : NotConfigured
      AllowLocalIPsecRules : NotConfigured
      AllowUserApps : NotConfigured
      AllowUserPorts : NotConfigured
      AllowUnicastResponseToMulticast : NotConfigured
      NotifyOnListen : True
      EnableStealthModeForIPsec : NotConfigured
      LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log
      LogMaxSizeKilobytes : 4096
      LogAllowed : False
      LogBlocked : False
      LogIgnored : NotConfigured
      DisabledInterfaceAliases : {NotConfigured}

      Name : Public
      Enabled : False
      DefaultInboundAction : NotConfigured
      DefaultOutboundAction : NotConfigured
      AllowInboundRules : NotConfigured
      AllowLocalFirewallRules : NotConfigured
      AllowLocalIPsecRules : NotConfigured
      AllowUserApps : NotConfigured
      AllowUserPorts : NotConfigured
      AllowUnicastResponseToMulticast : NotConfigured
      NotifyOnListen : True
      EnableStealthModeForIPsec : NotConfigured
      LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log
      LogMaxSizeKilobytes : 4096
      LogAllowed : False
      LogBlocked : False
      LogIgnored : NotConfigured
      DisabledInterfaceAliases : {NotConfigured}

      PS C:\util> (Get-NetConnectionProfile).NetworkCategory
      Public
      PS C:\util>

    • #175168
      Participant
      Topics: 21
      Replies: 74
      Points: 354
      Rank: Contributor

      PS C:\util> (Get-NetConnectionProfile).NetworkCategory
      Public
      PS C:\util> Get-NetConnectionProfile | select interfacealias,networkCategory

      interfacealias NetworkCategory
      ————– —————
      Primary Public

      PS C:\util> Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private
      PS C:\util> Get-NetConnectionProfile | select interfacealias,networkCategory

      interfacealias NetworkCategory
      ————– —————
      Primary Private

      PS C:\util> Enable-PSRemoting -force
      WinRM is already set up to receive requests on this computer.
      WinRM is already set up for remote management on this computer.
      PS C:\util> winrm quickconfig
      WinRM service is already running on this machine.
      WinRM is already set up for remote management on this computer.
      PS C:\util> Enable-PSRemoting -force
      WinRM is already set up to receive requests on this computer.
      WinRM is already set up for remote management on this computer.
      PS C:\util>

      Do I need to restart the computer?

      After making the change to private

      I still get the

      PS C:\util> invoke-command -ComputerName tgkw004 -ScriptBlock {get-service nscp}
      [tgkw004] Connecting to remote server tgkw004 failed with the following error message : WinRM cannot complete the
      operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and
      that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM
      firewall exception for public profiles limits access to remote computers within the same local subnet. For more
      information, see the about_Remote_Troubleshooting Help topic.
      + CategoryInfo : OpenError: (tgkw004:String) [], PSRemotingTransportException
      + FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionStateBroken
      PS C:\util>

    • #175303
      Senior Moderator
      Topics: 8
      Replies: 1141
      Points: 3,927
      Helping Hand
      Rank: Community Hero

      This error can come because of many reasons. Did you read about_Remote_Troubleshooting doc ? you can read by executing Get-Help about_Remote_Troubleshooting. Additional to it, check the state of Windows Firewall service, it should be running as well.

    • #175390
      MvW
      Participant
      Topics: 7
      Replies: 10
      Points: 73
      Rank: Member

      I use an batch file to enable WinRM remote

      PSremote.cmd

      psexec -s \\%1 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP" -RemoteAddress Any" -Profile Domain
      psexec -s \\%1 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "Enable-PSRemoting -SkipNetworkProfileCheck -Force"

    • #175705
      Participant
      Topics: 12
      Replies: 232
      Points: 466
      Helping Hand
      Rank: Contributor

      Maybe start with the basics, checking that you can actually reach the machine/port from your machine.

      Test-NetConnection tgkw004 -Port 5985
      Test-NetConnection tgkw004 -Port 5986
      

      First is the default HTTP port, second is the default HTTPS port.
      If neither of those are accessible then it's most likely a firewall issue, if the TcpTestSucceeded is "true" then it's a WinRM configuration issue.

    • #175777
      Participant
      Topics: 0
      Replies: 115
      Points: 433
      Helping Hand
      Rank: Contributor

      Tom,

      Are you using Wifi or Ethernet? If you are on Wifi it could be that your Security Admins have configured wifi to be classified as Public instead of Domain Authenticated via GPO. Try using Ethernet instead, you want to see DomainAuthenticated for NetworkCategory if your computer is connnected to a domain. I would also ask why are you using invoke-command for Get-Service when you can just provide the computername?

      Get-Service nscp -ComputerName tgkw004
    • #176056
      Participant
      Topics: 0
      Replies: 45
      Points: 243
      Helping Hand
      Rank: Participant

      Can you check if the Server:tgkw004 has WinRM service is in start mode ?

    • #176098
      js
      Participant
      Topics: 27
      Replies: 716
      Points: 1,881
      Helping Hand
      Rank: Community Hero

      Here's my script to enable powershell remote in windows 10. It's a PITA to get right. You don't have to be on a domain. Don't forget to set trustedhosts on the other end.

      # enable remote powershell
      
      #on target:
      enable-psremoting -force -skipnetworkprofilecheck
      $result = $?
      
      # (not firewall control panel displayname)
      # powershell 4 in win7 doesn't have it
      Set-NetFirewallRule -Name WINRM-HTTP-In-TCP -RemoteAddress 192.168.1.1 # DisplayName : Windows Remote Management (HTTP-In)
      Set-NetFirewallRule -Name WINRM-HTTP-In-TCP-NoScope -Enabled True -RemoteAddress 192.168.1.1 # domain,private profiles, DisplayName : Windows Remote Management (HTTP-In)
      
      #(to disable:  disable-psremoting -force)
      
      if ( -not $result ) { exit 1 }
      
      
      #on source or client:
      #start-service winrm
      #Set-Item WSMan:\localhost\Client\TrustedHosts -Value 192.168.1.2
      #$Cred = Get-Credential
      
      # don't need cred after this
      #$S = New-PSSession -ComputerName 172.17.64.195 -Credential $Cred
      #remove-session $s # ?
      
      #Invoke-Command -ComputerName 172.17.64.195 -ScriptBlock { Get-ChildItem C:\ } -credential $cred
      #Enter-PSSession -ComputerName 172.17.64.195 -Credential $cred
      
      #copy-item "c:\users\admin\desktop\there" "c:\users\admin\desktop" -fromsession $s
      #copy-item "c:\users\admin\desktop\there" "c:\users\admin\desktop" -tosession $s
      
    • #176431
      Participant
      Topics: 21
      Replies: 74
      Points: 354
      Rank: Contributor

      First Thanks to all the suggestions they lead me to the real problem.

      After trying this command I found the problem
      Test-NetConnection tgkw004 -Port 5985

      Not WINRM not FIREWALL it was DNS The computer registered with DNS the wrong ip address

      I had to disjoin the computer from the domain and join the computer back then the computer registered in DNS and winrm worked

      Thanks again This is now resolved.

    • #176581
      Participant
      Topics: 10
      Replies: 117
      Points: 457
      Helping Hand
      Rank: Contributor

      If you hadn't tried it, you could have used ipconfig /registerdns to initialize/update name registration with DNS (no reboot required either) and avoid the domain rejoin.

    • #177082
      Participant
      Topics: 4
      Replies: 11
      Points: 102
      Rank: Participant

      hi all,

      first thing: thank you all for the infos that helped me figure out how to configure winRM. Now everything seems to work just fine. Here's my concern: is it norma that whenever i issue a command (like get-process -computername MyRemoteComputer) i have to wait 10-15 seconds before i can see any output on screen?

      I am studing powershell in a LAN enviromentĀ  with a laptop connected via wireless (the client) and a desktop connected via ethernet (the remote host).

      Is there anything i can check to get faster response from the remote computer?

      Thank you in advance

    • #184664
      Participant
      Topics: 10
      Replies: 117
      Points: 457
      Helping Hand
      Rank: Contributor

      Response time is relative and there are a number of factors involved when it comes to performance. Some things to consider:

      1. Response time is dictated by what resources are available on both systems, especially the system where PowerShell is doing all the processing.
      2. You're performing remote commands over a wireless connection which is subject to low bandwidth, interference or distance-related issues, and it's just not as reliable as a good ol' wire.
      3. Depending on the commands you use, some do a lot more than others and can take longer for output to come back.

        For instance, if you ran a simple command against a remote system, like Get-Service -ComputerName server -Name Netlogon, it shouldn't take too long compared to if you ran Invoke-Command -ComputerName server { Get-ComputerInfo } or an unfiltered Get-EventLog/Get-WinEvent.

      For starters, if it's possible, get the laptop on a wired connection.

    • #185318
      Participant
      Topics: 4
      Replies: 11
      Points: 102
      Rank: Participant

      Thanks Aaron for the response,
      i totally agree with you regardind the wire powa, but i just figured out what was the problem: firewall rules
      i had to enable some of those on the laptop firewall, and after that i now have a 'normally delayed' response (due to wireless connection)
      I mean that now i issue a command and in a couple of second i have response from the server, which seems to be normal to me (now)

      The firewall rules were mainly:
      – File and Printer sharing
      – Network Discovery
      – DCOM
      – Remote Service Management (RPC)
      – Other that probably were not part of this problem

      Now almost all works fine, exept a strange error that i discussed in another post of mine, regading the use of Get-WmiObject with the -AsJob parameter
      but since i can bypass this strange behavior with
      – Invoke-Command -AsJob or
      – Start-Job
      I just stopped struggling to solve it

Viewing 21 reply threads
  • You must be logged in to reply to this topic.