Remoting fails, to and from a Win-10\Pro to any Win-11\Home; on the same Lan

Three machines on a Lan, no Domain, no Microsoft account’s; nothing exotic. Two Win-11\Home and a Win-10\Pro; same subnet and workgoup. The Win-11’s can remote to one another, nothing can remote to Win-10\Pro and Win-10\Pro cannot PS-remote (out) as well. Otherwise the networking, as it relates to SMB and the Inet, are typical for MS\Windows.

The only difference’s I have discovered are: a slight .NET versioning, along with, the following Registry Entry does not exist within the Win-10\Pro registry. a) Is the below entry required to allow LAN machine’s to PS-remote to one another? If so, is the path (below) valid for Win-10\Pro?


Get-ItemProperty –Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System –Name LocalAccountTokenFilterPolicy

I ultimately turned-off all the firewalls on each machine; same failed results. Everything posted below is Windows-10\Pro, until\unless otherwise posted:

OsName                   osdisplayversion OsVersion
------                   ---------------- ---------
Microsoft Windows 10 Pro                  10.0.19045

PS C:\Windows\system32> $psversiontable

Name                           Value
----                           -----
PSVersion                      5.1.19041.5247
#
# Win-11\Home(A) .NET installed versions
#
PS C:\Windows\system32> Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse | Get-ItemProperty -Name version -EA 0 | Where { $_.PSChildName -Match '^(?!S)\p{L}'} | Select PSChildName, version

PSChildName                      Version
-----------                      -------
v2.0.50727                       2.0.50727.4927
v3.0                             3.0.30729.4926
Windows Communication Foundation 3.0.4506.4926
Windows Presentation Foundation  3.0.6920.4902
v3.5                             3.5.30729.4926
Client                           4.8.09032
Full                             4.8.09032
Client                           4.0.0.0
#
# Win-11\Home(B) .NET installed versions
#
PSChildName Version
----------- -------
Client      4.8.09032
Full        4.8.09032
Client      4.0.0.0
#
# Win-10\Pro .NET installed versions
#
PSChildName Version
----------- -------
Client      4.8.09037
Full        4.8.09037
Client      4.0.0.0
#
# Win-10\Pro --'WinRM Service' status and settings:
#
Status   Name               DisplayName
------   ----               -----------
Running  winrm              Windows Remote Management (WS-Manag...

PS C:\Windows\system32> Get-Service winrm | format-list *


Name                : winrm
RequiredServices    : {RPCSS, HTTP}
CanPauseAndContinue : False
CanShutdown         : True
CanStop             : True
DisplayName         : Windows Remote Management (WS-Management)
DependentServices   : {}
MachineName         : .
ServiceName         : winrm
ServicesDependedOn  : {RPCSS, HTTP}
ServiceHandle       : SafeServiceHandle
Status              : Running
ServiceType         : Win32OwnProcess, Win32ShareProcess
StartType           : Automatic
Site                :
Container           :

#
# Continuing on the Win-10\Pro:
#

PS C:\Windows\system32> enable-psremoting -force

WinRM is already set up to receive requests on this computer.
Set-WSManQuickConfig : <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859113"
Machine="localhost"><f:Message><f:ProviderFault provider="Config provider"
path="%systemroot%\system32\WsmSvc.dll"><f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault"
Code="2150859113" Machine="Win-10\Pro"><f: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. </f:Message></f:WSManFault></f:ProviderFault></f:Message></f:WSManFault>
At line:116 char:17
+                 Set-WSManQuickConfig -force
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation:

#
# The message above states -- " ...one of the network connection types on this machine is set to Public."
# That is 'not' true. Ethernet = 'Private', WiFi = 'Disabled' and the firewall is entirely 'off'.

#
# Attempt to remote to a Win-11 box
#
PS C:\Windows\system32> Invoke-Command -ComputerName Win-11(A) -ScriptBlock {get-process}

[Win-11(A)] Connecting to remote server Win-11(A) failed with the following error message : Access is denied. For more
information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (Win-11(A):String) [], PSRemotingTransportException
    + FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken
	
#
# Entered on the Win-11\Home:
#
PS C:\Users\UsrAcct> Invoke-Command -ComputerName Win-10\Pro -ScriptBlock {get-process}
[Win-10\Pro] Connecting to remote server Win-10\Pro failed with the following error
message : Access is denied. For more information, see the
about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (Win-10\Pro:String) [], PSRemotingTranspor
   tException
    + FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken

Post Updated – 20250108_075245

PS C:\Windows\system32> Get-PSSessionConfiguration

Name          : microsoft.powershell
PSVersion     : 5.1
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators
                AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : microsoft.powershell.workflow
PSVersion     : 5.1
StartupScript :
RunAsUser     :
Permission    : BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users
                AccessAllowed

Name          : microsoft.powershell32
PSVersion     : 5.1
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators
                AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Updated – 20250108_093435

Additional research, findings and things that have been completed.on the Win-10\Pro, the machine in question, a ‘Network Reset’ was completed; issue remains. As previously mentioned, the error/exception displayed in the initial post stated one of the network interfaces was labeled as ‘Public’; which I know is not true. Moment’s ago. to find network interface’s set as public, the following returned --an empty prompt.

Get-NetConnectionProfile | Where-Object { $_.NetworkCategory -eq "Public" }

The results of this next command, courtesy of ‘Get-Help About_Remote_Troubleshooting’ is most interesting:

PS C:\Windows\system32> Get-WSManInstance winrm/config/listener -Enumerate


cfg                   : http://schemas.microsoft.com/wbem/wsman/1/config/listener
xsi                   : http://www.w3.org/2001/XMLSchema-instance
lang                  : en-US
Address               : *
Transport             : HTTP
Port                  : 5985
Hostname              :
Enabled               : true
URLPrefix             : wsman
CertificateThumbprint :
ListeningOn           : {127.0.0.1, 169.254.27.231, 172.20.160.1, 172.23.16.1...}

127.0.0.1 is obvious, both of the 172.x.x.x are associated with the [Ethernet adapter vEthernet (default Switch)] and the [Ethernet adapter vEthernet (Ethernet)] interfaces; respectively. According to ‘ipconfig’ result’s, run on the Win-10\Pro box, there is no listed interface associated with the 169.x.x.x.

At this point the most important item’s to note: i) The [Ethernet adapter Ethernet] and its assigned ip, the actual interface bound to the ip of the workgroup Lan --is not included with the above ‘ListeningOn’ results. ii) The ‘Network Reset’ was just completed. iii) WiFi is disabled.

I am on my third read of ‘Get-Help About_Remote_Troubleshooting’; I am truly listening …

What is the error? I’m guessing because you’re not in a domain you have to use HTTPS or use the trusted hosts

From the about_Remote_Troubleshooting

When the local computer isn’t in a domain, you must meet the following requirements:

  • Configure the computer for HTTPS transport or add the IP addresses of the remote computers to the TrustedHosts list on the local computer.

I don’t see anything about Trusted Hosts configuration in here. If you’re not in an Active Directory domain Powershell remoting requires quite a bit more set up. Something like what’s covered in this article:
https://4sysops.com/archives/enable-powershell-remoting-on-a-standalone-workgroup-computer/

@neemobeer @grey0ut – Hi, I thought it was obvious that I had http or trustedroot enabled and properly configured --when I stated that only the Win-10 box was a problem. That strongly suggested that the Win-10 was configured using the same method as the others. Apologies for not being specific with those details; I was trying to not make this a boring read.

TrustedHost is employed for all three of the machine’s. For the Win-10\Pro I’ve tried both the machine-name and its ip (separately); it refuses to connect or be connected to. If you haven’t already noticed, the error\exception I posted in the initial post is stating one of the interface’s is labeled as ‘Public’, which would not allow the connect. ← that is not the case, I’ve stated and confirmed that in both my second and third post. The WSmanInstance cmd also display’s --the ListeningOn, is not listening-on the ip which is bound to the Ethernet connected to the workgroup Lan. Also, the WSmanInstance cmdlet is displaying --bound to two different vEthernet, of which I have not a clue, where that data is being pulled from.

To hopefully be on the same page: even after completely disabling the firewall, with the Win-10\Pro box added as a TrustedHost, Win-10 is the only box out of the three that cannot PS-remote to, or allow a PS-remote connection from either of the Win-11 machines --which are able to PS-remote to one-another.

I continue to listen …

20250109024900 @neemobeer @grey0ut
Progress made, not completely resolved but, I’ll settle with this for now. All command’s shown were entered on a Powershell 5.1 elevated (Admin) prompt.

In the initial post, I pointed out WinRM firewall exception will not work ..., because an interface was set to type: 'Public'. The issue here, ‘I’ was focused on the machines WiFi and Ethernet interface’s. However, Winrm and friends were detecting and including all interfaces known to the machine. One of the vEthernet interface’s was marked as ‘Public’.

NOTE-01: The vEthernet interface’s, on this Win-10\Pro box, do not show themselves via the GUI unless you find and select “Change adapter options”. Even at that point you will not know if it/they are Public/Private, not even using ipconfig, --until or unless you step into the Registry. If there is a standard specification as to the default connection type: ‘Public/Private’, for vEthernet adapter’s, I am not aware.

THE REGISTRY: Once I navigated to –
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles, examined all of the pertinent details, I find one of the vEthernet interfaces was set to ‘Public’. After backing-up (Exporting) the registry, making the necessary change from ‘Public’ to ‘Private’, associated with that vEthernet adapter, then restarted the OS; the problem remains.

The next move, disable each and every network adapter except the Ethernet adapter that is bound to the workgroups Lan. This resulted in the Win-10\Pro machine being able to PS-remote to the Win-11\Home(b) machine: PS C:\Windows\system32> Invoke-Command -ComputerName Win-11\Home(b) -ScriptBlock {get-process}

The other Win-11\Home(a) requires the -credential parameter:
PS C:\Windows\system32> Invoke-Command -ComputerName Win-11\Home(a) -credential <UsrName> -ScriptBlock {get-process}

I can live with this for now, there has been a long standing OS stability and other credential/networking issue(s) with the Win-11\Home(a) box, that prompted the suspension of all Windows-11 updates; across the board, resulting in a more stable experience; Win-10\Pro continues with Automatic Win-updates. Both the Win-11\Home(a) and Win-11\Home(b) machines are currently able to PS-remote to the Win-10\Pro --without the need of the -credentail parameter.

Other than winrm and freinds including the vEthernet adapters and their IP’s into the winrm/config/listener,<one of which was set to type ‘Public’>, the output of: winrm enumerate winrm/config/listener did not fully expand the ListeningOn =. Perhaps it was truncated due to the window-size; not sure. In this case it was hiding the ip of the lan-adapter --which the workgroup uses, leaving me to believe the workgroup’s lan-adapter on the Win-10\Pro was not being detected by winrm. Said ip for the workgroup’s lan-adapter had in-fact changed from what winrm enumerate winrm/config/listener was displaying; those were two major speed-bumps.

The other item to note, that I have not yet found or read, why didn’t winrm update the changed ip? Granted that would be a Windows forum question --I hope to find/figure-out. After disabling all of the vEthernet adapter’s, I ran: winrm quickconfig, allowing it to detect and re_generate the data that winrm enumerate winrm/config/listener was displaying.

PS-remoting is now functioning --to and from-- all machine’s on the workgroup’s lan.

1 Like