The remote session with the name WinPSCompatSession is not available

[lehtoj]

Steps to reproduce

Import-Module ModuleName -UseWindowsPowerShell

Expected behavior

Module loads without errors.

Actual behavior

The remote session with the name WinPSCompatSession  is not available.

Environment data

PSVersion                      7.0.0-rc.2
PSEdition                      Core
GitCommitId                    7.0.0-rc.2
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[doctordns]

I can not duplicate this.

First - I do not have a module name 'modulename'

You only get the remoting session if you are loading via compatibility not by default. that is, only the modules in System 32 are remoted. I have tested this extensively and can not, in general, duplicate this.

[lehtoj]

"ModuleName" was simply an example, not a real name obviously. I got the error with every module I tried, so I omitted the real names.

For example modules AzureAD and ExchangeOnlineManagement which are available in the PSGallery do not work in PS7. And as such I attempted to use the UseWindowsPowerShell switch to load them in PS5.1 remote session.

But instead I get the described error, which is not really helpful. I did not know the switch is limited to modules located in system32. If this is intended behavior, then the error message should be clarified to say so.

[doctordns]

I can not reproduce your error. With the exception of the three modules we know are problematic, I can load the others just fine in compatibility mode.

You say AZUREAD module is an issue. I just installed it and it works fine in PowerShell 7. Here is what I see:

Not ALl modules automatically use remoting. The Azure AD module is cross-platform and is used natively in PWSH 7 without using remoting.

[lehtoj]

You can import the modules fine in PS7, but neither Connect-AzureAD nor Connect-ExchangeOnline cmdlets work. They produce error "Could not load type System.Security.Cryptography.SHA256Cng' from assembly 'System.Core".

Which is the reason I wanted to use the UseWindowsPowerShell switch.

Neither AzureAD or ExchangeOnline modules are cross-platform. Their cmdlets use .NET Framework namespaces. A known issue, but no timeline for fix.

[doctordns]

I see what you mean! I was using the AZ..accounts module (which does work) with the AzureAD commands - my bad. I can duplicate what you see.

This appears to be an issue with the module. The module is marked only with Desktop as the supported edition. To resolve this is a challenge for the Azure team.

The Connect=EXOService has the same issue and the module is not marke as Core compatible.

@iSazonov - should both these modules get added to the deny list?

[iSazonov]

I think it could be a temporary solution.

[doctordns]

I really think it is the best solution for RTM.

I strongly feel the product can not go out if there are unexpected surprises like this (and these are two module sets I had not yet tested).

It basically tells the user: this is not going to work (today) in PowerShell 7. I think this is a better solution then failing with an error message that is NOT in any way actionable. I get why the error we are seeing here is generated, but the new user is not given any clues as to how to fix this issue.

At least with putting these modules in the deny list, you shift the problem to where the solutions lies, ie at the MSOnline and AzureAD product teams.

I like the idea of PowerShell team having my back and not letting me load modules that just are not going to work. Today. And bacause that block list is in text - if a working module IS produced, i

[lehtoj]

Please also note that there are two Exchange Online modules; Microsoft.Exchange.Management.ExoPowershellModule and ExchangeOnlineManagement.

Former is installed from https://portal.office.com and the latter from https://www.powershellgallery.com.

There is also predecessor of the AzureAD module, called MSOnline. Which is still very widely in use.

[iSazonov]

/cc @anmenaga for information.

[anmenaga]

The The remote session with the name WinPSCompatSession is not available error is not supposed to happen; we need to get to the bottom of this, but I'm having difficulty with repro (tried on 2 machines) - module AzureAD version 2.0.2.76 from PSGallery:
When loaded directly in PS Core Connect-AzureAD does produce Cryptography.SHA256 errors;
but when loaded using -UseWindowsPowerShell Connect-AzureAD successfully logs me into AzureCloud.

@doctordns do you also see The remote session with the name WinPSCompatSession is not available. error?
@lehtoj can you please try loading any other module with -UseWindowsPowerShell, for example, what output do you get for following?:

# start a fresh PS Core
Import-Module -Name PKI -UseWindowsPowerShell
Get-Module
Get-PSSession

Some other hopefully clarifying thoughts:

• I did not know the switch is limited to modules located in system32
  it is not limited to system32 modules. In fact it was added for scenarios like you are trying to do - when the module is Not in system32, but user wants to use it with WindowsPS anyway.
• The module is marked only with Desktop as the supported edition.
  This is actually kind of misleading... Install-Module by default installs into user directory (e.g. C:\Users\me\Documents\PowerShell\Modules\AzureAD). But PS Core considers any module that is Not in system32 as PS Core-compatible. In other words, any module downloaded from PSGallery by default is considered PS Core-compatible.
  Modules\AzureAD\2.0.2.76\AzureAD.psd1 does not specify CompatiblePSEditions and get-module AzureAD -ListAvailable displays that as PSEdition == Desk, which is misleading. Looks like this is issue PSEdition module field should not say "Desk" when no CompatiblePSEditions field is given in the manifest #7856

[lehtoj]

@anmenaga I made a fresh Windows 10 virtual machine to test and installed PS7.0 RC3 on it.

I tried importing the PKI module with the UseWindowsPowerShell switch, which worked as expected. Then I tried importing the AzureAD module, which also worked.

Unfortunately Connect-AzureAD produces following errors.

Connect-AzureAD: One or more errors occurred.: The handle is invalid
Connect-AzureAD: One or more errors occurred.
Connect-AzureAD: The handle is invalid
Connect-AzureAD: One or more errors occurred.: The handle is invalid

If I use Enter-PSSession to enter the WinPSCompatSession and run Connect-AzureAD in there, I get more verbose errors.

Connect-AzureAD : One or more errors occurred.: The handle is invalid
At line:1 char:1
+ Connect-AzureAD
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : AuthenticationError: (:) [Connect-AzureAD], AadAuthenticationFailedException
    + FullyQualifiedErrorId : Connect-AzureAD,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD
 
Connect-AzureAD : One or more errors occurred.
At line:1 char:1
+ Connect-AzureAD
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : AuthenticationError: (:) [Connect-AzureAD], AggregateException
    + FullyQualifiedErrorId : Connect-AzureAD,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD
 
Connect-AzureAD : The handle is invalid
At line:1 char:1
+ Connect-AzureAD
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : AuthenticationError: (:) [Connect-AzureAD], Win32Exception
    + FullyQualifiedErrorId : Connect-AzureAD,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD
 
Connect-AzureAD : One or more errors occurred.: The handle is invalid
At line:1 char:1
+ Connect-AzureAD
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Connect-AzureAD], AadAuthenticationFailedException
    + FullyQualifiedErrorId : Microsoft.Open.Azure.AD.CommonLibrary.AadAuthenticationFailedException,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD

Then I attempted to import the ExchangeOnlineManagement module with the UseWindowsPowerShell switch and run Connect-ExchangeOnline and Get-EXOMailbox, all worked fine. Very nice.

Next Monday I will test what happens on PS7.0 RC2 as well as RC3 on my work laptop, which is where I originally experienced the "The remote session with the name WinPSCompatSession is not available" error. So I'll get back to you in a few days.

[lehtoj]

Right, so. I tested again on my work laptop and... now the UseWindowsPowerShell switch works as expected. And I haven't even rebooted the laptop since, only opened a fresh PS7.0 RC2 session. Which I did multiple times last week as well, without results changing any.

Unlike on the virtual machine earlier, both AzureAD and ExchangeOnlineManagement modules do work. I did not get "The handle is invalid" error.

I honestly don't know why the UseWindowsPowerShell switch produced the reported error last week, but now it does not. Perhaps there might be relation to VSCode and the PS extension, as I tend to only use VSCode. But I did do test VSCode too and could not replicate the error.

All things considered, seems to generally work as expected, with a few mysterious bugs. If you have any ideas how I might help to investigate the original issues as well as the invalid handle issue further, please let me know.

[MovGP0]

I can confirm this on PowerShell 7.0.0-rc.3. Example:

> Import-Module PKI
Get-PSSession: The remote session with the name WinPSCompatSession  is not available.

however, this seems to work:

> Import-Module PKI -UseWindowsPowerShell
WARNING: Module PKI is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell Core please use 'Import-Module -SkipEditionCheck' syntax.

and this works too:

> Import-Module PKI -SkipEditionCheck;

[doctordns]

SO far as I can tell, the PKI module is core compatible

PS Cert:\CurrentUser\My\> gmo pki | ft name, CompatiblePSEditions

Name CompatiblePSEditions
---- --------------------
pki  {Desktop, Core}

So after importing the module, there should be no compatibility remoting serssion as the cmdlets are native.

[anmenaga]

PKI module is core compatible - this is good find. It turns out they've added CompatiblePSEditions field to pki.psd1. So on older systems (like Server 2016) the PKI module is considered PS-Core-incompatible and WinCompat will be auto-engaged when loading it; but on newer systems the module is marked as PS-Core-compatible so it will load naively.

@MovGP0, @lehtoj do you know if your environment uses some sort of error redirection mechanism (e.g. redirect error stream to the regular output stream) ?

[codykonior]

I have this problem with Import-Module on PowerShell 7.0 RTM (Get-PSSession: The remote session with the name WinPSCompatSession is not available), with these built-in Windows 10 modules:

• FailoverClusters, it can be loaded with -SkipEditionCheck, but functions only work with Import-WinModule. Does not load with -UseWindowsPowerShell.
• ScheduledTasks, it must be loaded with -SkipEditionCheck, but functions only work with Import-WinModule. Does not load with -UseWindowsPowerShell.
• DnsClient. Does not load with -SkipEditionCheck or -UseWindowsPowerShell. It must be loaded with Import-WinModule instead.

[lehtoj]

@anmenaga Nope, no such redirection is taking place.

[doctordns]

In my testing (using Server 1809):

1. Failover clusters - works in compat mode. Does NOT work natively in Pwsh 7 (ie don't bother trying to load it with -SkipEditionCheck). It loads fine using -UseWindowsPowerShell. This module does NOT declare a CompatiblePSEditions tag.

2. Importing ScheduledTasks module works OK natively. This module declares itself as Desktop AND Core.

3.DNS CLient works natively. This module also declares itself as Desktop AND Core.

[codykonior]

I manage a few hundred servers and OSs not just Server 2019 so your observations aren’t valid for my environment.

Furthermore the stuff I listed is accurate and the reason -UseWindowsPowerShell is broken is because of a bug that exhibits when $ErrorActionPreference = ‘Stop’. Later I found there’s an open issue and a merge request in for it from someone else.

[doctordns]

This may be a compatibility issue - can you post the version numbers of the modules that are not working and which OS you tested under? And what specific issues.

For reference - I tested (client and server-side) on Windows Server 2019 1809. running from PowerShell 7.0.0.0 Here are the module versions I saw

FailoverClusters - Module Version 3.1.90.0 which is marked as Desktop (aka Windows PowerShell) only but loads/works in compatibility mode. I tested using both Import-Module and module autoload - both create the remoting session and import the module from that session successfully. I was able to test, the module's commands via building and managing a 2-node failover cluster using iSCSI CSV, and to build a SOFS on the cluster.

What, specifically, is meant by modules does 'not load'?

Can you check to see if your version of this module is moarked accordingly as core compatible?

ScheduledTasks - Module version 1.0.0.0 and marked as compatible with Core. Some basic testing works as expected but have not delved deeply. Are you meaning ScheduledTasks or PSScheduledTasks? The latter does not work.

The Scheduled Tasks module is marked as core compatible so loads natively - there is no reason to use the -UseWIndowsPowerShell switch to load the module.

DNSClient - version 1.0.0.0 and marked as compatible with Core. Built a 2 domain forest, created a second forest, with X-forest trusts, and carried out a wealth of other operations all of which required DNS. Created multiple zones (forward and ptr), RRs etc. I see no issues at all in the Client (or Server0 modules.

As this module is marked as core compatible - no need to use the -UseWIndowsPowerShell script. Can you check to see if your version of this module is marked accordingly as core compatible?

Finally - you mention Import-WinModule. That command is no longer needed. Import-Module has, in effect, incorporated the functionality of Import-WInModule (and even stops known to not work at all in PowerShell 7 modules).

[codykonior]

No need to go into it further.

For others, the fix is on #11980 (disclaimer: I haven’t tested the fix). Until then use Import-WinModule as it doesn’t have this bug. It’s still needed until this is resolved.

[ghost]

🎉This issue was addressed in #11980, which has now been successfully released as v7.1.0-preview.1.:tada:

Handy links:

• Release Notes

[ghost]

🎉This issue was addressed in #11980, which has now been successfully released as v7.0.1.:tada:

Handy links:

• Release Notes