Aside from its name - WinPsCompatSession- it looks just like any remote PowerShell session. Let’s start by taking a look at that remote session to localhost.

To use a Windows PowerShell 5.1 module in pwsh 7, you Import-Module using a new parameter: UseWindowsPowerShell. PowerShell 7 loads Windows PowerShell (desktop) modules in a remote session You can clearly see the remote session being set up. If you watch carefully, you’ll see how it’s done: via a remote PowerShell session to localhost. This is running in pwsh 7, as you can see on the status bar lower right of the window. In this gif, you see a simple script that assigns Get-AzureAdTenantDetail output to a variable after a Connect-AzureAD cmdlet. It works only on a Windows desktop or server (no help for us macOS and Ubuntu fans) and has some very interesting attributes you should know about. I think what they released will prove to be quite useful: PowerShell 7 does provide a a way to use 5.1-only modules in PowerShell 7.

Over time, things will get better (I hope) but the PowerShell team decided to do something in the meantime to ease Windows users into migrating to PowerShell 7. There are some Azure modules - my poster child is AzureAD - that an Azure architect can’t live without and which cling stubbornly to Windows PowerShell 5.1. One obstacle in doing so in the PowerShell Core (6.x) release was limited compatibility with Windows PowerShell 5.1 modules. PowerShell 7 is finally here (woot!) and it’s time for Windows users to think seriously about migrating to pwsh 7.

Azuread powershell 7