Windows PowerShell V1.0 (for .NET Framework 2.

0 RTM) Release Notes

Copyright (c)2006 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 V1.0 release. To learn more about Windows PowerShell, see the "Getting Started Guide," the "Windows PowerShell Primer," and the "Quick Reference." You can open them from the Windows PowerShell Start menu link.

Changes from Windows PowerShell RC2

There were no breaking changes between Windows PowerShell RC2 and the final V1.0 version of Windows PowerShell. The following list describes features that were not mentioned in the RC2 release notes, but are worth noting.

Support for ADSI:

We have added direct ADSI support to Windows PowerShell to allow users to more easily administer Active Directory. You can now create ADSI objects, get properties, and invoke methods on Active Directory objects. Example: (Create an OU) PS >$objDomain = [ADSI]"LDAP://localhost:389/dc=NA,dc=fabrikam,dc=com" PS >$objOU = $objDomain.Create("organizationalUnit", "ou=HR") PS >$objOU.SetInfo()

New Product ID:

The RC2 version of Windows PowerShell has a product ID (PID) that is stored in the following registry key with the following value: HKLM\Software\Microsoft\PowerShell\1 PID=89393-100-0001260-00301 In the final V1.0 version, the PID number is changed to: HKLM\Software\Microsoft\PowerShell\1 PID= 89383-100-0001260-04309

New Location for Profiles:

Windows PowerShell profiles are now located in the WindowsPowerShell directory, not the PSConfiguration directory. The profiles for all users are located in: %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 %windir%\system32\WindowsPowerShell\v1.0\ Microsoft.PowerShell_profile.ps1

User-specific profiles are located in a WindowsPowerShell directory in the %UserProfile% directory. On 64-bit versions of Windows, Windows PowerShell includes a second set of profiles for all users. These are located in: %windir%\syswow64\WindowsPowerShell\v1.0\profile.ps1 %windir%\syswow64\WindowsPowerShell\v1.0\ Microsoft.PowerShell_profile.ps1 As before, the Microsoft.PowerShell_profile.ps1 profiles are specific to the Microsoft.PowerShell shell, and the profile.ps1 profiles apply to all shells.

Changes from Windows PowerShell RC1

Improved error output readability:
A new object is available by using $host.PrivateData. This object, the ConsoleColorProxy, lets you set the color of output in the shell. To see the current colors, type "$host.privatedata". PS > $host.privatedata ErrorForegroundColor : Red ErrorBackgroundColor : Black WarningForegroundColor : Yellow WarningBackgroundColor : Black DebugForegroundColor : Yellow DebugBackgroundColor : Black VerboseForegroundColor : Yellow VerboseBackgroundColor : Black ProgressForegroundColor : Yellow ProgressBackgroundColor : DarkCyan To see the properties and methods of the ConsoleColorProxy object, pipe it to Get-Member. For example: PS > $host.privatedata | get-member To change the colors, set the value of a property to the desired color. For example, to change the error background color to blue, type: PS > $host.privatedata.ErrorBackgroundColor = "blue"

New byte quantifiers: KB, MB, GB

The byte quanitifier in Windows PowerShell have been changed from K, M, and G to KB, MB, and GB. For example: PS> 54K Bad numeric constant: 54K. At line:1 char:3

+ 54K <<<< PS> 54KB 55296

Added -Xor and -Bxor operators to the PowerShell script language:

Windows PowerShell includestwo new operators: -Xor (exclusive OR) and -Bxor (bitwise exclusive OR). PS> 1 True PS> 1 False PS> 1 0 PS> 1 1 -xor 0 -xor 1 -bxor 1 -bxor 0

Use of unsupported filter parameter causes error:

When a Windows PowerShell provider does not declare the Filter capability, it cannot support the Filter parameter of any cmdlet. Previously, when the Filter parameter was used with a provider that did not support it, the parameter was ignored without error. Now, if you use the Filter parameter with a provider that does not support it, Windows PowerShell generates a ProviderInvocationException and displays an error.

Windows PowerShell setup changes:

Update.exe installation technology is now used for installing Windows PowerShell on Windows XP and Windows 2003. On Windows Vista, componentbased setup technology (CBS) is used instead of the Update.exe-setup. The location of the Windows PowerShell installation folder is no longer configurable. Setup installs Windows PowerShell under %systemroot %\system32\WindowsPowerShell\V1.0 for x86 systems. The ADM file that adds the "Turn On Script Execution" group policy for Windows PowerShell is no longer included in the Windows PowerShell. It will be made available separately.

x64 package setup changes:

By default, the x64 versions of Windows 64-bit installation 32-bit installation package installs both the 32-bit and 64-bit bit PowerShell. folder: %systemroot%\system32\WindowsPowerShell\V1.0 folder: %systemroot%\Syswow64\WindowsPowerShell\V1.0

Access files and directories with special character names :

Two new features have been added to Windows PowerShell to make it

easier to refer to directories and files with names that contain an escape character (`) or wildcard characters. -- Windows PowerShell does not interpret a backtick (`) as an escape character when it appears within single quotation marks. This applies to all single-quoted strings, including strings in scripts. Example: PS> dir oct`06 Get-ChildItem : Illegal characters in path. At line:1 char:4 + dir <<<< oct`06 Get-ChildItem : Cannot find path 'C:\PS\oct 6' because it does not exist. At line:1 char:4 + dir <<<< oct`06 PS> dir 'oct`06' -- A "LiteralPath" parameter has been added to all core cmdlets that support wildcard expansion. LiteralPath prevents Windows PowerShell from resolving wildcard patterns in a path. To access a path that includes both an escape character (`) and wildcard characters, use both the LiteralPath parameter and single quotation marks. For example: PS > get-content -LiteralPath 'te[s`t].txt'

Improved Cmdlet help presentation:

Three new views were added to Default view: Example: PS >get-help Detailed view: Example: PS >get-help Full view: Example: PS >get-help Get-Help: get-item get-item -detailed get-item -full

Several improvements to Get-WMIObject cmdlet:

- WMI methods are exposed as part of the WMI Windows PowerShell adapter. - A new parameter set was added to Get-WmiObject that includes a Query parameter that takes WQL queries. - Added [WMI] as an intrinsic type that takes a string (such as a WMI PATH). You can now instantiate a WMI instance as follows: PS >[WMI]'\\JPSLAP04\root\cimv2:Win32_Process.Handle="0"' This would be the same as: PS >new-object system.management.managementobject '\\JPSLAP04\root\cimv2:Win32_Process.Handle="0"' - Designed a new way to deal with CIMDATETIMES that are STRINGS. This was implemented by having a SCRIPT method for System.Management.ManagementObject that does a ConvertToDateTime() and a ConvertFromDateTime().

Example: PS >$wmiclass PS >$dmtfDate PS >$dateTime PS >$result =

= [wmiclass]"win32_processstartup" = "20020408141835.999999-420" = $wmiclass.ConvertToDateTime($dmtfDate) $wmiclass.ConvertFromDateTime($dateTime)

No security warnings when you first start the shell:

Users are no longer prompted to trust the Microsoft signing certificate the first time that they start Windows PowerShell. The PS1XML files that are included in Windows PowerShell are signed and trusted even when the Windows PowerShell execution policy is set to "Restricted."

Miscellaneous changes:
- $host.version now reports the actual host version 1.0.0.0, not the assembly version. - A Force parameter was added to the ConvertTo-SecureString cmdlet. - Tab completion now works on property references: PS >$a = get-process outlook PS >$a.Mai<tab> => $a.MainModule then $a.MainModule.fi<tab> => $a.MainModule.FileName - Default attributes can now be used to resolve ambiguous parameter sets. For example, if a cmdlet has two parameter sets, and the command that is entered could be resolved by using either of the parameter sets, the default parameter set is used. Before this change, the command would generate a "cannot resolve parameterset" error.