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
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.
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.
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?
Test-WSMan -ComputerName GroupB-PC Test-WSMan -ComputerName GroupA-PC
Thanks for input, but no progress.
Remember, this is not a case of configuring systems to ACCEPT a psSession or remote job. All these systems run remote jobs initiated from a management workstation. NONE of these systems, GroupB, can INITIATE a connection to another host.