TOPIC about_Windows_PowerShell_2.0 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-Typ...
magdula294