ForEach-Object -Parallel - Comes to PowerShell 7 in P.3

The latest preview edition of PowerShell 7 (itself due for full release at end of Sept or thereabouts) contains a long-awaited feature - the ability to run invocations of a given script block in parallel natively.

An example: Suppose you had a script that used WMI remotely to gather/update information on a number of remote servers. Instead of doing the required operations on one server at a time, running each invocation of the script block in parallel. The ability to run script blocks in parallel has been a huge reason many folks use Workflows (which are not part of PowerShell 7). Foreach -Parallel does away with the need to use workflows just to get parallelism.

Consider the following snippet:

'Non-parallel' $Sb1 = { 1..100 | foreach-object { start-sleep -Milliseconds 100 }} Measure-command { ICM -ScriptBlock $Sb1 } $len = 0

In this sample, you run a script block 100 times. Admittedly the actual script block is not all that exciting but it's an operation that is being done in each iteration of ForEach-Object. The output shows this:

With the third preview of PowerShell 7, the ForEach-Object cmdlet has two new parameters. The first -Parallel which says to run things in parallel. The second, -Throttlelimit tells PowerShell how many separate parallel invocations are allowed. 

Let's rerun that script block but using parallelism and varying the throttle limit:

As you can see, without parallelism, this "script" takes 11.07 seconds. With parallelism, the script takes 4.93 seconds (using throttle limit of 4), 3.70 seconds (throttle limit of 8) and just 2.92 seconds (throttle limit of 12). My system is a dual-processor 6-core system by way of comparison. If you try this, you may get different results depending on your hardware.

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.