Windows PowerShell V2 (Community Technology Preview) Release Notes 

Copyright© 2007 Microsoft Corporation. All rights reserved.

THIS INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

This document explains the most recent changes to the Windows PowerShell release. To learn more about Windows PowerShell, see the "Getting Started Guide", the "User Guide", and the "Quick Reference". You can open them from the Windows PowerShell Start menu link. 

Notes:
·	This software is a pre-release version.  It will not work the way a final version of the software does.  Features will change before final release.
•	The goal of this CTP release is to provide a preview to the community on early thinking and direction on key 2.0 features and get early feedback on them.
·	Windows PowerShell 2.0 CTP release is compatible with and replaces Windows PowerShell 1.0. You must un-install PowerShell 1.0 to install the PowerShell 2.0 CTP release.
•	Windows PowerShell 2.0 CTP release will continue to use the execution policy setting of PowerShell 1.0, if present. PowerShell 1.0 installer does not remove or change the execution policy on un-installation.
•	PowerShell 2.0 Remoting features will not work correctly on Windows Vista RTM. Please install Windows Vista Service Pack 1 (SP1) Beta to enable PowerShell Remoting features.
•	When Windows PowerShell 2.0 CTP is launched with an execution policy of “Restricted,” it will display an error message while loading the types and formatting files. To prevent this error message, change the execution policy to one that enables PowerShell’s scripting features – such as RemoteSigned. For more information about PowerShell’s execution policies, type “Get-Help about_signing”.
·	Graphical PowerShell is a very early alpha version meant for previewing early thinking and getting feedback.
•	PsJobs rely on the remoting features of Windows PowerShell 2.0. To use PsJobs, remoting must be enabled on Windows PowerShell, even if the PsJob runs only on the local computer.

Supported Platforms:
This release of Windows PowerShell installs on x86 and x64 platforms of Windows XP-SP2, Windows Server 2003-SP2, Windows Vista, Windows Vista-SP1, and Windows Server 2008.

Pre-Requisites:
·	.Net Framework 2.0 is required.
·	 WS-MAN is required to use Remoting Features
·	.Net Framework 3.0 is required to use Graphical PowerShell and Out-GridView.

Installing Windows PowerShell
To install Windows PowerShell 2.0, turn-off or uninstall any previous version of Windows PowerShell. To install the CTP release, Run the MSI installer that is applicable for your system.

Uninstalling Windows PowerShell 1.0
·	Windows XP-SP2 and Windows Server 2003: Under Add/Remove Program, select the option to show updates. Remove the PowerShell updates as applicable for your system: KB926139 (en-us),KB926140 (localized), KB926141 (MUI pack)
·	Windows Vista: Go to Control Panel->Program and features->Installed Updates. Uninstall the PowerShell update: KB928439
·	Windows Server 2008: Starting with Beta3 of Windows Server 2008, PowerShell 1.0 comes as an in-band optional component. If you have enabled PowerShell 1.0, you must turn the feature off before you can install PowerShell V2 CTP. Launch Server Manager and choose the option to remove Features. Select PowerShell from the list and disable the feature.
 
Enable Remoting:
PowerShell Remoting feature relies on Windows Remote Management (WS-Man) technology. In order for remoting to work, make sure that the WS-Man Winrm service is installed and started. To verify that Winrm service is running, do the following:
PS> get-service winrm

Status   Name               DisplayName
------   ----               -----------
Running  WinRM              Windows Remote Management (WS-Manag...
 
Setup places a PowerShell script (Configure-Wsman.ps1) in $pshome folder that configures WS-Man settings. To configure WS-Man for PowerShell remoting feature, please run the configure-WSMan.ps1 script from PowerShell folder. This script does not start or stop WinRM service.

& $pshome\Configure-Wsman.ps1 (run elevated for Windows Server 2008 or Windows Vista SP1) 

Breaking Changes from Windows PowerShell 1.0

1.	The value of the PowerShellEngine key under HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine has been changed to 2.0
2.	New language Keywords Data and Cmdlet have been added. What this means is that commands named ‘data’ or ‘cmdlet’ will be interpreted as language Keywords which will result into parse errors. 
3.	Changes in Argument separator behavior. In PowerShell 1.0, $a.method(,1) is treated as a call with an array of 1 element but $a.method(1,,2) as a parse error. In PowerShell 2.0, both are treated as parse errors.
4. New Cmdlets, variables have been added (listed below). These can conflict with existing variables and functions.  

New Features in Windows PowerShell V2 
(See Additional Notes for Examples)

PowerShell Remoting
Windows PowerShell 2.0 provides support for executing Cmdlets and Scripts remotely. PowerShell Remoting allows managing a collection of remote machines from a single client. Managing remote computers using PowerShell 2.0, requires that PowerShell 2.0 be installed on all the computers taking part in the operation;  that is the client computer and the computer(s) being managed.

For more information:
·	get-help About_Remoting
·	get-help Invoke-Expression
·	get-help New-Runspace
·	get-help Get-Runspace
·	get-help Remove-Runspace

Known issue:
·	To use Remoting Cmdlets and features, PowerShell must be started as administrator/elevated.

Background Jobs
Windows PowerShell 2.0 introduces the concept of a background job (PsJob). A PsJob runs a command or expression asynchronously and "in the background" without interacting with the console. The command prompt returns immediately and you can query for the job results at your convenience.  You can run background jobs on a local or remote computer.

For more information see:
·	get-help About_PSJob 
•	get-help Start-PSJob
·	get-help Receive-PSJob
·	get-help Remove-PSJob
·	get-help Wait-PSJob
·	get-help Get-PSJob

ScriptCmdlets
ScriptCmdlets allow you to write cmdlets in PowerShell script, rather than compiled C# and VB.NET code.
For this release, all cmdlet parameters are supported except the following:
·	Parameter sets
·	Help
For more information:
·	Get-Help about_scriptcmdletparameters
·	Get-Help about_scriptcmdletmethods
·	Get-Help about_scriptcmdletattributes

Steppable Pipelines
This feature allows turning a script-block into a steppable pipeline and then controlling the sequence of activities by individually calling Begin(), Process() and End() on the pipeline.

Data Language
The data language is a subset of the PowerShell language that allows better sharing of scripts. It also allows better separation of data from the rest of the code in your script.

For more information:
·	Get-Help about_data_section
·	Get-Help ConvertFrom-StringData

Script Internationalization
This new feature allows PowerShell script authors to write scripts that can be translated to any language supported by Windows.
You can separate string resources from the rest of the code, using the new data language feature (above). Using the new Import-LocalizedData cmdlet, you can instruct PowerShell to check the operating system’s UI culture, check for a translated data file (.psd1) in the proper culture folder (such as en-US, or de-DE), and replace the original strings with the translated ones.

For more information:
·	Get-Help about_script_internationalization
·	Get-Help Import-LocalizedData
·	Get-Help ConvertFrom-StringData
·	Get-Help about_data_section

Script Debugging
New debugging features have been added: You can now set breakpoints on lines, columns, functions, variables, and commands. You can also specify actions to run when the breakpoint is hit. Stepping into, over, or out of functions is also supported. You can also get the call stack.
For more information:
·	Get-Help about_debugger
·	Get-Help New-PSBreakPoint
·	Get-Help Get-PSBreakPoint
·	Get-Help Enable-PSBreakPoint
·	Get-Help Disable-PSBreakPoint
·	Get-Help Remove-PSBreakPoint
·	Get-Help Step-Into
·	Get-Help Step-Over
·	Get-Help Step-Out
·	Get-Help Get-PSCallStack

New Operators:

1.	Splatting operator (@): PowerShell V2 supports splatting operator (@)to pass a collection of parameters
2.	-Split: The -split operator enables a user to split a string into an array of substrings, based on a separator.
3.	–Join: The -join operator concatenates multiple strings from a string array into a single string, separated by the separator.

New Variables:
1.	$commandLineParameters: Accumulates command-line and pipeline parameters. Cmdlets can access it through MyInvocation.CommandLineParameters.
2.	$PSVersionTable: PowerShell version information is available through this variable
3.	$Culture: Current Culture information is available through this variable
4.	$UICulture: Current UI Culture information is available through this variable

New Cmdlets:
The following cmdlets have been added in PowerShell 2.0. See help for these Cmdlets for details about how to use them.

Get-PSBreakpoint	Get-PSCallStack
	Remove-PSJob
	
New-PSBreakpoint
	ConvertFrom-StringData	Start-PSJob
	
Disable-PSBreakpoint
	Import-LocalizedData
	Stop-PSJob
	
Enable-PSBreakpoint
	Get-Runspace
	Wait-PSJob 
	
Remove-PSBreakpoint
	New-Runspace
	Invoke-WMIMethod
	
Step-Into
	Remove-Runspace
	Remove-WMIObject	
Step-Out
	Get-PsJob
	Set-WMIInstance
	
Step-Over	Receive-PSJob
	Out-GridView

Constrained Runspaces
Constrained Runspaces allows creation of PowerShell Runspaces with a set of Constraints. Constraints include the ability to restrict access and execution of Commands, scripts, and language elements when using the Constrained Runspace.

RunspacePools
Support has been added for RunspacePools. RunspacePools enables concurrent execution of commands by efficiently managing a pool of runspaces on behalf of the user. See the SDK documentation for more details about how to use RunspacePool APIs.

Parser Tokenizer API
Another new feature in this release is the Parser Tokenizer API which lets you determine the Tokens associated with a PowerShell script. This API enables many scenarios such as building syntax color highlighters, making your scripts production ready by expanding aliases and so on. See SDK documentation for more details about how to use the API.  

New PowerShell Hosting APIs
The release introduces new APIs which simplifies Hosting PowerShell Engine in your Applications and building GUI Management applications on top of PowerShell Cmdlets. Please see the SDK documentation for the new APIs.

Metadata APIs for Command and Parameters
New APIs allow access to command and parameter metadata (similar to the metadata obtained in the shell via get-command). This metadata can be used to automate generation of stub ScriptCmdlet code from Cmdlet Type.
 
Graphical PowerShell
This release includes a very early alpha version of the new graphical shell. A feedback button has been placed on the toolbar to hear your feedback, so please use it to report bugs, likes and dislikes. If you do not have a mail client installed, send feedback to gPSfback@microsoft.com

Features:
·	An interactive shell with syntax coloring and Unicode support.
·	A multi-tabbed scripting pane for loading / composing multiple ps1 files.
·	The ability to run (dot-source) a script by pressing <F5>, or by clicking the “Run” on the toolbar.
·	The ability to run (dot-source) parts of a script by selecting the desired parts and pressing <F5>, or clicking “Run” on the toolbar.
·	Multiple runspaces (shells): You can open up to eight runspaces inside Graphical PowerShell, by using the “Shell” menu, or pressing the tab “stub” when it becomes visible (after the second runspace)

Known issues:
·	There is no support for any commands that require user input, including legacy commands, such as: netsh, telnet, ftp, nslookup etc.
•	There is no support for Tab Completion.
·	PSHost functionality is not supported.
·	Text output still has the ellipses (…) although the screen is wide enough to display more text
•	The script editor is slow for large files (> 1,000 lines)

This feature requires Microsoft .NET Framework 3.0.

Out-GridView
The new Out-GridView cmdlet displays the results of other commands in an interactive table, where you can search, sort, and group the results. For example, you can send the results of a get-process, get-wmiobject, or get-eventlog command to out-gridview and use the table features to examine the data. 

This feature requires Microsoft .NET Framework 3.0. For more information, type "get-help out-gridview".

Known issue:
·	The command output that you send cannot be pre-formatted, such as by using the Format-Table or Format-Wide commands.

Improvements in Windows PowerShell V2

Changes to TabExpansion function:
The TabExpansion function now only shows unique parameters and lists them in sorted order.

New parameters added to Select-String:
select-string now supports new parameters, such as:
·	-Context: This allows you to see lines before and after the match line
·	-AllMatches: which allows you to see all matches in a line (Previously, you could see only the first match in a line)
·	-NotMatch: Equivalent to grep -v
·	-Encoding: to specify the character encoding

Updated Type Adapters:
Member lookup algorithm for Type Adapters has been updated to include Base members. Members on the Base Object for Adapted types are now directly accessible on the object. This removes the need to use PSBASE property to access base members.

Improvements to Get-Member:
Get-Member cmdlet now supports a –View and –Force parameter. Valid values for –View parameter are "Extended, Adapted, Base, All". The default value is “Extended,Adapted”. Getter and Setter Methods are not shown by the default get-member output. Since adapted Types now expose Base members, use –view All to list Base members in the get-member output.

Improved ADSI support:
ADSI adapter now allows access to Base Methods and Properties. [ADSISearcher] Type accelerator has been added for System.DirectoryServices.DirectorySearcher Class. Two CodeMethods, ConvertDNBinaryToString and ConvertLargeIntegerToInt64 have been added to DirectoryEntry type to simplify marshalling data between ADSI and PowerShell.

New parameters added to Get-WMIObject:
Get-WMIobject cmdlet now supports following parameters -Impersonation, -Authentication, -Locale, -EnableAllPrivileges, -Amended, -DirectRead, -Authority
The new parameters allow setting Authentication and Impersonation properties which are needed to make secure connections to a remote computer.

Improved Bitwise Operators:
The Bitwise operators now work with Int64

New PowerShell APIs
This release provides new APIs for programmatic access to many of the features listed above. See SDK documentation for a complete list of new Types and APIs. The following is a quick summary of Key APIs and related features to help you get started. Note that this is a pre-release drop and the Type Names and APIs are subject to change.

Feature Area	Related Types	
Hosting, RunspacePools	System.Management.Automation.Runspaces.PowerShell, System.Management.Automation.Runspaces.PSDataCollection, System.Management.Automation.Runspaces.RunspacePool
System.Management.Automation.Runspaces.PSCommand	
Parser Tokenizer	System.Management.Automation.PSParser, System.Management.Automation.PSToken, System.Management.Automation.PSTokenType, System.Management.Automation.PSParseError	
Constrained Runspaces	System.Management.Automation.Runspaces.InitialSessionState
System.Management.Automation.Runspaces.SessionStateAssemblyEntry
System.Management.Automation.Runspaces.SessionStateCmdletEntry
System.Management.Automation.Runspaces.SessionStateProviderEntry
System.Management.Automation.Runspaces.SessionStateScriptEntry
System.Management.Automation.Runspaces.SessionStateAliasEntry
System.Management.Automation.Runspaces.SessionStateApplicationEntry
System.Management.Automation.Runspaces.SessionStateFunctionEntry
System.Management.Automation.Runspaces.SessionStateVariableEntry	
MetaData APIs	System.Management.Automation.ProxyCommand, System.Management.Automation.CommandMetadata, System.Management.Automation.ParameterMetaData	

Blogs, SDK and Feedback
Your feedback is important to us. For suggestions/questions about PowerShell, use Windows PowerShell blog and the Connect Website

Additional Notes

Feature Examples:

Remoting Example:	
#Run get-process on a remote machine
PS> invoke-expression –command “get-process” –ComputerName Machine1
Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    125       8    12704      15472    61            1036 audiodg
  16441      12     5524       7512    73            1816 casha
   2362      31    16384      15144    99            2284 CcmExec
     22       3     2516       2320    49     0.84   3076 cmd
    100       7     7180       6412    97            4416 cmd

#Start a Background Job on a Remote Machine
PS> $job = start-psjob –command “get-process” –ComputerName Machine2

Splatting Example:	

PS> function foo ($a, $b, $c) {2*$a; 8*$c }
PS> $list=3,2,1
PS> foo @list 
6
8

Split Operation Example

PS> $x = “1,2,3,4”
PS> $x –split “,”, 2
1
2,3,4

Join Operator Example

PS> $v2 = ‘ScriptCmdlets’, ‘FunctionCmdlets’, ‘ScriptBlockCmdlets’
PS > -Join $v2
ScriptCmdletsFunctionCmdletsScriptBlockCmdlets
PS> $v2 -Join ‘,’
ScriptCmdlets,FunctionCmdlets,ScriptBlockCmdlets

ScriptCmdlet Example

Get-childitem ScriptCmdlet that only shows containers if –containersonly parameter is passed.

cmdlet Get-ChildItem `
	{
   	param(
   	[Position(0)] `
	      [ValueFromPipeline] `
		[ValueFromPipelineByPropertyName] `
		[System.String[]] `
		$Path,

		[switch] $ContainersOnly 
 		)
  		begin 
    	{ 
          $wrappedCmdlet = get-command -type cmdlet Get-ChildItem 
          [void] $CommandLineParameters.Remove("ContainersOnly")
          if ($containersonly)
          {
           $sb = {& $wrappedCmdlet @CommandLineParameters |where    {$_.PSIsContainer} }
          }
          Else 
          {
           $sb = { & $wrappedCmdlet @CommandLineParameters }
          }
          $sp = $sb.GetSteppablePipeline()
          $sp.Begin($cmdlet)
          }
          process { $sp.Process($_) }
    	end { $sp.End() }
	}