about_Windows_PowerShell_2.0 | Easy Powershell 2.0 Reference

SHORT DESCRIPTION
Describes the new features that are included in Windows PowerShell 2.0.

LONG DESCRIPTION
    Windows PowerShell 2.0 includes several significant features that
    extend its use, improve its usability, and allow you to control and
    manage Windows-based Environments more easily and comprehensively.

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

NEW FEATURES
Windows PowerShell 2.0 includes the following new features.

Remoting

     Windows PowerShell 2.0 lets you run commands on one or many remote
     computers with a single Windows PowerShell command. You can run
     individual commands, or you can create a persistent connection
     (a session) to run a series of related commands. You can also start a
     session with a remote computer so that the commands you type run
     directly on the remote computer.

     The remoting features of Windows PowerShell are built on Windows
     Remote Management (WinRM). WinRM is the Microsoft implementation of
     the WS-Management protocol, a standard SOAP-based, firewall-compatible
     communications protocol.

     The remote computers must have Windows PowerShell 2.0, the Microsoft .NET
     Framework 2.0, and the WinRM service. Remote commands are supported
     on all operating systems that can run Windows PowerShell. The
     current user must have permission to run commands on the remote
     computers. For more information, see about_remote_requirements.

     To support remoting, the Invoke-Command, Enter-PSSession, and
     Exit-PSSession cmdlets have been added, along with other cmdlets
     that contain the PSSession noun. These cmdlets let you create and manage
     persistent connections.

     The ComputerName parameter has also been added to several cmdlets,
     including the Get-Process, Get-Service, and Get-Eventlog cmdlets. This
     parameter allows you to get information about remote computers.
     These cmdlets use .NET Framework methods to get their data,
     so they do not rely on Windows PowerShell remoting. They do not require
     any new programs or configuration. For more information, see the Help for
     each cmdlet.

     For more information about remote commands, see about_remote and
     about_remote_FAQ. For more information about sessions, see
     about_pssessions.

Windows PowerShell ISE

     Windows PowerShell 2.0 includes Windows PowerShell Integrated
     Scripting Environment (ISE), a host application that lets you run
     commands, and design, write, test, and debug scripts in a graphical,
     color-coded, Unicode-based Environment.

Windows PowerShell ISE requires the Microsoft .NET Framework 3.0 or
later.

Windows PowerShell ISE includes:

     – A Command pane that lets you run interactive commands just as you
         would in the Windows PowerShell console. Just type a command, and then
         press ENTER. The output appears in the Output pane.

– A Script pane that lets you compose, edit, debug, and run Functions
and scripts.

– Multiple tabs, each with its own Command and Script pane, that let you
work on one or several tasks independently.

Windows PowerShell ISE is designed for both novice and advanced users.

Background Jobs

     Background jobs are commands that run asynchronously. When you run a
     background job, the command prompt returns immediately, even if the
     command is still running. You can use the background job feature to run a
     complex command in the background so that you can use your session for
     other work while the command runs.

     You can run a background job on a local or remote computer and then save
     the results on the local or remote computer. To run a job remotely, use
     the Invoke-Command cmdlet.

     Windows PowerShell includes a set of cmdlets that contain the Job noun
     (the Job cmdlets). Use these cmdlets for creating, starting, managing,
     and deleting background jobs and for getting the results of a background
     job. To get a list of the job cmdlets, type the following command:

Get-Command *-job

For more information about background jobs, see about_jobs.

Script Debugger

     Windows PowerShell 2.0 includes a cmdlet-based debugger for scripts and
     Functions. The debugger is supported by a fully documented public API
     that you can use to build your own debugger or to customize or extend
     the debugger.

     The debugger cmdlets let you set breakpoints on lines, columns,
     Variables, and commands. These cmdlets let you manage the breakpoints
     and display the call stack. You can create conditional breakpoints and
     specify custom actions at a breakpoint, such as running diagnostic and
     logging scripts.

     When you reach a breakpoint, Windows PowerShell suspends execution
     and starts the debugger. The debugger includes a set of custom commands
     that let you step through the code. You can also run standard Windows
     PowerShell commands to display the values of Variables, and you can use
     cmdlets to investigate the results.

For more information about debugging, see about_debuggers.

Data Section

     Scripts designed for Windows PowerShell 2.0 can have one or more
     DATA sections that isolate the data from the script logic. The data in
     the new DATA section is restricted to a specified subset of the Windows
     PowerShell scripting language.

     In Windows PowerShell 2.0, the DATA section is used to support
     script internationalization. You can use the DATA section to isolate
     and identify user message strings that will be translated into
     multiple user interface languages.

For more information, see about_data_sections.

Script Internationalization

     Windows PowerShell 2.0 script internationalization features allow you
     to better serve users throughout the world. Script internationalization
     enables scripts and Functions to display messages and Help text to users
     in multiple languages.

     The script internationalization features query the operating system user
     interface culture ($PsUICulture) during execution and then import the
     appropriate translated text strings so you can display them to the user.
     The Data section lets you store text strings separate from code so that
     they are easily identified. A new cmdlet, ConvertFrom-StringData,
     converts text strings into dictionary-like hash tables to facilitate
     translation.

For more information, see about_script_internationalization.

WMI Cmdlets

     The Windows Management Instrumentation (WMI) Functionality of
     Windows PowerShell 2.0 is improved with the addition of the following
     cmdlets:

         – Remove-WmiObject
         – Set-WmiInstance
         – Invoke-WmiMethod

New parameters have been added to the Get-WmiObject cmdlet. All the WMI
cmdlets now support the following parameters:

         – EnableAllPrivileges
         – Impersonation
         – Authentication
         – Authority

     These new parameters give you more refined control over the security
     configuration of your WMI operations without requiring you to work
     directly with the types in the .NET Framework Class Library.

For a list of WMI cmdlets, type the following command:

Get-Help *wmi*

To get help for each cmdlet, type Get-Help followed by the cmdlet name.

The Get-WinEvent Cmdlet

     The Get-WinEvent cmdlet gets events from Event Viewer logs and from
     Event Tracing for Windows (ETW) event log files on local and remote
     computers. It can get events from classic event logs and from the
     Windows Event Logs that were introduced in Windows Vista.

     You can use Get-WinEvent to get the objects that represent event logs, event
     log providers, and the events in the logs. Get-WinEvent lets you combine
     events from different sources in a single command. It supports
     advanced queries in XML Path Language (XPath), XML, and hash table
     format.

Get-WinEvent requires Windows Vista or Windows Server 2008 and the
Microsoft .NET Framework 3.5.

The Out-GridView Cmdlet

     The Out-GridView cmdlet displays the results of other commands in an
     interactive table in which you can search, sort, group, and filter the
     results. For example, you can send the results of a Get-Process,
     Get-WmiObject, Get-WinEvent, or Get-Eventlog command to Out-GridView and
     then use the table features to examine the data.

help Out-GridView -full

The Add-Type Cmdlet

     The Add-Type cmdlet lets you add .NET Framework types to
     Windows PowerShell from the source code of another .NET Framework
     language.

     Add-Type compiles the source code that creates the types and generates
     assemblies that contain the new .NET Framework types. Then, you can use
     the .NET Framework types in Windows PowerShell commands along with the
     standard object types provided by the .NET Framework.

You can also use Add-Type to load assemblies into your session so that
you can use the types in the assemblies in Windows PowerShell.

Add-Type allows you develop new .NET Framework types, to
use .NET Framework types in C# libraries, and to access Win32 APIs.

For more information, see Add-Type.

Event Notification

     Windows PowerShell 2.0 introduces event notification. Users can register
     and subscribe to events, such as Windows PowerShell events, WMI events,
     or .NET Framework events. And, users can listen, forward, and act on
     management and system events both synchronously and asynchronously.

     Developers can write applications that use the event architecture
     to receive notification about state changes. Users can write
     scripts that subscribe to various events and that react to the content.

     Windows PowerShell provides cmdlets that create new events, get
     events and event subscriptions, register and unregister events,
     wait for events, and delete events. For more information about these
     cmdlets, type the following command:

Get-Command *-event

Modules

     Windows PowerShell modules let you divide and organize your
     Windows PowerShell scripts into independent, self-contained,
     reusable units. Code from a module executes in its own context,
     so it does not add to, conflict with, or overwrite the Variables,
     Functions, Aliases, and other resources in the session.

You can write, distribute, combine, share, and reuse modules to build
simple scripts and complex applications.

     Windows PowerShell 2.0 includes cmdlets to add, get, and remove modules
     and to export module members. For more information about the cmdlets
     that are related to modules, type the following command:

Get-Command *-module*

Transactions

     Windows PowerShell 2.0 includes support for transactions. Transactions
     let you undo an entire series of operations. Transactions are available
     only for operations that support transactions. They are designed for
     applications that require atomicity, consistency, isolation, and
     recoverability, like databases and message queuing.

     Cmdlets and providers that support transactions have a new
     UseTransaction parameter. To start an operation within a transaction,
     use the Start-Transaction cmdlet. Then, when you use the cmdlets that
     perform the operation, use the UseTransaction parameter of each cmdlet
     when you want the command to be part of a transaction.

     If any command in the transaction fails at any point, use the
     Rollback-Transaction cmdlet to undo all the commands in the transaction.
     If all the commands succeed, use the Commit-Transaction cmdlet to make
     the command actions permanent.

     Windows PowerShell 2.0 includes cmdlets to start, use, commit, and roll
     back transactions. For information about these cmdlets, type the
     following command:

Get-Command *transaction*

Breaking Changes to Windows PowerShell 1.0

     — The value of the PowerShellVersion Registry entry in
        HKLM\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine
        is changed to 2.0.

— New cmdlets and Variables have been added. These additions might
conflict with Variables and Functions in profiles and scripts.

— The -IEQ operator performs a case insensitive comparison on characters.

— The Get-Command cmdlet gets Functions by default, in addition to
cmdlets.

— Native commands that generate a user interface cannot be piped to the
Out-Host cmdlet.

     — The new Begin, Process, End, and Dynamic Param language keywords might
        conflict with similar words used in scripts and Functions. Interpreting
        these words as language keywords might result in parsing errors.

     — Cmdlet name resolution has changed. In Windows PowerShell 1.0, a
        runtime error was generated when two Windows PowerShell snap-ins
        exported cmdlets with the same name. In Windows PowerShell 2.0, the
        last cmdlet that is added to the session runs when you type the command
        name. To run a command that does not run by default, qualify the cmdlet
        name with the name of the snap-in or module in which it originated.

— A Function name followed by ‘-?’ gets the help topic for the Function,
if one is included in the Function.

    — Parameter resolution for Microsoft .Net Frameword methods have changed.
        In Windows PowerShell 1.0, if you called an overloaded .NET method
        that has more than one best fit syntax, no error was reported. In
        Windows PowerShell 2.0, an ambiguity error is reported.

        In addition, in Windows PowerShell 2.0, the algorithm for choosing the
        best fit method has been revised significantly to minimize the number
        of ambiguities.

     — If you are enumerating a collection in the pipeline and you try to
        modify the collection in the pipeline, Windows PowerShell throws an
        exception.

        For example, the following commands would work in Windows
        PowerShell 1.0, but would fail after first pipeline iteration in
        Windows PowerShel 2.0.

$h = @{Name=”Hello”; Value=”Test”}
$h.keys | ForEach-Object {$h.remove($_)}

To avoid this error, create a sub-expression for the enumerator
by using the $() characters. For example:

$($h.keys) | ForEach-Object {$h.remove($_)}

For more information about Windows PowerShell 2.0, visit the following Web
sites:

— Windows PowerShell Web Site
http://go.microsoft.com/fwlink/?LinkID=106031

— Windows PowerShell Team Blog:
http://go.microsoft.com/fwlink/?LinkId=143696