Many Things Go Well with PowerShell 7 - But Not All!

Introduction 

I am currently working on a PowerShell 7 book for those nice people at Wiley (https://blackwells.co.uk/bookshop/product/PowerShell-7-and-NET-Core-3-0-for-IT-Pros-by-Thomas-Lee-author/9781119644729). I'm meant to finish up by December and have the book out in 2020. For me, one of the key questions around PowerShell 7, in the Window space at least, is how well PowerShell 7 can be used to manage an enterprise. If it can, then IT Pros can move towards it with increasing confidence.

PowerShell 7, at the time this is written is at Preview-3 stage with an expectation of shipping sometime in September. If you find I am wrong on any of the points below please let me know. This is a work in progress as we approach PowerShell 7 RTW.

What Works and What Doesn't

In working on the book, I have found that commands, modules, and .NET classes fall into 3 distinct bands:

• Stuff that works. 
• Stuff that can work using WindowsCompatibility module
• Stuff that does not work and probably won't work 

Stuff that works is, well, stuff that works. Most of the basic day to day commands/modules work fine. Which I think is to be expected. A big win here is that the ActiveDirectory module works great (although sadly, the AD Deployment module does not work natively).

The Windows Compatibility module (WCM) is a solution to some compatibility issues. WCM uses a combination of implicit remoting and PowerShell remoting sessions. For each module you want to use - you use Import-WinModule to load the commands in the current PowerShell session. WCM, under the cover, creates a remoting session into PowerShell 5.x on the local machine and imports the underlying module using implicit remoting. Thus you can import the ADDeployment module using this technique and access the commands natively.

Stuff that doesn't work and never well should be a small subset of overall PowerShell functionality. An example is workflows - these depend on Windows Workflow Foundation and thus far at least, there is no interest in porting the necessary .NET classes to .NET Core.

While I never say never, I think if you want to use anything that doesn't work today - you either stick with PowerShell 5.x for the foreseeable future or evaluation alternatives.

Stuff that Doesn't Work and May Never Work

Here is my list of PowerShell 5.x features that are (probably) not ever going to work in PowerShell 7:

• Workflows - Workflows in PowerShell depends on the Windows Workflow Foundation and that is not in .NET Core. As far as can be told at the time of writing, this is not going to happen. See the release notes at https://docs.microsoft.com/en-us/powershell/scripting/whats-new/breaking-changes-ps6?view=powershell-6.
• PowerShell Snap-ins - Snap-ins was an earlier approach to add-ins, but were replaced by Modules in Windows PowerShell 2.  Some Microsoft modules were affected but these are being updated. In many cases, you can convert the Snap-in into a module - but many modules delivered by third parties may not be so easy to modify. If you are still using an old snap-in, consider migrating it to a module. 
• Desired State Configuration - this too is not going forward. At least not yet. Having said that, there might be some updates on this shortly. We'll see.
• Windows Update - the issue here is that much functionality of WSUS is delivered via methods, not via cmdlets. The WSUS object methods do not work via Windows Compatibility. It turns out that the module also makes use of SOAP which causes more issues with future support. This is unlikely to be supported in PowerShell 7.
• Best Practices Module - I would have expected this module to have been fully supported.

Things That Work Using the Windows Compatibility Module

There are a number of Windows PowerShell cmdlets and modules which are not supported natively in PowerShell 7 but can be used by way of the WindowsCompatibility module. You load these modules using the Import-WinModule command.

The modules I've found that do not work natively in PowerShell 7 but do work with Windows Compatibility Module include:

• ADDSDeployment module 
• AppLocker module
• BITSTransfer module
• ConfigCI module
• DFSR module
• DHCP Server module 
• GroupPolicy module
• IscsiTarget module
• MsDtc  module
• NetworkController module
• NetworkControllerDiagnostics module
• NetworkLoadBalancingClusters module
• ServerManager module
• Storage Replica module
• The *-Computer commands in Microsoft.PowerShell.Management - specifically Add‑Computer, Checkpoint-Computer, Remove‑Computer, and Restore-Computer commands.
• The *-Counter commands - these are used to obtain Windows performance counters.
• The WMI cmdlets. I was kind of surprised at this - but still, the CIM cmdlets are just a better way to leverage WMI.

NB: this is a work in progress. I'll update it as I find out more:

1. (20/8) Removed Print Management from a list of modules that do not work - all seems fine with Preview.2 and beyond
2. (21/8) Updated modules that need remediation. 
3. (21/08) Retested and updated based on Preview 3.
4. (2/09) Added issue with Windows Update, added BITS module to remediated list.