psRemote Fails Based on Source Computer Config

Welcome Forums General PowerShell Q&A psRemote Fails Based on Source Computer Config

Viewing 4 reply threads
  • Author
    Posts
    • #252725
      Participant
      Topics: 1
      Replies: 2
      Points: 19
      Rank: Member
      I am unable to create a New-psSession FROM a group of computers.  Attempting to do so returns an error which includes:
      “The WinRM client received an HTTP status code of 307 from the remote WS-Management service.”
      I’ve worked with remoting errors/configs always based on the configuration of the target computer.  In this case the issue seems to be with the host initiating the call.
      I have two groups of computers.  Group A is older, Win2008.  GroupB is Win2012R2.  psRemoting is configured the same on all.  All are subject to the same group policies.
      From a machine in Group A, I can create a session on any computer in either group.  This tells me psRemoting is configured on all.
      I fail to create a remote session from ANY machine in Group B to any other machine, in either group.
      Client Auth\CredSSP is enabled.  The WinRM configurations on hosts is identical, included here:
      Config
      MaxEnvelopeSizekb = 500
      MaxTimeoutms = 60000
      MaxBatchItems = 32000
      MaxProviderRequests = 4294967295
      Client
      NetworkDelayms = 5000
      URLPrefix = wsman
      AllowUnencrypted = false
      Auth
      Basic = true
      Digest = true
      Kerberos = true
      Negotiate = true
      Certificate = true
      CredSSP = true
      DefaultPorts
      HTTP = 5985
      HTTPS = 5986
      TrustedHosts = *
      Service
      RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
      MaxConcurrentOperations = 4294967295
      MaxConcurrentOperationsPerUser = 1500
      EnumerationTimeoutms = 240000
      MaxConnections = 300
      MaxPacketRetrievalTimeSeconds = 120
      AllowUnencrypted = true [Source=”GPO”]
      Auth
      Basic = false
      Kerberos = true
      Negotiate = true
      Certificate = false
      CredSSP = false
      CbtHardeningLevel = Relaxed
      DefaultPorts
      HTTP = 5985
      HTTPS = 5986
      IPv4Filter = * [Source=”GPO”]
      IPv6Filter = * [Source=”GPO”]
      EnableCompatibilityHttpListener = false
      EnableCompatibilityHttpsListener = false
      CertificateThumbprint
      AllowRemoteAccess = true [Source=”GPO”]
      Winrs
      AllowRemoteShellAccess = true
      IdleTimeout = 900000 [Source=”GPO”]
      MaxConcurrentUsers = 2147483647
      MaxShellRunTime = 2147483647
      MaxProcessesPerShell = 2147483647
      MaxMemoryPerShellMB = 2147483647
      MaxShellsPerUser = 2147483647
      What am I missing?
    • #253010
      Participant
      Topics: 8
      Replies: 168
      Points: 817
      Helping Hand
      Rank: Major Contributor

      You make the comment: “In this case the issue seems to be with the host initiating the call”

      Have you checked the Trusted Hosts entry to make sure Group B is included in whatever you have defined?

      Computer Configuration/Admin Templates/Windows Components/Windows Remote Management/WinRM Client

       

    • #253034
      Participant
      Topics: 1
      Replies: 2
      Points: 19
      Rank: Member

      Yes, TrustedHosts = *.  For some reason, Group B cannot create a connection to any host.  Group A hosts can connect to Group A hosts and all Group B hosts.  Same subnet.  No switch/router/firewall.  MS firewall is disabled on all hosts.

    • #253043
      Participant
      Topics: 8
      Replies: 168
      Points: 817
      Helping Hand
      Rank: Major Contributor

      I have also seen IPV6 cause odd issues with PSRemoting. I start with “Enable-PSRemoting -Force”, and somtimes would get the public profile error. Simply turning off IPV6 would solve that problem. Seemed odd to me this would fix the error, and I did not want to add -SkipNetworkPfrofileCheck.

      Another issue that can crop up with PSRemoting is the Remote Registry service. Try enabling that on group B??

      And lastly, make sure you can get to C$ on the group B hosts from the system running the remote queries.

      Just thinking out loud. I have a script that audits remote systems and these are some of the issues I have seen. I am guessing you already know/have tried this, but you never know.

    • #253097
      Participant
      Topics: 8
      Replies: 669
      Points: 2,631
      Helping Hand
      Rank: Community Hero

      Good suggestion on the network profile. You can use

      and if it’s public change it with

      Trey you never said what A/V and firewall you are using. What does these commands show?

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