Updating PowerShell Core Windows Compatibility

I thought I'd share a quick update on my experiences in living in a PowerShell Core world. One of the things that Microsoft is working on to make this easier is a way to access your Windows PowerShell modules that will work in PowerShell Core. It does this through commands in the WindowsCompatibility module. However ,I've encountered an annoyance which you might also see which I figured I should share, along with my work around.

Expected Behavior

PowerShell Core behaves pretty much the way it does in Windows PowerShell. In a Windows system you can map a new PSDrive and if you use a letter, PowerShell automatically defines a simple function that makes it easy to change to that path.

I can create a new PSDrive and change to it without error.  Now I'll import the WindowsCompatibility module.

Problem Behavior

One of the ways the module works is to provide access to Windows PowerShell commands via a remoting compatibility session. It may not always be clear when such a session gets created, although you can intentionally create it with Initialize-WinSession.

I'm sure the expectation is that commands will transparently use this session. But there is a bit of an issue. Look what happens when I try to change to the S: drive now.

PowerShell complains but in fact changes location. Digging into the error I found that the Set-Location command was being run through the WinCompatibility session, which doesn't know anything about the S: drive.

I discovered that if I create the drive in the session, then the annoying error is resolved.

A Scripted Solution

With this in mind I came up with a scripted solution. Part of my PowerShell profile is create a number of PSDrive shortcuts. Once those are defined I go ahead an import the WindowsCompatibilityModule

Import-Module WindowsCompatibility
Add-WindowsPSModulePath
Initialize-WinSession

I know I'll need the WinCompat session. I then call this function.

#requires -version 6.1
#requires -module WindowsCompatibility

Function Update-WinCompatibiltySession {
    [cmdletbinding(SupportsShouldProcess)]
    [alias("uwc")]

    Param([switch]$Passthru)

    Try {
        $s = Get-PSSession -name "wincompat-localhost-$env:username" -ErrorAction Stop
        $local = Get-PSDrive
        foreach ($psdrive in $local) {
            if ($PSCmdlet.ShouldProcess($pdrive.name, "Adding")) {
                Invoke-Command {
                    Try {
                        Get-PSDrive -Name $using:psdrive.name -ErrorAction Stop | Out-Null
                    }
                    Catch {
                        $newParams = @{
                            name       = $using:psdrive.name
                            PSProvider = $using:psdrive.provider
                            Root       = $using:psdrive.root
                        }
                        #mapping the drive using the credential. This may not be necessary.
                        if ($using:psdrive.credential.username) {
                            $newParams.Add("Credential", $using:psdrive.credential)
                        }
                        $new = New-PSDrive @newParams
                        if ($using:Passthru) {
                            $new
                        }
                    }
                } -session $s
            }
        } #Whatif
    }
    Catch {
        Write-Warning "Did not detect a WinCompat remoting session. You might need to run Initialize-WinSession."
    }
}

The function gets all PSDrives in my local session and adds it in the remoting session if it doesn't already exist. And yes, I realize there are several ways I could have accomplished this. But now, my errors are gone.

If I add another drive later, I need to re-run the function.

I have an open issue on this in GitHub but for now, this arrangement seems to work around the issue.

---

---