New features in Windows PowerShell 5.0

New features in Windows PowerShell

  • Starting in Windows PowerShell 5.0, you can develop by using classes, by using formal syntax and semantics that are similar to other object-oriented programming languages. Class, Enum, and other keywords have been added to the Windows PowerShell language to support the new feature. For more information about working with classes, see about_Classes.
  • In collaboration with Microsoft Research, a new cmdlet, ConvertFrom-String, has been added. ConvertFrom-String lets you extract and parse structured objects from the content of text strings. For more information, see ConvertFrom-String.
  • A new module, Microsoft.PowerShell.Archive, includes cmdlets that let you compress files and folders into archive (also known as ZIP) files, extract files from existing ZIP files, and update ZIP files with newer versions of files compressed within them.
  • A new module, OneGet, lets you discover and install software packages on the Internet. The OneGet module is a manager or multiplexer of existing package managers (also called package providers) to unify Windows package management with a single Windows PowerShell interface.
  • A new module, PowerShellGet, lets you find, install, publish, and update modules and DSC resources on the PowerShell Resource Gallery, or on an internal module repository that you can set up by running the Register-PSRepository cmdlet.
  • New-Item, Remove-Item, and Get-ChildItem have been enhanced to support creating and managing symbolic links. The ItemType parameter for New-Item accepts a new value, SymbolicLink. Now you can create symbolic links in a single line by running the New-Item cmdlet.
  • Windows PowerShell transcription has been improved to apply to all hosting applications (such as Windows PowerShell ISE) in addition to the console host (powershell.exe). Transcription options (including enabling a system-wide transcript) can be configured by enabling the Turn on PowerShell Transcription Group Policy setting, found in Administrative Templates/Windows Components/Windows PowerShell.
  • A new detailed script tracing feature lets you enable detailed tracking and analysis of Windows PowerShell scripting use on a system. After you enable detailed script tracing, Windows PowerShell logs all script blocks to the Event Tracing for Windows (ETW) event log, Microsoft-Windows-PowerShell/Operational.
  • Starting in Windows PowerShell 5.0, new Cryptographic Message Syntax cmdlets support encryption and decryption of content by using the IETF standard format for cryptographically protecting messages as documented by RFC5652. The Get-CmsMessage, Protect-CmsMessage, and Unprotect-CmsMessage cmdlets have been added to the Microsoft.PowerShell.Security module.
  • New cmdlets in the Microsoft.PowerShell.Utility module, Get-Runspace, Debug-Runspace, Get-RunspaceDebug, Enable-RunspaceDebug, and Disable-RunspaceDebug, let you set debug options on a runspace, and start and stop debugging on a runspace. For debugging arbitrary runspaces—that is, runspaces that are not the default runspace for a Windows PowerShell console or Windows PowerShell ISE session—Windows PowerShell lets you set breakpoints in a script, and have added breakpoints stop the script from running until you can attach a debugger to debug the runspace script. Nested debugging support for arbitrary runspaces has been added to the Windows PowerShell script debugger for runspaces.
  • New cmdlets Enter-PSHostProcess and Exit-PSHostProcess let you debug Windows PowerShell scripts in processes separate from the current process that is running in the Windows PowerShell console. Run Enter-PSHostProcess to enter, or attach to, a specific process ID, and then run Get-Runspace to return the active runspaces within the process. Run Exit-PSHostProcess to detach from the process when you are finished debugging the script within the process.
  • A new Wait-Debugger cmdlet has been added to the Microsoft.PowerShell.Utility module. You can run Wait-Debugger to stop a script in the debugger before running the next statement in the script.
  • The Windows PowerShell Workflow debugger now supports command or tab completion, and you can debug nested workflow functions. You can now press Ctrl+Break to enter the debugger in a running script, in both local and remote sessions, and in a workflow script.
  • A Debug-Job cmdlet has been added to the Microsoft.PowerShell.Core module to debug running job scripts for Windows PowerShell Workflow, background, and jobs running in remote sessions.
  • A new state, AtBreakpoint, has been added for Windows PowerShell jobs. The AtBreakpoint state applies when a job is running a script that includes set breakpoints, and the script has hit a breakpoint. When a job is stopped at a debug breakpoint, you must debug the job by running the Debug-Job cmdlet.
  • Windows PowerShell 5.0 implements support for multiple versions of a single Windows PowerShell module in the same folder in $PSModulePath. A RequiredVersion property has been added to the ModuleSpecification class to help you get the desired version of a module; this property is mutually-exclusive with the ModuleVersion property. RequiredVersion is now supported as part of the value of the FullyQualifiedName parameter of the Get-Module, Import-Module, and Remove-Module cmdlets.
  • You can now perform module version validation by running the Test-ModuleManifest cmdlet.
  • Results of the Get-Command cmdlet now display a Version column; a new Version property has been added to the CommandInfo class. Get-Command shows commands from multiple versions of the same module. The Version property is also part of derived classes of CmdletInfo: CmdletInfo and ApplicationInfo.
  • A new Get-ItemPropertyValue cmdlet lets you get the value of a property without using dot notation. For example, in older releases of Windows PowerShell, you can run the following command to get the value of the Application Base property of the PowerShellEngine registry key: (Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine -Name ApplicationBase).ApplicationBase. Starting in Windows PowerShell 5.0, you can run Get-ItemPropertyValue -Path HKLM:\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine -Name ApplicationBase.
  • A new NetworkSwitch module contains cmdlets that enable you to apply switch, virtual LAN (VLAN), and basic Layer 2 network switch port configuration to Windows Server 2012 R2 logo-certified network switches.
  • The FullyQualifiedName parameter has been added to Import-Module and Remove-Module cmdlets, to support storing multiple versions of a single module.
  • Save-Help, Update-Help, Import-PSSession, Export-PSSession, and Get-Command have a new parameter, FullyQualifiedModule, of type ModuleSpecification. Add this parameter to specify a module by its fully qualified name.
  • The value of $PSVersionTable.PSVersion has been updated to 5.0.

New features in Windows PowerShell Desired State Configuration

  • Windows PowerShell language enhancements let you define Windows PowerShell Desired State Configuration (DSC) resources by using classes. Import-DscResource is now a true dynamic keyword; Windows PowerShell parses the specified module’s root module, searching for classes that contain the DscResource attribute. You can now use classes to define DSC resources, in which neither a MOF file nor a DSCResource subfolder in the module folder is required. A Windows PowerShell module file can contain multiple DSC resource classes.
  • A new parameter, ThrottleLimit, has been added to the following cmdlets in the PSDesiredStateConfiguration module. Add the ThrottleLimit parameter to specify the number of target computers or devices on which you want the command to work at the same time.
    • Get-DscConfiguration
    • Get-DscConfigurationStatus
    • Get-DscLocalConfigurationManager
    • Restore-DscConfiguration
    • Test-DscConfiguration
    • Compare-DscConfiguration
    • Publish-DscConfiguration
    • Set-DscLocalConfigurationManager
    • Start-DscConfiguration
    • Update-DscConfiguration
  • With centralized DSC error reporting, rich error information is not only logged in the event log, but it can be sent to a central location for later analysis. You can use this central location to store DSC configuration errors that have occurred for any server in their environment. After the report server is defined in the meta-configuration, all errors are sent to the report server, and then stored in a database. You can set up this functionality regardless of whether or not a target node is configured to pull configurations from a pull server.
  • Improvements to Windows PowerShell ISE ease DSC resource authoring. You can now do the following.
    • List all DSC resources within a configuration or node block by entering Ctrl+Space on a blank line within the block.
    • Automatic completion on resource properties of the enumeration type.
    • Automatic completion on the DependsOn property of DSC resources, based on other resource instances in the configuration.
    • Improved tab completion of resource property values.
  • A new DscLocalConfigurationManager attribute designates a configuration block as a meta-configuration, which is used to configure the DSC Local Configuration Manager. This attribute restricts a configuration to containing only items which configure the DSC Local Configuration Manager. During processing, this configuration generates a *.meta.mof file that is then sent to the appropriate target nodes by running the Set-DscLocalConfigurationManager cmdlet.
  • Partial configurations are now allowed in Windows PowerShell 5.0. You can deliver configuration documents to a node in fragments. For a node to receive multiple fragments of a configuration document, the node’s Local Configuration Manager must be first set to specify the expected fragments
  • Cross-computer synchronization is new in DSC in Windows PowerShell 5.0. By using the built-in WaitFor* resources (WaitForAll, WaitForAny, and WaitForSome), you can now specify dependencies across computers during configuration runs, without external orchestrations. These resources provide node-to-node synchronization by using CIM connections over the WS-Man protocol. A configuration can wait for another computer’s specific resource state to change.
  • Just Enough Administration (JEA), a new delegation security feature, leverages DSC and Windows PowerShell constrained runspaces to help secure enterprises from data loss or compromise by employees, whether intentional or unintentional. For more information about JEA, including where you can download the xJEA DSC resource, seeJust Enough Administration, Step by Step.
  • The following new cmdlets have been added to the PSDesiredStateConfiguration module.
    • A new Get-DscConfigurationStatus cmdlet gets high-level information about configuration status from a target node. You can obtain the status of the last, or of all configurations.
    • A new Compare-DscConfiguration cmdlet compares a specified configuration with the actual state of one or more target nodes.
    • A new Publish-DscConfiguration cmdlet copies a configuration MOF file to a target node, but does not apply the configuration. The configuration is applied during the next consistency pass, or when you run the Update-DscConfiguration cmdlet.
    • A new Test-DscConfiguration cmdlet lets you verify that a resulting configuration matches the desired configuration, returning either True if the configuration matches the desired configuration, or False if the actual configuration does not match the desired configuration.
    • A new Update-DscConfiguration cmdlet forces a configuration to be processed. If the Local Configuration Manager is in pull mode, the cmdlet gets the configuration from the pull server before applying it.

New features in Windows PowerShell ISE

  • You can now edit remote Windows PowerShell scripts and files in a local copy of Windows PowerShell ISE, by running Enter-PSSession to start a remote session on the computer that’s storing the files you want to edit, and then running PSEdit <path and file name on the remote computer>. This feature eases editing Windows PowerShell files that are stored on the Server Core installation option of Windows Server, where Windows PowerShell ISE cannot run.
  • The Start-Transcript cmdlet is now supported in Windows PowerShell ISE.
  • You can now debug remote scripts in Windows PowerShell ISE.
  • A new menu command, Break All (Ctrl+B), breaks into the debugger for both local and remotely-running scripts.

New features in Windows PowerShell Web Services (Management OData IIS Extension)

  • Starting in Windows PowerShell 5.0, you can generate a set of Windows PowerShell cmdlets based on the functionality exposed by a given OData endpoint, by running the Export-ODataEndpointProxy cmdlet.

Notable bug fixes in Windows PowerShell 5.0

Windows PowerShell 5.0 includes a new COM implementation, which offers significant performance improvements when you are working with COM objects. For a video demonstration of the effect, see Com_Perf_Improvements.

How to Install Windows PowerShell 4.0

Windows PowerShell 4.0 is part of the Windows Management Framework 4.0, which includes the following:

  • Windows PowerShell
  • Windows PowerShell Integrated Scripting Environment (ISE)
  • Windows PowerShell Web Services (Management OData IIS Extension)
  • Windows Remote Management (WinRM)
  • Windows Management Infrastructure (WMI)
  • Server Manager WMI provider
  • Windows PowerShell Desired State Configuration (DSC)


Windows Management Framework 4.0 supportability matrix

Operating system Windows PowerShell 4.0 available Prerequisites Installation file
Windows Server 2012 R2 Built-in N/A N/A
Windows 8.1 Built-in N/A N/A
Windows Server 2012 Yes, part of WMF 4.0 .NET 4.5 (built-in) x64: Windows8-RT-KB2799888-x64.msu
Windows 8 No, user must upgrade to Windows 8.1 N/A N/A
Windows Server 2008 R2 Yes, part of WMF 4.0 Windows Server 2008 R2 SP1

.NET 4.5

x64: Windows6.1-KB2819745-x64-MultiPkg.msu
Windows 7 Yes, part of WMF 4.0 Windows 7 SP1

.NET 4.5

x64: Windows6.1-KB2819745-x64-MultiPkg.msu

x86: Windows6.1-KB2819745-x86.msu


Installation

  • Verify that all prerequisites are installed according to the Windows Management Framework 4.0 supportability matrix above. To verify the presence of .NET 4.5, you may use the Test-Net45 function available in this article on the Hey Scripting Guy! Blog
  • Run the installation file applicable to the operating system
  • Reboot the computer, start Windows PowerShell and verify that the output of $PSVersionTable shows 4.0 as the value of the PSVersion property


Known issues

Installation succeeds even if .NET 4.5 is not installed

Scenario: Installing WMF 4.0 on a computer that is not running .NET Framework 4.5 will report that the installation is successful, but the components of WMF 4.0 (such as Windows PowerShell, WMI, etc.) will not be updated.

Solution: Install .NET Framework 4.5, and then run the WMF 4.0 installer again.

More information:
http://blogs.msdn.com/b/powershell/archive/2013/10/29/wmf-4-0-known-issue-partial-installation-without-net-framework-4-5.aspx

Compatibility issues

There are known compatibility issues with several Microsoft server-class applications:

  • System Center 2012 Configuration Manager (not including SP1)
  • System Center Virtual Machine Manager 2008 R2 (including SP1)
  • Microsoft Exchange Server 2013, Microsoft Exchange Server 2010, and Microsoft Exchange Server 2007
  • Microsoft SharePoint Server 2013 and Microsoft SharePoint Server 2010
  • Windows Small Business Server 2011 Standard

Read the WMF 4.0 Release Notes for more information.


Related KB articles

Update is available that prevents the PSModulePath environment variable from being reset when you upgrade WMF 3.0 to WMF 4.0 and then uninstall WMF 4.0 in Windows http://support.microsoft.com/kb/2872047

Update prevents the “PSModulePath” environment variables from being reset after you uninstall WMF 4.0 in Windows
http://support.microsoft.com/kb/2872035

New features in Windows PowerShell 4.0

Windows PowerShell 4.0 is backward-compatible. Cmdlets, providers, modules, snap-ins, scripts, functions, and profiles that were designed for Windows PowerShell 3.0 and Windows PowerShell 2.0 work in Windows PowerShell 4.0 without changes.

Windows PowerShell 4.0 is installed by default on Windows® 8.1 and Windows Server 2012 R2. To install Windows PowerShell 4.0 on Windows 7 with SP1, or Windows Server 2008 R2, download and install Windows Management Framework 4.0. Be sure to read the download details, and meet all system requirements, before you install Windows Management Framework 4.0.

Windows PowerShell 4.0 includes the following new features.

New features in Windows PowerShell

  • Windows PowerShell Desired State Configuration (DSC) is a new management system in Windows PowerShell 4.0 that enables the deployment and management of configuration data for software services and the environment in which these services run. For more information about DSC, see Get Started with Windows PowerShell Desired State Configuration.
  • Save-Help now lets you save help for modules that are installed on remote computers. You can use Save-Help to download module Help from an Internet-connected client (on which not all of the modules for which you want help are necessarily installed), and then copy the saved Help to a remote shared folder or a remote computer that does not have Internet access.
  • The Windows PowerShell debugger has been enhanced to allow debugging of Windows PowerShell workflows, as well as scripts that are running on remote computers. Windows PowerShell workflows can now be debugged at the script level from either the Windows PowerShell command line or Windows PowerShell ISE. Windows PowerShell scripts, including script workflows, can now be debugged over remote sessions. Remote debugging sessions are preserved over Windows PowerShell remote sessions that are disconnected and then later reconnected.
  • A RunNow parameter for Register-ScheduledJob and Set-ScheduledJob eliminates the need to set an immediate start date and time for jobs by using the Triggerparameter.
  • Invoke-RestMethod and Invoke-WebRequest now let you set all headers by using the Headers parameter. Although this parameter has always existed, it was one of several parameters for the web cmdlets that resulted in exceptions or errors.
  • Get-Module has a new parameter, FullyQualifiedName, of the type ModuleSpecification[]. The FullyQualifiedName parameter of Get-Module now lets you specify a module by using the module’s name, version, and optionally, its GUID.
  • The default execution policy setting on Windows Server 2012 R2 is RemoteSigned. On Windows 8.1, there is no change in default setting.
  • Starting in Windows PowerShell 4.0, method invocation by using dynamic method names is supported. You can use a variable to store a method name, and then dynamically invoke the method by calling the variable.
  • Asynchronous workflow jobs are no longer deleted when the time-out period that is specified by the PSElapsedTimeoutSec workflow common parameter has elapsed.
  • A new parameter, RepeatIndefinitely, has been added to the New-JobTrigger and Set-JobTrigger cmdlets. This eliminates the necessity of specifying aTimeSpan.MaxValue value for the RepetitionDuration parameter to run a scheduled job repeatedly for an indefinite period.
  • A Passthru parameter has been added to the Enable-JobTrigger and Disable-JobTrigger cmdlets. The Passthru parameter displays any objects that are created or modified by your command.
  • The parameter names for specifying a workgroup in the Add-Computer and Remove-Computer cmdlets are now consistent. Both cmdlets now use the parameterWorkgroupName.
  • A new common parameter, PipelineVariable, has been added. PipelineVariable lets you save the results of a piped command (or part of a piped command) as a variable that can be passed through the remainder of the pipeline.
  • Collection filtering by using a method syntax is now supported. This means that you can now filter a collection of objects by using simplified syntax, similar to that for Where() or Where-Object, formatted as a method call. The following is an example: (Get-Process).where({$_.Name -match ‘powershell’})
  • The Get-Process cmdlet has a new switch parameter, IncludeUserName.
  • A new cmdlet, Get-FileHash, that returns a file hash in one of several formats for a specified file, has been added.
  • In Windows PowerShell 4.0, if a module uses the DefaultCommandPrefix key in its manifest, or if the user imports a module with the Prefix parameter, theExportedCommands property of the module shows the commands in the module with the prefix. When you run the commands by using the module-qualified syntax, ModuleName\CommandName, the command names must include the prefix.
  • The value of $PSVersionTable.PSVersion has been updated to 4.0.
  • Where() operator behavior has changed. Collection.Where('property –match name') accepting a string expression in the format "Property –CompareOperator Value" is no longer supported. However, the Where() operator accepts string expressions in the format of a scriptblock; this is still supported.

New features in Windows PowerShell Integrated Scripting Environment (ISE)

  • Windows PowerShell ISE supports both Windows PowerShell Workflow debugging and remote script debugging.
  • IntelliSense support has been added for Windows PowerShell Desired State Configuration providers and configurations.

New features in Windows PowerShell Workflow

  • Support has been added for a new PipelineVariable common parameter in the context of iterative pipelines, such as those used by System Center Orchestrator; that is, pipelines that run commands simply left-to-right, as opposed to interspersed running by using streaming.
  • Parameter binding has been significantly enhanced to work outside of tab completion scenarios, such as with commands that do not exist in the current runspace.
  • Support for custom container activities has been added to Windows PowerShell Workflow. If an activity parameter is of the types Activity, Activity[]—or is a generic collection of activities—and the user has supplied a script block as an argument, then Windows PowerShell Workflow converts the script block to XAML, as with normal Windows PowerShell script-to-workflow compilation.
  • After a crash, Windows PowerShell Workflow automatically reconnects to managed nodes.
  • You can now throttle Foreach -Parallel activity statements by using the ThrottleLimit property.
  • The ErrorAction common parameter has a new valid value, Suspend, that is exclusively for workflows.
  • A workflow endpoint now automatically closes if there are no active sessions, no in-progress jobs, and no pending jobs. This feature conserves resources on the computer that is acting as the workflow server, when the automatic closure conditions have been met.

New features in Windows PowerShell Web Services

  • When an error occurs in Windows PowerShell Web Services (PSWS, also called Management OData IIS Extension), while a cmdlet is running, more detailed error messages are returned to the caller. In addition, error codes follow Windows Azure REST API error code guidelines.
  • An endpoint can now define the API version, as well as enforce the usage of a specific API version. Whenever version mismatches occur between client and server, errors are displayed to both the client and the server.
  • Management of the dispatch schema has been simplified by automatically generating values for any missing fields in the schema. Generation occurs, as a helpful starting point, even if the dispatch schema does not exist.
  • Type handling in PSWS has been improved to support types that use a different constructor than the default constructor, by behaving similarly to the PSTypeConverter in Windows PowerShell. This lets you use complex types with PSWS.
  • PSWS now allows expanding an associated instance while running a query. For larger binary contents (such as images, audio, or video), the transfer cost is significant, and it is better to transfer binary data without encoding. PSWS uses named resource streams for transferring without encoding. The named resource stream is a property of an entity of the Edm.Stream type. Each named resource stream has a separate URI for GET or UPDATE operations.
  • OData actions now provide a mechanism for invoking non-CRUD (Create, Read, Update, and Delete) methods on a resource. You can invoke an action by sending an HTTP POST request to the URI that is defined for the action. The parameters for the action are defined in the body of the POST request.
  • To be consistent with Windows Azure guidelines, all URLs should be simplified. A change included in Key As Segment allows single keys to be represented as segments. Note that references that use multiple key values require comma-separated values in parenthetical notation, as before.
  • Before this release of PSWS, the only way to perform Create, Update, or Delete operations was to invoke Post, Put, or Delete on a top-level resource. New in this release of PSWS, Contained Resource operations let users achieve the same results while reaching the same resource less directly, approaching as if these resources were contained.

New features in Windows PowerShell Web Access

  • You can disconnect from and reconnect to existing sessions in the web-based Windows PowerShell Web Access console. A Save button in the web-based console lets you disconnect from a session without deleting it and reconnect to the session another time.
  • Default parameters can be displayed on the sign-in page. To display default parameters, configure values for all of the settings displayed in the Optional Connection Settings area of the sign-in page in a file named web.config. You can use the web.config file to configure all optional connection settings except for a second or alternate set of credentials.
  • In Windows Server 2012 R2, you can remotely manage authorization rules for Windows PowerShell Web Access. The Add-PswaAuthorizationRule and Test-PswaAuthorizationRule cmdlets now include a Credential parameter that enables administrators to manage authorization rules from a remote computer or in a Windows PowerShell Web Access session.
  • You can now have multiple Windows PowerShell Web Access sessions in a single browser session by using a new browser tab for each session. You no longer need to open a new browser session to connect to a new session in the web-based Windows PowerShell console.

Notable bug fixes in Windows PowerShell 4.0

  • Get-Counter can now return counters that contain an apostrophe character in French editions of Windows.
  • You can now view the GetType method on deserialized objects.
  • #Requires statements now let users require Administrator access rights, if needed.
  • The Import-Csv cmdlet now ignores blank lines.
  • A problem where Windows PowerShell ISE uses too much memory when you are running an Invoke-WebRequest command has been fixed.
  • Get-Module now displays module versions in a Version column.
  • Remove-Item –Recurse now removes items from subfolders as expected.
  • A UserName property has been added to Get-Process output objects.
  • The Invoke-RestMethod cmdlet now returns all available results.
  • Add-Member now takes effect on hashtables, even if the hashtables have not yet been accessed.
  • Select-Object –Expand no longer fails or generates an exception if the value of the property is null or empty.
  • Get-Process can now be used in a pipeline with other commands that get the ComputerName property from objects.
  • ConvertTo-Json and ConvertFrom-Json can now accept terms within double quotes, and its error messages are now localizable.
  • Get-Job now returns any completed scheduled jobs, even in new sessions.
  • Issues with mounting and unmounting VHDs by using the FileSystem provider in Windows PowerShell 4.0 have been fixed. Windows PowerShell is now able to detect new drives when they are mounted in the same session.
  • You no longer need to explicitly load ScheduledJob or Workflow modules to work with their job types.
  • Performance improvements have been made to the process of importing workflows that define nested workflows; this process is now faster.