Tag Archives: Powershell

PowerShell 7 Preview 6

This post was originally published on this site

Today we shipped PowerShell 7 Preview.6! This release contains a number of new features and many bug fixes from both the community as well as the PowerShell team. See the Release Notes for all the details of what is included in this release.

This will be the last preview release as we head towards a Release Candidate in December. For the Release Candidate, there will be no more new features although small changes to cmdlets may still be accepted depending on risk of the change. Bug fixes will still be accepted but also accessed for their risk of causing a regression. Finally, we expect General Availability of PowerShell 7 in January as our first Long Term Servicing release.

New Features in Preview 6

This release has a number of new features from both the community as well as the PowerShell team. Remember that preview releases of PowerShell are installed side-by-side with stable versions so you can use both and provide us feedback on previews for bugs and also on experimental features.

You can read about new features in previous preview releases:

There were new features in Preview 1 and Preview 2, but I didn’t blog about them… sorry!

Skip Error Check for Web Cmdlets

Great addition by community member Vincent Damewood to allow skipping the internal HTTP response error check within the web cmdlets. This means that you can now handle the web error yourself including getting the response object as well as the HTTP response headers whereas previously you would have to get it from the resulting error object.

Null Conditional Member Property and Method Access

This is a new language feature that allows you to skip checking if a variable is $null before indexing into the variable, calling a method, or accessing a property. For properties, PowerShell will already allow accesing properties of $null, but this new syntax makes it more clear the intent in the script. Note that because PowerShell allows variable names to end with a question mark, you must use braces around the variable name

Extended Unix Filesystem Information

For users of PowerShell on Linux and macOS, they may miss some of the additional information of the filesystem provided by ls -l (long form of a directory listing). This new feature makes that information available using Get-ChildItem so you are no longer missing any useful information.

Windows PowerShell Compatibility in Preview 6

This release also improves the compatibility of PowerShell 7 with Windows PowerShell 5.1. We’ve brought back many existing cmdlets from Windows PowerShell 5.1 thanks to .NET Core 3! In addition, we have a new feature included with PowerShell 7 that encapsulates the Windows Compatibility Module (more on that below!).

Clipboard Cmdlets

Get-Clipboard and Set-Clipboard are back! Not only are they available again, but they are cross platform compatible which means you can use them on Linux (requires xclip to be installed) and macOS. Note that only text is supported at this time even on Windows.

Performance Counter Cmdlets

Get-Counter is back allowing you to get Windows performance counter information. Note that Import-Counter and Export-Counter cmdlets are not supported in PowerShell 7.

Graphical Tools Cmdlets

With .NET Core 3.0 bringing back WPF support on Windows, we’ve been able to bring back some popular graphical tools. Out-GridView gives a dynamic table view of results in a pipeline with sorting and filtering capabilities and when used with -PassThru can be used interactively within a pipeline to select objects to send back to the pipeline. Show-Command gives a graphical view of a command including parameter sets, parameters, switches, etc… Finally, Get-Help -ShowWindow works again to give a graphical view of PowerShell help content.

Update-List, Out-Printer, and Clear-RecycleBin cmdlets

Update-List allows adding/removing items from a property value that contains a collection of objects within a pipeline. This cmdlet is cross-platform compatible.

Out-Printer sends a PowerShell object to the printer. This cmdlet is only supported on Windows currently.

Clear-RecycleBin empties the recycle bin and is currently only supported on Windows.

Test-Connection Improvements

The original implementation of Test-Connection in Windows PowerShell relied on WMI which made it not cross-platform compatible.

Community member and PowerShell repo maintainer Ilya Sazonov ported the cmdlet to work against .NET Core APIs in PowerShell Core 6 making it work cross-platform. However, this also changed the user experience.

For PowerShell 7, Joel Sallow, another community member made improvements to this cmdlet and also getting back to similar experience as the original cmdlet in Windows PowerShell.

Import Windows PowerShell Modules in PS7

For PowerShell Core 6, we introduced the Windows Compatibility Module to allow importing Windows PowerShell modules that were not compatible with PowerShell Core 6 leveraging WinRM and implicit remoting.

In PowerShell 7, we have included this functionality into Import-Module directly without relying on WinRM, but does rely on Windows PowerShell 5.1 (it won’t work if Windows PowerShell 5.1 is not available).

Basically, for modules in the System32 folder, if the module manifest doesn’t indicate that module is compatible with Core then that module will be loaded in a Windows PowerShell process and using implicit remoting reflected into your PowerShell 7 session.

More details of this feature along with other information regarding Windows PowerShell compatibility in general coming in a separate blog post.

Closing

These are the last of the big changes coming in PowerShell 7 as we heads toward a Release Candidate next month. Please try out this preview and report issues in our GitHub repo as we still have opportunity to fix existing bugs as well as new bugs introduced by these features.

Thanks!

Steve Lee
PowerShell Team

The post PowerShell 7 Preview 6 appeared first on PowerShell.

PowerShell Editor Services Roadmap

This post was originally published on this site

Over the last year we have committed to making the PowerShell editing experience in Visual Studio Code a rich and productive cross-platform alternative for the PowerShell ISE. To that end, we have focused on two primary areas: bringing the PSReadLine experience to the Integrated Console, and improving the stability of the extension while editing and debugging. The goal of this blog post is to walk through how we have made efforts in these key areas, and what our next steps are to follow through on these efforts.

Investments in the reliability of PowerShell in Visual Studio Code

Our number one user request for the PowerShell editing experience in Visual Studio Code is to improve the stability of the editor and debugger. Long-standing constraints in the original design of the PowerShell extension made it difficult to improve its robustness through incremental changes. Instead, over the last six months we prioritized work to re-architect the extension with an emphasis on stability.

Using the Omnisharp Project’s Common Language Server Protocol

Based on the maturity of OmniSharp we took advantage of the project’s common language server protocol implementation which is a .NET library. It is important to note that Omnisharp’s common LSP server library is distinct from Omnisharp which is largely synonymous with the C# LSP backend. While we do hope this Omnisharp port will improve your editing experience, do not expect it to provide additional .NET completions. Omnisharp’s architecture is more robust meaning that bugs that might once have been crashes will now be caught and logged. By leveraging this library we were able to greatly simplify our code and are now more compliant with language server protocol.
Ultimately, we believe that these changes will significantly reduce the number crashes of the extension and improve the performance overall. These changes shipped in the November 2019 release of the PowerShell Preview extension and will ship with the January 2020 release of the PowerShell extension.

Other features of the Omnisharp Port

  • Asynchronous message handling for increase in performance
  • CodeLens requests no longer depend on running PowerShell so IntelliSense hangs should reduce
  • Formatting is now handled directly by the language server

Hosted PSScriptAnalyzer

PSScriptAnalyser (PSSA) is a static code checker for PowerShell modules and scripts, which provides services like script diagnostics and formatting in the PowerShell extension. In our analysis of the PowerShell extension we found that PSScriptAnalyzer had a major impact on the performance of the extension overall so we have been investing in changes to how PSSA integrates with the PowerShell extension.
In the current architecture, the PowerShell extension must interface with PSSA through its cmdlets, which re-instantiate the PSSA engine on every invocation. Further, because we must use PowerShell cmdlet invocation for this, the PowerShell extension is forced to manage the overhead of PowerShell runspace management and command resolution to run PSSA. In scenarios like real-time diagnostics and formatting, this overhead has become a significant bottleneck for the extension. Instead, since PSSA is .NET code at heart, we are moving toward a model allowing direct hosting of PSSA in .NET, with management and invocation of the PSSA engine performed through a set of suitable public .NET APIs. Work on these APIs has entered into a validation and integration phase and we expect this improvement to ship with the January 2020 release of the PowerShell extension.

PSReadLine support in the Integrated Console

Full PSReadLine support has long been at the top of our list for feature requests. It has also been among our most difficult problems to solve because at its core it also required architectural changes in how the PowerShell extension manages threading and runspaces.
The additional challenge of trying to support both legacy versions of PowerShell and a range of platform distributions has caused this problem to continually be delayed. In January of 2019 we released a Preview version of the PowerShell extension which was built on .NET Standard thereby enabling us to support PSReadLine in the integrated console for Windows users on PowerShell Version 5.1 and above.

With PowerShell 7 delivering a fix in .NET Core 3.0 for the way POSIX terminal APIs are handled when starting new processes, we are finally able to move the PSReadLine support currently available in the PowerShell Preview extension into the stable PowerShell extension with support across platform distributions. We expect to ship this update in the same time frame as PowerShell 7 (targeted for January 2020).

Dropping support for PowerShell Versions 3 and 4

Support for PSReadLine in the PowerShell extension Integrated Console depends on changes made in PSReadLine since it moved to version 2.0, where it dropped support for PowerShell versions 3 and 4. In turn, we also made the difficult decision to no longer support PowerShell 3 and 4 in future updates of the extension. In making this decision we analyzed the use of these PowerShell versions and found that approximately 1% of PowerShell session in VSCode use one of these versions. In order to accommodate these use cases we will ship a final stable version of the extension with PowerShell version 3 and 4 support which can continue to be used. To use this version of the extension the user will still install the PowerShell extension through the VSCode marketplace. They will then need to use the extension settings to select their desired version.

DSC Resource Kit Release October 2019

This post was originally published on this site

DSC Resource Kit Release

We just released the DSC Resource Kit!

This release includes updates to 9 DSC resource modules. In the past 6 weeks, 91 pull requests have been merged and 41 issues have been closed, all thanks to our amazing community!

Special thanks to everyone who contributed to the Hacktoberfest effort to update xWebAdministration!!! This accounted for 26 of the pull requests closed this month.

The modules updated in this release are:

  • ActiveDirectoryDsc 4.2.0.0
  • ComputerManagementDsc 7.1.0.0
  • SharePointDsc 3.7.0.0
  • StorageDsc 4.9.0.0
  • xDnsServer .16.0.0
  • xDscResourceDesigner .13.0.0
  • xExchange .30.0.0
  • xHyper-V .17.0.0
  • xWebAdministration 3.0.0.0

For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.

Our latest community call for the DSC Resource Kit was last Wednesday, October 23. A recording of the call is posted on the PowerShell YouTube channel. You can join us for the next call at 12PM (Pacific time) on August 28th to ask questions and give feedback about your experience with the DSC Resource Kit.

Following this resource kit release, maintainers will begin publishing as soon as they are ready rather than holding 6 weeks to do a group release. In the next community call we will discuss progress and whether we need to do a November release or not. Be sure to follow the DSC Community on Twitter for live updates as modules release.

You can find more information about our progress as a community on the DSC Community page.

We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!

Please see our documentation here for information on the support of these resource modules.

Included in this Release

You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or CHANGELOG.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).

Module Name Version Release Notes
ActiveDirectoryDsc 4.2.0.0
  • Changes to ActiveDirectoryDsc
    • Resolved custom Script Analyzer rules that was added to the test framework.
    • Resolve style guideline violations for hashtables (issue 516).
  • Changes to ADReplicationSite
    • Added “Description” attribute parameter (issue 500).
    • Added Integration testing (issue 355).
    • Correct value returned for RenameDefaultFirstSiteName (issue 502).
  • Changes to ADReplicationSubnet
    • Added “Description” attribute parameter (issue 503)
    • Added Integration testing (issue 357)
  • Changes to ADReplicationSiteLink
    • Added Integration testing (issue 356).
    • Added ability to set “Options” such as Change Notification Replication (issue 504).
  • Changes to ActiveDirectoryDsc.Common
    • Fix Test-DscPropertyState Failing when Comparing $Null and Arrays. (issue 513)
ComputerManagementDsc 7.1.0.0
  • ComputerManagementDsc:
    • Update psd1 description – Fixes Issue 269.
  • Fix minor style issues with missing spaces between param statements and “(“.
  • SmbServerConfiguration:
    • New resource for configuring the SMB Server settings.
    • Added examples for SMB Server Configuration.
  • Minor corrections to CHANGELOG.MD.
  • ScheduledTask:
    • Fixed bug when description has any form of whitespace at beginning or end the resource would not go into state – Fixes Issue 258.
  • SmbShare:
    • Removal of duplicate code in Add-SmbShareAccessPermission helper function fixes Issue 226.
SharePointDsc 3.7.0.0
        • SPConfigWizard
          • Fixed issue with incorrect check for upgrade status of server
        • SPDistributedCacheService
          • Improved error message for inclusion of server name into ServerProvisionOrder parameters when Present or change to Ensure Absent
        • SPFarm
          • Removed SingleServer as ServerRole, since this is an invalid role.
          • Handle case where null or empty CentralAdministrationUrl is passed in
          • Move CentralAdministrationPort validation into parameter definition to work with ReverseDsc
          • Add NotNullOrEmpty parameter validation to CentralAdministrationUrl
          • Fixed error when changing developer dashboard display level.
          • Add support for updating Central Admin Authentication Method
        • SPFarmSolution
          • Fix for Web Application scoped solutions.
        • SPInstall
          • Fixes a terminating error for sources in weird file shares
          • Corrected issue with incorrectly detecting SharePoint after it has been uninstalled
          • Corrected issue with detecting a paused installation
        • SPInstallLanguagePack
          • Fixes a terminating error for sources in weird file shares
        • SPInstallPrereqs
          • Fixes a terminating error for sources in weird file shares
        • SPProductUpdate
          • Fixes a terminating error for sources in weird file shares
          • Corrected incorrect farm detection, added in earlier bugfix
        • SPSite
          • Fixed issue with incorrectly updating site OwnerAlias and SecondaryOwnerAlias
        • SPWebAppAuthentication
          • Fixes issue where Test method return false on NON-US OS.
StorageDsc 4.9.0.0
  • Disk:
    • Added Location as a possible value for DiskIdType. This will select the disk based on the Location property returned by Get-Disk
    • Maximum size calculation now uses workaround so that Test-TargetResource works properly – workaround for Issue 181.
  • DiskAccessPath:
    • Added Location as a possible value for DiskIdType. This will select the disk based on the Location property returned by Get-Disk
  • WaitForDisk:
    • Added Location as a possible value for DiskIdType. This will select the disk based on the Location property returned by Get-Disk
xDnsServer 1.16.0.0
  • Changes to XDnsServerADZone
    • Raise an exception if DirectoryPartitionName is specified and ReplicationScope is not Custom. (issue 110).
    • Enforce the ReplicationScope parameter being passed to Set-DnsServerPrimaryZone if DirectoryPartitionName has changed.
  • xDnsServer:
    • OptIn to the following Dsc Resource Meta Tests:
      • Common Tests – Relative Path Length
      • Common Tests – Validate Markdown Links
      • Common Tests – Custom Script Analyzer Rules
      • Common Tests – Required Script Analyzer Rules
      • Common Tests – Flagged Script Analyzer Rules
xDscResourceDesigner 1.13.0.0
  • Fix Parameter Blocks to conform to Dsc Style Guidlelines issue 79.
  • Fix README.md MarkDownLint Errors and Formatting Issues
xExchange 1.30.0.0
  • Resolved custom Script Analyzer rules that was added to the test framework.
  • Added xExchAcceptedDomain resource
  • Resolved hashtable styling issues
  • Added xExchRemoteDomain resource
xHyper-V 3.17.0.0
  • MSFT_xVMNetworkAdapter:
    • Added NetworkSettings to be able to statically set IPAddress.
    • Added option for Vlan tagging. You can now setup a Network Adapeter as an access switch on a specific Vlan.
xWebAdministration 3.0.0.0
  • Changes to xWebAdministration
    • Changes to PULL_REQUEST_TEMPLATE.md
      • Improving descriptive text around the CHANGELOG.md entry.
      • Adding note that entry in CHANGELOG.md is mandatory for all PRs.
    • Resolved custom Script Analyzer rules that was added to the test framework.
    • Moved change log from README.md to a separate CHANGELOG.md (issue 446).
    • Remove example “Creating the default website using configuration data” from README.md (issue 488).
    • Removed examples README.md as it was obsolete (issue 482).
    • Updated Ensure property description for xIisHandler resource to match schema.mof
    • Moved examples from Readme.md to respective /Examples/Resources/ folders (issue 486).
    • Created new folder structure for examples so that examples will be placed in /Examples/Resources/$resourceName (issue 483).
    • Added a table of contents for the resource list (issue 450).
    • Alphabetized the resource list in the README.md (issue 449).
    • Optimized exporting in the module manifest for best performance (issue 448).
    • Updated hashtables in the repo to adhere to the style guidelines described at https://github.com/PowerShell/DscResources/blob/master/StyleGuidelines.mdcorrect-format-for-hashtables-or-objects (issue 524)
    • Moved example Sample_EndToEndxWebAdministration from readme.md to a separate .ps1 in /examples/ (issue 491)
    • Removed example “Create and configure an application pool” from README.md (issue 489).
  • Changes to xIisHandler
    • Updated schema.mof to include descriptions for each property (issue 453).
    • Moved MSFT_xIisHandler localization strings to strings.psd1 (issue 463).
  • Changes to xWebSite
    • Fix Get-TargetResource so that LogFlags are returned as expected array of strings (one for each flag) rather than an array containing a single comma-separated string of flags” (issue 332).
    • Moved localization strings to strings.psd1 file (issue 475)
    • Updated schema.mof so that each property has an appropriate description (issue 456).
    • Updated schema.mof and README so that SourceType and SourceName properties for MSFT_xLogCustomFieldInformation are associated with the appropriate descriptions and valuemaps/values (issue 456).
    • Move examples from README.md to resource examples folder (issue 487).
    • Fix case of resource name from xWebsite to xWebSite (issue 535).
  • Changes to xIISLogging
    • Fix Get-TargetResource so that LogFlags are returned as expected array of strings (one for each flag) rather than an array containing a single comma-separated string of flags (issue 332).
    • Moved MSFT_xIisLogging localization strings to strings.psd1 (issue 464).
  • Changes to xSslSettings
    • Updated casing of xSslSettings in all file names, folder names, schema, and documentation (issue 461).
    • Updated casing of xSslSettings in all file names, folder names, schema, and documentation (issue 536).
    • Moved MSFT_xSslSettings localization strings to strings.psd1 (issue 467).
  • Changes to xWebConfigKeyValue
    • Updated schema.mof to include a description for the Ensure property (issue 455).
    • Move localization strings to strings.psd1 file (issue 472).
  • Changes to xWebAppPoolDefaults
    • Move localization strings to strings.psd1 file (issue 470).
    • BREAKING CHANGE: Changed ApplyTo key parameter to IsSingleInstance to bring the resource into compliance with published best practices (issue 462).
  • Changes to xWebApplication
    • Move localization strings to strings.psd1 file (issue 468)
    • Add description on class MSFT_xWebApplicationAuthenticationInformation (issue 454).
  • Changes to xIisModule entry
    • Moved xIisModule localization strings to strings.psd1 (issue 466).
  • Changes to xIisMimeTypeMapping
    • Moved MSFT_xIisMimeTypeMapping localization strings to strings.psd1 (issue 465).
  • Changes to xWebVirtualDirectory
    • Moved MSFT_xWebVirtualDirectory localization strings to strings.psd1 (issue 477).
  • Changes to xWebSiteDefaults
    • Move localization strings to strings.psd1 file (issue 475).
    • BREAKING CHANGE: Changed ApplyTo key parameter to IsSingleInstance to bring the resource into compliance with published best practices (issue 457).
    • Fix case of resource name from xWebsiteDefaults to xWebSiteDefaults (issue 535).
  • Changes to xWebConfigProperty
    • Move localization strings to strings.psd1 file (issue 473).
  • Changes to xWebConfigPropertyCollection
    • Move localization strings to strings.psd1 file (issue 474).
  • Changes to xIisFeatureDelegation
    • Moved MSFT_xIisFeatureDelegation localization strings to strings.psd1 (issue 459).
  • Changes to xWebAppPool
    • Moved MSFT_xWebAppPool localization strings to strings.psd1 (issue 469).

How to Find Released DSC Resource Modules

To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.

Of course, you can also always use PowerShellGet (available starting in WMF 5.0) to find modules with DSC Resources:

# To list all modules that tagged as DSCResourceKit
Find-Module -Tag DSCResourceKit 
# To list all DSC resources from all sources 
Find-DscResource

Please note only those modules released by the PowerShell Team are currently considered part of the ‘DSC Resource Kit’ regardless of the presence of the ‘DSC Resource Kit’ tag in the PowerShell Gallery.

To find a specific module, go directly to its URL on the PowerShell Gallery:
http://www.powershellgallery.com/packages/< module name >
For example:
http://www.powershellgallery.com/packages/xWebAdministration

How to Install DSC Resource Modules From the PowerShell Gallery

We recommend that you use PowerShellGet to install DSC resource modules:

Install-Module -Name < module name >

For example:

Install-Module -Name xWebAdministration

To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:

Update-Module

After installing modules, you can discover all DSC resources available to your local system with this command:

Get-DscResource

How to Find DSC Resource Modules on GitHub

All resource modules in the DSC Resource Kit are available open-source on GitHub.
You can see the most recent state of a resource module by visiting its GitHub page at:
https://github.com/PowerShell/< module name >
For example, for the CertificateDsc module, go to:
https://github.com/PowerShell/CertificateDsc.

All DSC modules are also listed as submodules of the DscResources repository in the DscResources folder and the xDscResources folder.

How to Contribute

You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones.
See our contributing guide for more info on how to become a DSC Resource Kit contributor.

If you would like to help, please take a look at the list of open issues for the DscResources repository.
You can also check issues for specific resource modules by going to:
https://github.com/PowerShell/< module name >/issues
For example:
https://github.com/PowerShell/xPSDesiredStateConfiguration/issues

Your help in developing the DSC Resource Kit is invaluable to us!

Questions, comments?

If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.

Michael Greene
Principal Program Manager
PowerShell DSC Team
@migreene (Twitter)
@mgreenegit (GitHub)

The post DSC Resource Kit Release October 2019 appeared first on PowerShell.

PowerShell 7 Preview 5

This post was originally published on this site

Today we shipped PowerShell 7 Preview5! This release contains a number of new features and many bug fixes from both the community as well as the PowerShell team. See the Release Notes for all the details of what is included in this release.

We are still on track to have one more preview release next month in November. Then, barring any quality concerns, a Release Candidate in December aligned with the .NET Core 3.1 final release. Finally, we expect General Availability of PowerShell 7 in January as our first Long Term Servicing release.

Between the Release Candidate and General Availability, we will only accept critical bug fixes and no new features will be included. For that release, some Experimental Features will be considered design stable and no longer be Experimental. This means that any future design changes for those features will be considered a breaking change.

New Features in Preview 5

This release has a number of new features from both the community as well as the PowerShell team. Remember that preview releases of PowerShell are installed side-by-side with stable versions so you can use both and provide us feedback on previews for bugs and also on experimental features.

You can read about new features in previous preview releases:

There were new features in Preview 1 and Preview 2, but I didn’t blog about them… sorry!

Chain operators

The new Pipeline Chain Operators allow conditional execution of commands depending on whether the previous command succeeded for failed. This works with both native commands as well as PowerShell cmdlets or functions. Prior to this feature, you could already do this by use of if statements along with checking if $? indicated that the last statement succeeded or failed. This new operator makes this simpler and consistent with other shells.

img

Null conditional operators for coalescing and assignment

Often in your scripts, you may need to check if a variable is $null or if a property is $null before using it. The new Null conditional operators makes this simpler.

The new ?? null coalescing operator removes the need for if and else statements if you want to get the value of a statement if it’s not $null or return something else if it is $null. Note that this doesn’t replace the check for a boolean value of true or false, it’s only checking if it’s $null.

The new ??= null conditional assignment operator makes it easy to assign a variable a value only if it’s not $null.

img

New PowerShell version notification

Our telemetry available in our PowerBI Dashboard indicates some set of users are still using older versions (sometimes older previews of released stable versions!). This new feature will inform you on startup if a new preview version is available (if you are using a preview version) or if a new stable version is available to keep you up-to-date on the latest servicing release which may contain security fixes. Because this is new, you won’t see this in action until Preview 6 comes out.

More details of this feature including how to disable it in the Notification on Version Update RFC

img

Tab completion for variable assignment

This new feature will allow you to use tab completion on variable assignment and get allowed values for enums or variables with type constraints like [ValidateSet()]. This makes it easy to change $ErrorActionPreference or the new $ErrorView (detailed below) to valid values without having to type them out.

img

Format-Hex improved formatting

This improvement comes from Joel Sallow making Format-Hex more useful when viewing different types of objects in a pipeline as well as supporting viewing more types of objects.

img

Get-HotFix is back

The Get-HotFix cmdlet only works on Windows and will query the system on what patches have been installed. This was previously unavailable in PowerShell Core 6 because it depended on System.Management namespace which wasn’t available on .NET Core 2.x which PowerShell Core 6.x is built on. However, .NET Core 3.0 which PowerShell 7 is built on brought back this namespace (for Windows only) so we re-enabled this cmdlet.

There is a delay getting results in this example due to the number of patches I have on my Windows 7 VM.

img

Select-String adds emphasis

This was a HackIllinois project by Derek Xia that uses inverse colored text to highlight the text in a string that matches the selection criteria. There is an optional -NoEmphasis switch to suppress the emphasis.

img

ConciseView for errors

Some user feedback we’ve consistently received is about the amount of red text you get when you encounter an error in PowerShell.

The $ErrorView preference variable allows you to change the formatting of errors. Previously, it supported NormalView (the default) as well as a more terse CategoryView. This feature adds a ConciseView where most commands return just the relevant error message. In cases where there is additional contextual information in a script file or the location in a script block, you get the line number, the line of text in question, and a pointer to where the error occurred.

This new view is part of the Update Error View RFC so please provide feedback there!

img

Get-Error cmdlet

While ConciseView gives you more precise, but limited information on errors, we added a new cmdlet Get-Error to get much richer information on errors.

By default, just running Get-Error shows a formatted view of the most recent error including showing specific nested types like Exceptions and ErrorRecords making it easier to diagnose what went wrong.

This new cmdlet is part of the Update Error View RFC so please provide feedback there!

img

Closing

We have one more preview planned for November with a few more features coming from the PowerShell team as well as the PowerShell community!

Steve Lee
PowerShell Team

The post PowerShell 7 Preview 5 appeared first on PowerShell.

DSC Resource Kit Release September 2019

This post was originally published on this site

We just released the DSC Resource Kit!

This release includes updates to 15 DSC resource modules. In the past 6 weeks, 160 pull requests have been merged and 68 issues have been closed, all thanks to our amazing community!

The modules updated in this release are:

  • ActiveDirectoryCSDsc 4.1.0.0
  • ActiveDirectoryDsc 4.1.0.0
  • ComputerManagementDsc 7.0.0.0
  • DFSDsc 4.4.0.0
  • NetworkingDsc 7.4.0.0
  • SecurityPolicyDsc 2.10.0.0
  • SqlServerDsc 13.2.0.0
  • xDnsServer 1.15.0.0
  • xExchange 1.29.0.0
  • xFailOverCluster 1.13.0.0
  • xPSDesiredStateConfiguration 8.10.0.0
  • xRemoteDesktopSessionHost 1.9.0.0
  • xSCSMA 2.1.0.0
  • xWebAdministration 2.8.0.0

For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.

Our latest community call for the DSC Resource Kit was last Wednesday, September 11. A recording of the call is posted on the PowerShell YouTube channel. You can join us for the next call at 12PM (Pacific time) on August 28th to ask questions and give feedback about your experience with the DSC Resource Kit.

The next DSC Resource Kit release will be on Wednesday, October 9.

We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!

Please see our documentation here for information on the support of these resource modules.

Included in this Release

You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or CHANGELOG.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).

Module Name Version Release Notes
ActiveDirectoryCSDsc 4.1.0.0
  • AdcsCertificationAuthoritySettings:
    • Fix grammar in the resource README.md.
  • Fix minor style issues in statement case.
ActiveDirectoryDsc 4.1.0.0
    • We could not add the change log to the release notes due to the length of the change log. What have change in this release can be found here

https://github.com/PowerShell/ActiveDirectoryDsc/blob/dev/CHANGELOG.md#4100

    .
ComputerManagementDsc 7.0.0.0
  • ScheduledTask:
    • Better compatibility with Group LogonType when passing BuiltIn groups through ExecuteAsCredential
      • Primary use case is “BUILTINUsers”
      • Use the ExecuteAsCredential property to pass the username The PSCredential needs a non-null that is ignored
    • Delay property not handled properly on AtLogon and AtStartup trigger – Fixes Issue 230
    • Changed Get-ScheduledTask calls to ScheduledTasksGet-ScheduledTask to avoid name clash with Carbon module. Fixes Issue 248
    • Cast MultipleInstances value returned by Get-TargetResource to string – fixes Issue 255
  • PendingReboot:
    • Migrated xPendingReboot from xPendingReboot and renamed to PendingReboot.
    • Converted to meet HQRM guidelines – Fixes Issue 12.
    • Changed SkipCcmClientSDK parameter to default to $true – Fixes Issue 13.
    • Fixed Test-TargetResource so that if ConfigMgr requires a reboot then the pending reboot will be set – Fixes Issue 26.
    • Refactored Test-TargetResource to reduce code duplication and move to a data driven design.
    • Refactored Get-TargetResource by adding a new function Get-PendingRebootState so that Test-TargetResource no longer needed to use Get-TargetResource. This eliminated the need to include write parameters in Get-TargetResource.
    • Converted the call to Invoke-WmiMethod to Invoke-CimMethod.
    • Deleted the code that removes the regRebootLocations variable at the end of the resource as it appears to serve no purpose.
  • Correct all tests to meet Pester 4.0 standards.
  • RemoteDesktopAdmin:
    • New resource for configuring Remote Desktop for Administration – fixes Issue 224.
  • Updated common function Test-DscParameterState to support ordered comparison of arrays by copying function and tests from NetworkingDsc – fixes Issue 250.
  • BREAKING CHANGE: ScheduledTask:
    • Correct output type of DaysInterval,StartTime,WeeksDaysOfWeek, and WeeksInterval parameters from Get-TargetResource to match MOF.
    • Refactored Get-TargetResource to remove parameters that are not key or required – fixes Issue 249.
    • Added function Test-DateStringContainsTimeZone to determine if a string containing a date time includes a time zone.
    • Enable verbose preference to be passed through to Test-DscParameterState.
    • Changed Test-TargetResource so that StartTime is only compared for trigger types Daily,Weekly or Once.
  • Fix minor style issues in statement case.
DFSDsc 4.4.0.0
  • Fix example publish to PowerShell Gallery by adding gallery_api environment variable to AppVeyor.yml – fixes Issue 91.
  • Fix minor style issues in statement case.
NetworkingDsc 7.4.0.0
  • Added Comment Based Help for New-NotImplementedException common function – fixes Issue 411.
  • Added common function “Format-Win32NetworkADapterFilterByNetConnectionID” to properly accept wild cards for Win32_NetworkAdapter filters.
  • Updated MSFT_Netbios to use “Format-Win32NetworkADapterFilterByNetConnectionID”
  • Corrected minor style and consistency issues in NetworkingDsc.Common.tests.ps1 and NetworkingDsc.Common.ps1.
  • Changed verbose messages in Test-DscParameterState to include full type name.
  • Fixed bug in Test-DscParameterState that causes it to return true when both the current array and desired array is empty.
  • Fix minor style issues in statement case.
SecurityPolicyDsc 2.10.0.0
  • Changes to SecurityPolicyDsc
    • Opt-in to the following DSC Resource Common Meta Tests:
      • Common Tests – Validate Module Files
      • Common Tests – Validate Script Files
      • Common Tests – Validate Markdown Files
      • Common Tests – Required Script Analyzer Rules
      • Common Tests – Flagged Script Analyzer Rules
      • Common Tests – New Error-Level Script Analyzer Rules
      • Common Tests – Custom Script Analyzer Rules
      • Common Tests – Validate Markdown Links
      • Common Tests – Relative Path Length
      • Common Tests – Validate Example Files
      • Common Tests – Validate Example Files To Be Published
    • Fix keywords to lower-case to align with guideline.
SqlServerDsc 13.2.0.0
  • Changes to SqlServerDsc
    • Fix keywords to lower-case to align with guideline.
    • Fix keywords to have space before a parenthesis to align with guideline.
xDnsServer 1.15.0.0
xExchange 1.29.0.0
  • Enable Script Analyzer default rules
  • Fixed keywords in upper case
xFailOverCluster 1.13.0.0
  • Updated the xCluster test method to return true if a node is joined to the cluster but is in a Paused state.
xPSDesiredStateConfiguration 8.10.0.0
  • Changes to xPSDesiredStateConfiguration
    • Fix keywords to lower-case to align with guideline.
  • Added SMB PullServer support for publishing.
xRemoteDesktopSessionHost 1.9.0.0
  • Changes to xRDRemoteApp
    • Fixing typo in parameter name when calling the function ValidateCustomModeParameters (issue 50).
  • Changes to xRDSessionDeployment
    • When RDMS service does not exist the Get-TargetResource will no longer throw an error (issue 47).
  • Rename Tests/Unit folder to use upper case on first letter.
  • Update appveyor.yml to use the default template.
  • Added default template files .codecov.yml, .gitattributes, and .gitignore, and .vscode folder.
  • xRDSessionCollectionConfiguration:
    • Changed CollectionName variable validation max length to 256
  • xRDSessionCollection
    • Changed CollectionName variable validation max length to 256
  • xRDRemoteApp
    • Changed CollectionName variable validation max length to 256
xSCSMA 2.1.0.0
  • Update appveyor.yml to use the default template.
  • Added default template files .codecov.yml, .gitattributes, and .gitignore, and .vscode folder.
  • Closed issue 29 – Web bindings fail due to hardcoded WSE
  • Switched from Get-WmiObject Win32_Product to Get-ItemProperty for identifer number
xWebAdministration 2.8.0.0
  • Fix multiple HTTPS bindings on one xWebsite receiving the first binding”s certificate 332
    • Added unit regression test
  • Changes to xWebsite
    • Added ServerAutoStart (controls website autostart) and changed documentation for ServiceAutoStartEnabled (controls application auto-initialization). Fixes 325.
    • Fix multiple HTTPS bindings on one xWebsite receiving the first binding”s certificate 332
      • Added unit regression test
    • Changes to xWebAppPool
      • Fix false Test-TargetResource failure for logEventOnRecycle if items in the Configuration property are specified in a different order than IIS natively stores them 434
    • Changes to xIisModule
      • Fixed the parameters specification for the internal Get-IISHandler and Remove-IISHandler function

How to Find Released DSC Resource Modules

To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.

Of course, you can also always use PowerShellGet (available starting in WMF 5.0) to find modules with DSC Resources:

# To list all modules that tagged as DSCResourceKit
Find-Module -Tag DSCResourceKit 
# To list all DSC resources from all sources 
Find-DscResource

Please note only those modules released by the PowerShell Team are currently considered part of the ‘DSC Resource Kit’ regardless of the presence of the ‘DSC Resource Kit’ tag in the PowerShell Gallery.

To find a specific module, go directly to its URL on the PowerShell Gallery:
http://www.powershellgallery.com/packages/< module name >
For example:
http://www.powershellgallery.com/packages/xWebAdministration

How to Install DSC Resource Modules From the PowerShell Gallery

We recommend that you use PowerShellGet to install DSC resource modules:

Install-Module -Name < module name >

For example:

Install-Module -Name xWebAdministration

To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:

Update-Module

After installing modules, you can discover all DSC resources available to your local system with this command:

Get-DscResource

How to Find DSC Resource Modules on GitHub

All resource modules in the DSC Resource Kit are available open-source on GitHub.
You can see the most recent state of a resource module by visiting its GitHub page at:
https://github.com/PowerShell/< module name >
For example, for the CertificateDsc module, go to:
https://github.com/PowerShell/CertificateDsc.

All DSC modules are also listed as submodules of the DscResources repository in the DscResources folder and the xDscResources folder.

How to Contribute

You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones.
See our contributing guide for more info on how to become a DSC Resource Kit contributor.

If you would like to help, please take a look at the list of open issues for the DscResources repository.
You can also check issues for specific resource modules by going to:
https://github.com/PowerShell/< module name >/issues
For example:
https://github.com/PowerShell/xPSDesiredStateConfiguration/issues

Your help in developing the DSC Resource Kit is invaluable to us!

Questions, comments?

If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.

Michael Greene
Principal Program Manager
PowerShell DSC Team
@migreene (Twitter)
@mgreenegit (GitHub)

The post DSC Resource Kit Release September 2019 appeared first on PowerShell.

PowerShell 7 Preview 4

This post was originally published on this site

We continue to make progress towards our PowerShell 7 release which currently is targeting December 2019 for a Release Candidate and January 2020 for General Availability and will be our first LTS (Long Term Servicing) release!

Please see the previous blog post on Preview 3 for more details about LTS and also Windows PowerShell compatibility.

Preview 4 contains a number of bug fixes, but also new features which I’ll cover in this blog post.

New Features in Preview 4

This is just a small part of the entire changelog. New experimental features in this preview from the community and also the PowerShell team:

Ternary Operator

The ternary operator is popular among C# developers due to its terseness which can improve readability if you are familiar with this operator.

This operator is completely opt-in so if you prefer to use if..else instead, you can certainly continue to do that.

gif

Start-Job -WorkingDirectory

Those of you familiar with the Start-Job cmdlet will have encountered that the new PowerShell process started to handle the job will have different working directory on Windows PowerShell and PowerShell Core and it can sometimes be not what you expected. This parameter was added to allow you to specify the working directory of the new job process before your script block runs!

gif

$ErrorActionPreference = “Break”

This feature comes from a well known PowerShell MVP Kirk Munro. Basically, if you set $ErrorActionPreference to Break, then when there is an error it will drop you into the debugger immediately!

gif

Invoke-DscResource

With this change, you can now leverage DSC Resources while by-passing the LCM (Local Configuration Manager). This means that you can author your own LCM or simply leverage existing DSC Resources within your scripts and this also works cross platform!

Note that binary DSC Resources are not supported!

gif

DSC Configuration Compilation

Previously if you authored a DSC Configuration script, you would need to use a Windows machine to compile it to a mof file to deploy onto your managed node. Starting with Preview4, you can now perform DSC compilation on non-Windows systems.

Note that this is work in progress with some known issues.

gif

Testing the MSIX package

Recently, we started publishing a MSIX package for Windows. This will eventually allow us to publish PowerShell 7 to the Windows Store. For now, if you wish to try out this package, you must be in Developer Mode and use Add-AppxPackage to install it. Double clicking it from the Windows Shell will not allow you to install the developer signed package.

Closing

Although this blog post focuses on new features, this release also contains many bug fixes as well as targeted performance improvements.

You can always get the latest version of PowerShell from https://aka.ms/get-powershell.

Expect more new features from the community and the PowerShell team in future Preview releases!

Steve Lee
PowerShell Team

The post PowerShell 7 Preview 4 appeared first on PowerShell.

Release of PowerShell Script Analyzer (PSScriptAnalyzer) 1.18.2

This post was originally published on this site

In keeping with the tradition of releasing improvements to PSScriptAnalyzer more often, we’re happy to announce that 1.18.12 is now available! As a dependency of PowerShell Editor Services (a module used by editor extensions like the PowerShell Visual Studio Code extension), this release is motivated by a desire to further stabilize our editor experience. At the moment, the Visual Studio Code PowerShell extension still ships with PSScriptAnalyzer 1.18.0. After fixing some undesirable edge cases between 1.18.1 and 1.18.2, we intend to ship an update to the Visual Studio Code extension that will include 1.18.2.

The blocking issue that it resolves is quite technical and should not concern end-users, but for those who are interested: starting with1.18.1, a performance optimization was added whereby we started to share and cache a PowerShell runspace pool instead of creating a new one for every command invocation. However, it turns out that there is an edge case where, when dealing with specific commands from thePackageManagementmodule, the runspace pool can get into a deadlock, which causes the execution of PSScriptAnalyzer to hang indefinitely. This is due to a bug inPackageManagementitself (a very unfortunate asynchronous API call that leads to the deadlock) but also PowerShell itself, which should be able to handle bad scenarios like this. Therefore, a workaround for this had to be implemented in PSScriptAnalyzer by blacklisting the PackageManagement commands.

Given that the other changes in this release are mainly fixes and small enhancements, we decided to not bump the minor version number. We ask that the community participate in testing and giving feedback on this update before it ships by default in the Visual Studio Code extension. You can make this new update with the Visual Studio Code extension start by executing the following command:

Install-Module -Name PSScriptAnalyzer -Repository PSGallery -Scope CurrentUser

Should you find that there are changes that you are not happy with, please report them here.

Optionally, you can roll back to the default included version of PSScriptAnalyzer by running Uninstall-Module -Name PSScriptAnalyzer.

In this release, we’ve made the following fixes

  • PipelineIndentation: More edge cases when using non-default values of this setting (NoIndentation in the Visual Studio Code extension) were fixed. This feature was only introduced in1.18.0and we hope the be closer to a state now where we could potentially change the default.
  • New compatibility rule profiles were added for non-Windows OSs on PowerShell 7 (preview). Additionally, fixes were made to profile generation to support macOS and Linux.
  • A fix was made to PSCloseBrace to correctly flag the closing brace of a one-line hashtable, correcting some broken formatting.

Enhancements were made in the following areas

  • When using settings files, error messages are now much more actionable.
PS> Invoke-ScriptAnalyzer -Settings /tmp/MySettings.psd1 -ScriptDefinition 'gci'

Invoke-ScriptAnalyzer : includerule is not a valid key in the settings hashtable.
Valid keys are CustomRulePath, ExcludeRules, IncludeRules, IncludeDefaultRules,
RecurseCustomRulePath, Rules and Severity. 
...

  • PSScriptAnalyzer has a logo now thanks to the community member @adilio
  • The formatter was enhanced to also take commented lines into account in multi-line commands
  • The formatter was enhanced to optionally allow correction of aliases as well. With this change, a setting in the Visual Studio Code extension will soon be made available to configure this. By default, this setting will not be on for the moment. We are open to feedback: while there are very likely a few people that would love for it to be enabled, it may upset others.
  • UseDeclaredVarsMoreThanAssignmentsnow also takes into account the usage of Get-Variable with an array of variables and usage of the named parameter -Name

We’ve also made some changes in our GitHub repository and changed the default branch from development to master to simplify the development workflow and be consistent with other repositories in the PowerShell organization. If you have a fork of the project, you will need to make this change in your fork as well or remember to use master as a base and open pull requests against master. This also means that the next version of the Visual Studio Code extension will point tomasterfor the documentation of PSScriptAnalyzer’s rules.

The Changelog has more details if you want to dig further.

Future Directions

We are thinking of following an approach similar to the Visual Studio Code extension where we make a version 2.0 at that drops support for PowerShell version 3 and 4. One of the next changes could be to improve how PowerShellEditorServices calls into PSScriptAnalyzer: currently, Editor Services uses the PSScriptAnalyzer PowerShell cmdlets which means that we have to create an entire instance of PowerShell for these invocations. Knowing that bothPowerShellEditorServicesandPSScriptAnalyzerare binary .NET modules, we could directly call into PSScriptAnalyzer’s .NET code by publishing a NuGet package of PSScriptAnalyzer with suitable public APIs. Given that PSScriptAnalzyer currently performs a conditional compilation for each PowerShell version (3, 4, 5, and 6+), dropping support for version 4 and 5 could help make the aforementioned move to an API model much easier to implement. Please give feedback if your use case ofPSScriptAnalyzerwould be impacted by this.

On behalf of the Script Analyzer team,

Christoph Bergmeister, Project Maintainer from the community, BJSS
Jim Truher, Senior Software Engineer, Microsoft

The post Release of PowerShell Script Analyzer (PSScriptAnalyzer) 1.18.2 appeared first on PowerShell.

PowerShell ForEach-Object Parallel Feature

This post was originally published on this site

PowerShell ForEach-Object Parallel Feature

PowerShell 7.0 Preview 3 is now available with a new ForEach-Object Parallel Experimental feature. This feature is a great new tool for parallelizing work, but like any tool, it has its uses and drawbacks.

This article describes this new feature, how it works, when to use it and when not to.

What is ForEach-Object -Parallel?

ForEach-Object -Parallel is a new parameter set added to the existing PowerShell ForEach cmdlet.

ForEach-Object -Parallel <scriptblock> [-InputObject <psobject>] [-ThrottleLimit <int>] [-TimeoutSeconds <int>] [-AsJob] [-WhatIf] [-Confirm] [<CommonParameters>]

 

Normally, when you use the ForEach-Object cmdlet, each object piped to the cmdlet is processed sequentially.

PS C:> 1..5 | ForEach-Object { "Hello $_"; sleep 1 } Hello 1 Hello 2 Hello 3 Hello 4 Hello 5 PS C:> (Measure-Command { 1..5 | ForEach-Object { "Hello $_"; sleep 1 } }).Seconds 5

But with the new ForEach-Object -Parallel parameter set, you can run all script in parallel for each piped input object.

PS C:> 1..5 | ForEach-Object -Parallel { "Hello $_"; sleep 1; } -ThrottleLimit 5
Hello 1
Hello 3
Hello 2
Hello 4
Hello 5

PS C:> (Measure-Command { 1..5 | ForEach-Object -Parallel { "Hello $_"; sleep 1; } -ThrottleLimit 5 }).Seconds
1

Because each script block in the ForEach-Object example above takes 1 second to run, running all five in parallel takes only one second instead of 5 seconds when run sequentially.

Since the script blocks are run in parallel for each of the 1-5 piped input integers, the order of execution is not guaranteed. The -ThrottleLimit parameter limits the number of script blocks running in parallel at a given time, and its default value is 5.

This new feature also supports jobs, where you can choose to have a job object returned instead of having results written to the console.

PS C:> $Job = 1..5 | ForEach-Object -Parallel { "Hello $_"; sleep 1; } -ThrottleLimit 5 -AsJob PS C:> $job | Wait-Job | Receive-Job Hello 1 Hello 2 Hello 3 Hello 5 Hello 4

ForEach-Object -Parallel is not the same as the foreach language keyword

Don’t confuse ForEach-Object cmdlet with PowerShell’s foreach keyword. The foreach keyword does not handle piped input but instead iterates over an enumerable object. There is currently no parallel support for the foreach keyword.

PS C:> foreach ($item in (1..5)) { "Hello $item" }
Hello 1
Hello 2
Hello 3
Hello 4
Hello 5

How does it work?

The new ForEach-Object -Parallel parameter set uses existing PowerShell APIs for running script blocks in parallel. These APIs have been around since PowerShell v2, but are cumbersome and difficult to use correctly. This new feature makes it much easier to run script blocks in parallel. But there is a fair amount of overhead involved and many times there is no gain in running scripts in parallel, and in fact it can end up being significantly slower than running ForEach-Object normally.

PowerShell currently supports parallelism in three main categories.

  1. PowerShell remoting. Here PowerShell sends script to external machines to run, using PowerShell’s remoting system.
  2. PowerShell jobs. This is the same as remoting except that script is run in separate processes on the local machine, rather than on external machines.
  3. PowerShell runspaces. Here script is run on the local machine within the same process but on separate threads.

This new feature uses the third method for running scripts in parallel. It has the least overhead of the other two methods and does not use the PowerShell remoting system. So it is generally much faster than the other two methods.

However, there is still quite a bit of overhead to run script blocks in parallel. Script blocks run in a context called a PowerShell runspace. The runspace context contains all of the defined variables, functions and loaded modules. So initializing a runspace for script to run in takes time and resources. When scripts are run in parallel they must be run within their own runspace. And each runspace must load whatever module is needed and have any variable be explicitly passed in from the calling script. The only variable that automatically appears in the parallel script block is the piped in object. Other variables are passed in using the $using: keyword.

$computers = 'computerA','computerB','computerC','computerD'
$logsToGet = 'LogA','LogB','LogC'

# Read specified logs on each machine, using custom module
$logs = $computers | ForEach-Object -ThrottleLimit 10 -Parallel {
    Import-Module MyLogsModule
    Get-Logs -ComputerName $_ -LogName $using:logsToGet
}

Given the overhead required to run scripts in parallel, the -ThrottleLimit becomes very useful to prevent the system from being overwhelmed. There are some cases where running a lot of script blocks in parallel makes sense, but also many cases where it does not.

When should it be used?

There are two primary reasons to run script blocks in parallel with the ForEach-Object -Parallel feature (keeping in mind that this feature runs the script on separate system threads).

  1. Highly compute intensive script. If your script is crunching a lot of data over a significant period of time and the scripts can be run independently, then it is worthwhile to run them in parallel. But only if the machine you are running on has multiple cores that can host the script block threads. In this case the -ThrottleLimit parameter should be set approximately to the number of available cores. If you are running on a VM with a single core, then it makes little sense to run high compute script blocks in parallel since the system must serialize them anyway to run on the single core.
  2. Script that must wait on something. If you have script that can run independently and performs long running work that requires waiting for somethings to complete, then it makes sense to run these tasks in parallel. If you have 5 scripts that take 5 minutes each to run but spend most of the time waiting, you can have them all run/wait at the same time, and complete all 5 tasks in 5 minutes instead of 25 minutes. Scripts that do a lot of file operations, or perform operations on external machines can benefit by running in parallel. Since the running script cannot use all of the machine cores, it makes sense to set the -ThrottleLimit parameter to something greater than the number of cores. If one script execution waits many minutes to complete, you may want to allow tens or hundreds of scripts to run in parallel.
$logNames.count
10

PS C:> Measure-Command { $logs = $logNames | ForEach-Object -Parallel { Get-WinEvent -LogName $_ -MaxEvents 5000 2>$null } -ThrottleLimit 10 }
TotalMilliseconds : 115994.3 (1 minute 56 seconds)
$logs.Count
50000

PS C:> Measure-Command { $logs = $logNames | ForEach-Object { Get-WinEvent -LogName $_ -MaxEvents 5000 2>$null } }
TotalMilliseconds : 229768.2364 (3 minutes 50 seconds)
$logs.Count
50000

The script above collects 50,000 log entries on the local machine from 10 system log names. Running this in parallel is almost twice as fast as running sequentially, because it involves some relatively slow disk access and can also take advantage of the machine multiple cores as it processes the log entries.

When should it be avoided?

ForEach-Object -Parallel should not be thought as something that will always speed up script execution. And in fact it can significantly slow down script execution if used heedlessly. For example, if your script block is executing trivial script then running in parallel adds a huge amount of overhead and will run much slower.

PS C:> (measure-command { 1..1000 | ForEach-Object -Parallel { "Hello: $_" } }).TotalMilliseconds
10457.962

PS C:> (measure-command { 1..1000 | ForEach-Object { "Hello: $_" } }).TotalMilliseconds
18.4473

The above example, a trivial script block is run 1000 times. The ThrottleLimit is 5 by default so only 5 runspace/threads are created at a time, but still a runspace and thread is created 1000 times to do a simple string evaluation. Consequently, it takes over 10 seconds to complete. But removing the -Parallel parameter and running the ForEach-Object cmdlet normally, results in completion in about 18 milliseconds.

So, it is important to use this feature wisely.

Implementation details

As previously mentioned, the new ForEach-Object -Parallel feature uses existing PowerShell functionality to run script blocks concurrently. The primary addition is the ability to limit the number of concurrent scripts running at a given time with the -ThrottleLimit parameter. Throttling is accomplished by a PSTaskPool class that holds running tasks (running scripts), and has a settable size limit which is set to the throttle limit value. An Add method allows tasks to be added to the pool, but if it is full then the method blocks until a new slot becomes available. Adding tasks to the task pool was initially performed on the ForEach-Object cmdlet piped input processing thread. But that turned out to be a performance bottleneck, and now a dedicated thread is used to add tasks to the pool.

PowerShell itself imposes conditions on how scripts run concurrently, based on its design and history. Scripts have to run in runspace contexts and only one script thread can run at a time within a runspace. So in order to run multiple scripts simultaneously multiple runspaces must be created. The current implementation of ForEach-Object -Parallel creates a new runspace for each script block execution instance. It may be possible to optimize this by re-using runspaces from a pool, but one concern in doing this is leaking state from one script execution to another.

Runspace contexts are an isolation unit for running scripts, and generally do not allow sharing state between themselves. However, variables can be passed at the beginning of script execution through the $using: keyword, from the calling script to the parallel script block. This was borrowed from the remoting layer which uses the keyword for the same purpose but over a remote connection. But there is a big difference when using the $using: keyword in ForEach-Object -Parallel. And that is for remoting, the variable being passed is a copy sent over the remoting connection. But with ForEach-Object -Parallel, the actual object reference is being passed from one script to another, violating normal isolation restrictions. So it is possible to have a non thread-safe variable used in two scripts running on different threads, which can lead to unpredictable behavior.

# This does not throw an error, but is not guaranteed to work since the dictionary object is not thread safe
$threadUnSafeDictionary = [System.Collections.Generic.Dictionary[string,object]]::new()
Get-Process | ForEach-Object -Parallel {
    $dict = $using:threadUnSafeDictionary
    $dict.TryAdd($_.ProcessName, $_)
}
# This *is* guaranteed to work because the passed in concurrent dictionary object is thread safe
$threadSafeDictionary = [System.Collections.Concurrent.ConcurrentDictionary[string,object]]::new()
Get-Process | ForEach-Object -Parallel {
    $dict = $using:threadSafeDictionary
    $dict.TryAdd($_.ProcessName, $_)
}

$threadSafeDictionary["pwsh"]

 NPM(K)    PM(M)      WS(M)     CPU(s)      Id  SI ProcessName
 ------    -----      -----     ------      --  -- -----------
    112   108.25     124.43      69.75   16272   1 pwsh

Conclusion

This feature can greatly improve your life for many work load scenarios. As long as you understand how it works and what its limitations are, you can experiment with parallelism and make real performance improvements with your scripts.

Paul Higinbotham
Senior Software Engineer
PowerShell Team

The post PowerShell ForEach-Object Parallel Feature appeared first on PowerShell.

New Telemetry in PowerShell 7 Preview 3

This post was originally published on this site

Beginning in PowerShell 7 Preview 3, PowerShell will be sending some additional data points to Microsoft.
This data will allow us to better understand usage of PowerShell and enable us to prioritize our future investments.
These additional points of data were reviewed with the PowerShell community and approved by the PowerShell Committee through the PowerShell RFC process.

What we added

We will continue to use Application Insights to collect the following new telemetry points:

- Count of PowerShell starts by type (API vs console)
    - Count of unique PowerShell usage
    - Count of the following execution types:
        - Application (native commands)
        - ExternalScript
        - Script
        - Function
        - Cmdlet
    - Enabled Microsoft experimental features or experimental features shipped with PowerShell
    - Count of hosted sessions
    - Microsoft owned modules loaded (based on white list)
This data will include the OS name, OS version, the PowerShell version, and the distribution channel when provided.

We will continue to share portions of our aggregated data with the PowerShell community through the
Public PowerBi report.

Why we added it

We want to make PowerShell better and believe this can be achieved by better understanding how PowerShell is being used.
Through these additional data points we will get answers backed by data to the following questions:

  • Is the PowerShell Core user-base growing?
  • How is PowerShell being used? What is the usage distribution across command types and session type?
  • How can we encourage PowerShell Core usage growth?
  • What are issues that customers are hitting in PowerShell Core?
  • What versions of PowerShell tools and services should Microsoft continue to support?
  • Which experimental features are being used and tested? Which experimental features should we invest in?
  • How can we optimize the engine size and efficiency of PowerShell for cloud scenarios?

To ensure we are getting an accurate picture of how everyone uses PowerShell, not just those most
vocal/involved in the community, we made improvements in our telemetry.
PowerShell usage telemetry will allow us to better prioritize testing, support, and investments.

Performance testing

When implementing this telemetry we took special care to ensure that there would not be a discernible performance impact.
The telemetry is collected through Application Insights and is batched and sent on a separate thread in order to reduce impact.
We also conducted tests to verify that there would not be a noticeable difference in PowerShell performance.

In order to test the performance impact of the telemetry we ran our test suite 5 times with and 5 times without the telemetry changes
and compared the average time for test completion.
The tests had a 1% difference in average completion time with the telemetry-enabled test runs actually having the faster average completion. The difference in average completion time, however, was not statistically significant.

We also tested the impact of collecting telemetry on startup time for both cold starts (first start-up of PowerShell) and warm starts (all future starts). We found that on average cold starups were .028 seconds slower with the additional telemetry while warm startups were, on average, .027 slower. The average performance impact was around 4% and all start-ups during the test runs performed faster than .6023 seconds.

How to disable

The telemetry reporting can be disabled by setting the environment variable POWERSHELL_TELEMETRY_OPTOUT to true, yes, or 1.
This should not be done in your profile, as PowerShell reads this value from your system before executing your profile.

Feedback and issues

If you encounter any issues with PowerShell telemetry, the best place to get support is through our GitHub page.

The post New Telemetry in PowerShell 7 Preview 3 appeared first on PowerShell.

PowerShell 7 Preview 3

This post was originally published on this site

PowerShell 7 Preview 3

In May, I published our PowerShell 7 Roadmap. We have been making progress on our roadmap and are currently on track to have a Generally Available (GA)
release by end of this calendar year.

Long Term Servicing

PowerShell 7 GA will also be our first Long Term Servicing (LTS) release which is a change from our current Modern Lifecycle support for PowerShell Core 6.
We will support PowerShell 7 GA for as long as .NET Core 3.1 is supported before you must upgrade to a newer version to continue to be supported by Microsoft.

Windows PowerShell compatibility

One of the main goals of PowerShell 7 is to have a viable replacement for Windows PowerShell 5.1 in production and we’ve made significant progress towards that goal.

PowerShell 7 Preview 3 is built on .NET Core 3.0 Preview 8 and leverages the work from the .NET Team to close the gap between .NET Core and .NET Framework. .NET Core 3.0 reintroduces a large number of .NET Framework APIs, opening up a large number of PowerShell modules shipped with Windows to be validated and marked as compatible by our team. Because the compatibility changes to the modules come as part of Windows, the latest version of Windows 10/Windows Server is required for full module compatibility.

However, on older versions of Windows, some modules may just work if you use:

Import-Module <moduleName> -SkipEditionCheck

If you have issues with a Microsoft PowerShell module, please open an issue in the PowerShellModuleCoverage repository!

Expect more content on this specific topic from Joey Aiello in the near future with more detail on which modules are compatible and where they’re marked as such.

New Features in Preview 3

This is just a small part of the entire changelog.
New features in this preview from the community and also the PowerShell team:

Experimental Features on by default in Preview builds

We decided to enable all Experimental Features by default in order to solicit more feedback for the PowerShell Committee to determine if a feature should continue as experimental, move from experimental to stable (non-experimental), or be withdrawn. On Stable builds (as well as Release Candidates), experimental features will continue to be disabled by default.

Note that if you had previously manually enabled experimental features, your powershell.config.jsonsettings file will take precedence and only experimental features listed within that file will be enabled. You can delete that file or run Get-ExperimentalFeature | Enable-ExperimentalFeature to ensure all experimental features are enabled. However, if you use the pipeline, you’ll have to do it again with a future Preview release that has new experimental features.

gif

Single Apartment Thread as default

In general, you don’t need to worry about a concept called ApartmentState which only applies to Windows.

Prior to this release pwsh would run as a multi-threaded apartment by default. However, graphical user interface (GUI) APIs such as WinForms and WPF require a single-threaded apartment. What is important here is that pwsh is now the same as powershell.exe in regards to apartment state and as such support calling WinForms and WPF APIs from PowerShell script.

gif

Display COM Method Signature Argument Names

On Windows, if you happen to call COM APIs from PowerShell, a new capability by nbkalex will now show the argument names of COM methods instead of just the type information which can be used as simple documentation indicating what arguments should be passed.

gif

Consider DBNull and NullString as $null

If you work with database types, you may get back a [dbnull]::Value which is equivalent to $null within the database, but in PowerShell, this was not equal to $null so you can’t compare it directly. This change from Joel Sallow allows you to compare both [dbnull]::Value and [nullstring]::Value to $null and get $true.

gif

Read-Host -Prompt works for all input

Due to how Read-Host calls into the console host and how the console host prompts for input (such as mandatory parameters that are given a value), you might encounter a situation where using Read-Host to prompt for input in your script exhibits unintended behavior when certain characters are used. This has been fixed so Read-Host will accept input as expected.

gif

Support negative numbers with -Split operator

The -Split operator splits one or more strings into substrings. You can optionally specify a value to indicate the maximum number of substrings you want returned.

This new capability by Jacob Scott now allows you to specify the maximum number of substrings as a negative value signifying that the split should happen right to left instead of the usual left to right.

gif

ForEach-Object -Parallel

We’ve received consistent feedback that PowerShell users use PSWorkflow primarily to easily run scriptblocks in parallel.

We’ve added a -Parallel parameter to ForEach-Object that accepts a scriptblock to execute in parallel. There is an optional -ThrottleLimit parameter to set the maximum threads to use in parallel where it defaults to 5.

gif

Resolve AppX reparse points

On Windows 10, if you have apps installed from the Windows Store and list them in the command line, they show up as 0 byte files. These files are actually a different type of link to the actual executable. With this change, the target executable will now show up when using Get-ChildItem.

gif

pwsh as a login shell

On Linux and macOS systems, there is a concept of a login shell which sets up the environment from which other apps and shells inherit. Prior to this release if you used pwsh as your default login shell, you may have noticed that some environment variables are missing or incomplete.

With this change, pwsh will work the same as sh Bourne Shell in how it sets up the login environment so that everything works correctly.

Additional Telemetry

In this Preview release, we’ve added more telemetry. Please see Sydney Smith‘s blog post on New Telemetry in PowerShell 7 Preview 3.

Closing

Although this blog post focuses on new features, this release also contains many bug fixes as well as targeted performance improvements.

You can always get the latest version of PowerShell from https://aka.ms/get-powershell.

Expect more new features from the community and the PowerShell team in future Preview releases!

Steve Lee
PowerShell Team

The post PowerShell 7 Preview 3 appeared first on PowerShell.