Forum Discussion
Windows PowerShell 5.1 and PowerShell 7.4: Enable-PSRemoting
Hello!
In a host with Windows 10 (after activating the service WinRM), in Windows PowerShell 5.1 I ran Enable-PSRemoting.
If now I also install PowerShell 7.4, is PSRemoting automatically enabled there, or should I enable it again from PowerShell 7.4?
Then, from a remote host, how to connect specifically to Windows PowerShell 5.1 or to PowerShell 7.4?
Remoting is enabled by default on Windows 10 and 11 and aligned to Windows PowerShell.
Windows PowerShell comes with its own endpoint, and PowerShell comes with its own, which is not automatically registered on installation.
Let's say you have two computers and you install PowerShell 7.4 on just one of them. You can still remote from one machine to the other and in both cases the common denominator is Windows PowerShell, meaning you session is a Windows PowerShell session, even if you're launching the remote session from the host that contains PowerShell 7.4.
This doesn't change even if you then install PowerShell 7.4 on the second host, since as mentioned above, the PowerShell 7.4 endpoint is not automatically registered. To register it, you need to run (default location shown):
C:\Program Files\PowerShell\7\Install-PowerShellRemoting.ps1
This creates the endpoint but does not control the default. Rather, when you're creating the remoting session, you need to specify the configuration you want to connect to (which of course needs to exist in the first place; i.e. if you get the name wrong, it won't work).
Here's a reference article:
Here's a complicated history of PowerShell versus Windows PowerShell which contains a lot of the thought processes behind why things are the way they currently are.
If I were to offer any advice from a very reductionist perspective, I'd say that if you're a Windows customer, stick to using PowerShell for your manual administration and author scripts that will work in both PowerShell and Windows PowerShell, since the latter has significantly better coverage given it ships natively with Windows.
If you feel you can adequately cope with version management and deployment for PowerShell across the enterprise, then you can absolutely choose to pursue PowerShell for everything, but I have yet to see a single enterprise with complete Windows (Server and client) coverage and version parity, hence why I work with Windows PowerShell.
Conversely, if you're in a heterogenous environment where PowerShell hasn't been used much, perhaps that's a good enough reason to try and standardise (meaning sorting out the deployment and maintenance topics) on PowerShell from the outset, though even there, when it comes to Windows and Azure platforms, there are a modest number of modules that do not play nicely with PowerShell as they were framed to work with Windows PowerShell.
Lots to think about. But there's no harm whatsoever with having both installed and keeping on top of them via your daily manual administration (if that's a relevant scenario to your position).
Cheers,
Lain
Thank you for all your observations. They are very useful.
Just for the sake of completeness, the endpoints in a "server" machine can be listed with "Get-PSSessionConfiguration" (sometimes only available if PowerShell has been run as Administrator) and, as mentioned in the other thread, they can be selected in the "client" machine through "-ConfigurationName <endpoint_name>" in "Enter-PSSession" or "New-PSSession".
Thanks for the links, which probably can provide more insight as regards the difference between Windows PowerShell and PowerShell.
My tasks are simple and more related to an enthusiast than to an enterprise, and I prefer PowerShell 7.x. But I take into account all your advices, with the several different use-cases you mentioned.
Paige
