ICM fails on call back to local PC

Copper Contributor

Hi there.

 

I've an odd issue with Powershell.  I discovered that I cannot ICM from the domain controller to a remote workstation - and I also cannot ICM from the actual workstation PC console back to itself. 

 

This had been properly configured & working until...

 

(Recent details:  We had an SBS 2008 DC, migrated to WS2019.  When I finally transferred DNS & DHCP and took the old server offline is when the ICM problem began.  Before the SBS 2k8 came offline and the two DCs were still replicating AD & etc., I could ICM from the WS2019 DC with no problem.)

 

Not sure what to make of it. 

 

On a side note, the DHCP snap-in strips the domain from the server name and replaces it with 'mshome.net' no matter how many times I delete it and add it back in - and does not allow any interaction.  But the Get-DHCPServer(...) cmdlets report all the correct settings, scope, exclusions, etc. - so I've ignored this for the most part.)

 

Linear_z_0-1590761285577.png

 

Linear_z_3-1590757513118.png

 

--------------------------------

Back to the initial question, this is an example of events pulled from WinRM / ICM where the client & destination are the same computer:

 

Thinking perhaps User & Computer domain mismatch?

 

Linear_z_2-1590756809446.png

 

Linear_z_1-1590756758129.png

 

Any ideas? 

 

Thanks!

 

 

P.S. This might be correlated - RDP attempt from the DC to remote PC.  Strange error since the DC is the computer being used, but says the DC can't be contacted for NLA.

 

Linear_z_0-1590761644158.png

 

1 Reply

@Linear_z 

 

From what I can deduce, it was GPO. 

 

The SBS2k8 had a policy object "Allow automatic configuration of listeners" which is not present in WS2019 and caused this to occur once the old server came offline and the forest functional level was elevated:

 

PS C:\WINDOWS\system32> winrm enumerate winrm/config/listener
Listener [Source="GPO"]
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = null

 

So when the IP filter for the client listeners was set back to " * " and GPO refreshed, Invoke-Command works from the DC as expected. :thumbs_up: 

 

On a side note: the clients produce a new error now when ICM'ing to themselves - which I had tried initially as a test measure since the DC would actually do that successfully.  This really is immaterial though because there is no reason to ever do this, but now it says: "The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available." 

 

Maybe a puzzle to work on when there's nothing else to do - but for now it's of no concern.  🤷‍:male_sign: