Category: Cloud / Azure / Office365

Following the March 2019 release of PowerShell Core 6.2, the Microsoft PowerShell team announced that Windows PowerShell 5.1 and the PowerShell 6.x Core version will converge into a single version known as PowerShell 7.

Apart from automation across Linux, macOS and Windows, a very high degree of compatibility with existing Windows PowerShell (5.x) modules can be achieved with the next release of PowerShell 7 by leveraging changes in .NET Core 3.0 (such as the return of Out-GridView in Windows).

Unlike the current PowerShell Core support lifecycle, PowerShell 7 will have both LTS (Long Term Servicing) and non-LTS releases which aligns closely with the .NET Core support lifecycle.

PowerShell 7 in Windows is planned to ship as a side-by-side feature with Windows PowerShell 5.1. No information around the PS7 release date in a future version of Windows 10 or Windows Server is available though as the release timelines of .NET Core and Windows do not align.

According to Microsoft, May (2019?) is the likely first Preview release of PowerShell 7 with the generally available (GA) some time after the GA of .NET Core 3.0.

Besides the common -Identity parameter, most cmdlets from the Active Directory Module for PowerShell support the -Filter parameter.

If you encounter the following error even though the syntax is correct,

PS C:\> Get-ADGroup -Identity *
Get-ADGroup : Cannot find an object with identity: * under: ‘DC=swissitpro,DC=com’
At line;1 char:1
+ Get-ADGroup -Identity *
+ CategoryInfo : ObjectNotFound: (*:ADGroup) [Get-ADGroup], ADIdentityNotFoundException
…

simply replace -Identity with -Filter and try again. Obviously this makes sense (and is the only way) to get a list of all defined active directory security and distribution groups in the organisation.

It is common to use Start-Job to run a  background job against a remote machine via the -ScriptBlock parameter:

Start-Job -ScriptBlock { param($computer) Get-EventLog -LogName system -ComputerName $computer } -ArgumentList $computer

However, this always runs as a local BackgroundJob, consumes local resources and can be very slow.

Instead, consider using the -AsJob parameter of Invoke-Command to run the task as a RemoteJob on a remote host via -ComputerName i.e.

Invoke-Command -AsJob -ComputerName $computer -ScriptBlock { Get-EventLog -LogName system }