PowerShell 7 Remoting Cleanup

Now that PowerShell 7 is here and hopefully installed on your Windows 10 desktop, you're good to go, right? I'd say you probably all set. However, if like me, you were running PowerShell 7 betas or had PowerShell Core also installed, a little housekeeping might be in order. I don't think what I'm going to discuss has any serious implications. But I like to maintain a tidy system and I'm betting many of you do as well.

PSSessionConfigurations For Everyone

On my Windows 10 desktop, I had been running PowerShell Core, the 6.x version of PowerShell, as well as the PowerShell 7 betas and release candidates. I enabled remoting over WSMan with each. Over time, this has left me with multiple PSSessionConfiguration settings.

In PowerShell 7, you don't see the PowerShell 5.1 sessions. I doubt there are any issues with simply leaving these here, but it feels messy to me. At this point, I've already uninstalled PowerShell Core 6.x so I definitely don't need the related sessions. Digging a little deeper I can discover what these sessions are pointing to.

My first thought was that some of these files have since been deleted. I figured I could use PowerShell to determine which sessions still have valid plugin files.

This surprised me. But it was easily verified.

Even though the PowerShell v6.x editions had long been uninstalled, these locations remained. Along older PowerShell 7 bits.

Version Cleanup

When you install the final release of PowerShell 7 and enable remoting you will get folders labeled 7 and 7.0.0. The plugin files in each folder are identical. From what I have learned so far this is by design. There is a generic PowerShell 7 folder and then a version specific folder, 7.0.0. Presumably, at some point in the future I'll install something like PowerShell 7.1.0 which will overwrite the 7.0.0 folder. I'm trying to learn more about this,  but for now that doesn't factor into my cleanup tasks.

My clean up will consist of removing the obsolete files and folders and unregistering the obsolete PSSessionConfigurations.

#requires -version 7.0

[cmdletbinding(SupportsShouldProcess)]
Param()

#clean up folders
Get-Childitem -path $env:windir\system32\powershell -directory |
Where-object {$_.name -notmatch "^7(\.0\.0)?$"} | Remove-Item -Force -Recurse

#clean up sessions
Get-PSSessionConfiguration | Where-object {$_.name -notmatch "^Powershell\.7(\.0\.0)?$"} | 
Unregister-PSSessionConfiguration -Force -NoServiceRestart

Write-Warning "You will need to restart the WinRM service for these changes to take effect"

The script file uses a regular expression pattern to keep the current PowerShell 7.0.0 files and sessions. I also included support for -WhatIf.

I figured I was all set. But apparently not.

I suspect that I should have removed the session configuration before removing the files. So I have revised my script.

[cmdletbinding(SupportsShouldProcess)]
Param()

#clean up sessions
$sessions = Get-PSSessionConfiguration | Where-Object {$_.name -notmatch "^Powershell\.7(\.0\.0)?$"}
foreach ($session in $sessions) { 
    Try {
        Unregister-PSSessionConfiguration -Name $session.name -Force -NoServiceRestart -ErrorAction Stop
    }
    Catch {
        #Fall back to this if the cmdlet fails
        winrm delete http://schemas.microsoft.com/wbem/wsman/1/config/plugin?Name=$($session.name)
    }
}

#clean up folders
Get-Childitem -path $env:windir\system32\powershell -directory |
Where-object {$_.name -notmatch "^7(\.0\.0)?$"} | Remove-Item -Force -Recurse

In this version, if Unregister-PSSessionConfiguration fails, I'll fall back to the winrm command line tool. However, when I try again, I still get errors. In fact, I appear to have completely botched things up. But that's ok. That's how I can learn more. Any perhaps some of you might encounter equally trashed environments.

Digging Deeper

What I should have done, is backed up the files before I deleted them. Or created a system restore point. You should keep that in mind. In my case, I'm going to need to go an alternate route because even after restarting the WinRM service, My WSMan configuration is still looking for plugin configurations. These are stored in the registry.

I'm working under the assumption that if I remove the obsolete registry entries, I can get over the Get-PSSessionConfiguration error.

$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin"
#get the PowerShell plugins
$ps = Get-Childitem -path $regPath | Where {$_.PSChildName -match "^PowerShell"}
#filter the ones to remove
$remove = $ps | where-object {$_.pschildname -notmatch "^Powershell\.7(\.0\.0)?$"}
$remove | Remove-Item -Recurse -Force #-WhatIf

I tested with -WhatIf to verify I'm removing the correct entries. Once those entries are deleted, I finally have the PSSessionConfigurations I want.

Summary

You don't have to automate this type of cleanup. But if you do, it seems you should unregister the PSSessionConfiguration and then delete any left over files or registry keys that remain.  Personally, I'm looking forward to someday using SSH for all my PowerShell remoting needs. But for now, WSMan still plays a role and might need a little attention every now and then.

---

---