I have a number of computers, all up to date, all members of a Domain.
Windows 2012R2 (Domain Controller) (Virtual)
Windows 2012R2 (Member Server) (Virtual)
Windows 10 Pro Build 1803 (Physical) (Hyper-V Host)
Windows 10 Surface Pro 4 Build 1709
Windows 10 HP Laptop Build 1709
I can Remote Desktop into any of them using either FQDN or NetBIOS name. They are all physically connected to the same switch. I can also run cmdlets using the computer name parameter, successfully. However when I try to enable Remoting, either Enable-PSRemoting or set-WSManQuickConfig, I get the same Response:
set-wsmanquickconfig : The client cannot connect to the destination specified in the request. Verify
that the service on the destination is running and is accepting requests. Consult the logs and documentation for the
WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run
the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”.
Set-WSManQuickConfig : The client cannot connect to the destination specified in the request. Verify
that the service on the destination is running and is accepting requests. Consult the logs and documentation for the
WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run
the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”.
WINRm is started and set to: “Automatic Delayed start”
When I run: netstat -anop TCP I do not see a listener on any Interface for Port 5985
If I run: Netsh http show IPListen. I get:
PS C:\WINDOWS\system32> netsh http show iplisten
IP addresses present in the IP listen list:
192.168.100.9
They all give the same result. I believe the problem is more fundamental than PowerShell, but before I try a Domain re-build, has anybody got any ideas?
Something’s stopping it from working, then. If it’s on all machines, then I’d suspect something in domain policy, but I’ve never, ever run into this myself, so I don’t even know where to tell you to look. Enable-PSRemoting isn’t spitting out anything useful, although you could see if the diagnostic or analytic event logs for WS-MAN or Remoting have anything useful.
Thanks for the reply, I am looking at G.P. at the moment and the to better understand the process, I am looking into WS-Management to see if that will be of use. How important is PSremoting to using “Learn PowerShell in a month of lunches”? Could I skip it for now? While I sort this out.
If I then change to WSMan: and do dir, I get:
PS WSMan:> dir
WSManConfig:
ComputerName Type
localhost Container
However, there are no further paths. If I do a cd localhost and dir, I get:
PS WSMan:\localhost> dir
dir : The client cannot connect to the destination specified in the request. Verify that the service on the
destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service
running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following
command on the destination to analyze and configure the WinRM service: “winrm quickconfig”.
At line:1 char:1
A little more information:
C:>dcdiag
Run on my DC does not produce any errors.
Netsh>set machine DC
[DC]Netsh>
Could there be a bug in PowerShell? Any suggestions as to recommended actions, greatly appreciated.
None of the domain controller stuff should have anything to do with it. Remoting doesn’t really interact with AD except for the Kerberos authentication piece, which you’re not even up to.
Hi Folks,
I’m a relative newbie and it’s been over a week since I updated this. So I don’t know if these time out and get closed, but here goes, in case it’s of any help:
All is well now, and remote works a treat.
At the outset I suspected my Domain had been sexually assaulted at some point, I had had various hardware issues and Domain down time. There was nothing I could find in the logs that gave me cause for concern, but I’m sure others may have spotted something I missed. The thing that put me off was that if I logged on as a local user, there was still a problem. Though in hind sight the computer is still a member of the domain, and still must communicate with AD. None of my research, or enquiries came up with any suggestions and I suppose I was being a little lazy. Yesterday I decided I should try and rebuild the Domain, I had all the backups I needed, so shouldn’t be a problem. I removed a member Server and Windows 10 workstation from the Domain and tried again. I now got the correct response from:
Enable-PSremoting -force
WinRM is already set up to receive requests on this computer.
WinRM has been updated for remote management.
WinRM firewall exception enabled.
However, as the two computer were stand-alone, there was no trust between them so I had to set up the trust: