Windows PowerShell 5.1 and PowerShell 7.4: Enable-PSRemoting

Paige__Tanner 

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:

• Installing PowerShell on Windows - PowerShell | Microsoft Learn

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.

• PowerShell remoting in PowerShell 7 should use PowerShell.7 endpoint by default · Issue #11616 · PowerShell/PowerShell · GitHub

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