Welcome to MSDN Blogs Sign in | Join | Help

Windows PowerShell RC2 Release Notes (DRAFT)

We are finishing up work on Windows PowerShell RC2.  While I can't announce an availability date at this point, I know that a lot of you are eager to see what is coming.  I think you'll be pleased.  Here are our draft release notes for RC2.  Note that this documents the major changes and not the bugfixes.

 

Jeffrey Snover [MSFT]
Windows PowerShell/Aspen Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Windows PowerShell RC 2 Drop (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 RC1 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 the Windows PowerShell Start menu link.

 

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 -xor 0

    True

    PS> 1 -xor 1

    False

    PS> 1 -bxor 1

    0

    PS> 1 -bxor 0

    1

 

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, component-based 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 package installs both the 32-bit and 64-bit bit versions of Windows PowerShell.

64-bit installation folder: %systemroot%\system32\WindowsPowerShell\V1.0

32-bit installation 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 Get-Help:

    Default view:

        Example: PS >get-help get-item

    Detailed view:

        Example: PS >get-help get-item -detailed

    Full view:

        Example: PS >get-help 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 = [wmiclass]"win32_processstartup"

    PS >$dmtfDate = "20020408141835.999999-420"

    PS >$dateTime = $wmiclass.ConvertToDateTime($dmtfDate)

    PS >$result = $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.

 

Published Friday, August 25, 2006 4:59 PM by PowerShellTeam

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# PowerShell close to release

Per the Microsoft blog posting, PowerShell RC2 is very close to release&amp;hellip;they&amp;rsquo;ve even posted
Friday, August 25, 2006 9:05 PM by Rod Trent at myITforum.com

# リリースノート先行公開Windows PowerShell RC2

リリースノート先行公開Windows PowerShell RC2
Sunday, August 27, 2006 8:14 PM by 米田 Blog ( SQL Server MEMO )

# re: Windows PowerShell RC2 Release Notes (DRAFT)

I think it's a terrible mistake to modify the PowerShell setup the way you told us:
-using package installer instead of Windows installer setup is bad from a feature standpoint
-forcing the deployment under %systemroot%\system32 is simply a bad idea:
- because of security: if failures are discovered in PowerShell core files, it could enable write access in this obscure folder (because they are neither well documented nor logical)
- because it's confusinf. MS has never been able to cleanly separate, manage, and order files from its systems and applications, and this one add-up to the confusion
Monday, August 28, 2006 5:24 AM by Sébastien Mouren

# Where's ADSI support?

I thought (http://blogs.msdn.com/arulk/archive/2006/07/25/678137.aspx) native ADSI support was one of the upcoming features of RC2. How come it is not in the What's New list?
Monday, August 28, 2006 11:19 AM by Dmitry Sotnikov

# re: Windows PowerShell RC2 Release Notes (DRAFT)

> I thought (http://blogs.msdn.com/arulk/archive/2006/07/25/678137.aspx) native ADSI support was one of the upcoming features of RC2. How come it is not in the What's New list?

That is an omission - thanks for catching it.

Jeffrey Snover [MSFT] Windows PowerShell/Aspen Architect Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx


Tuesday, August 29, 2006 9:16 AM by PowerShellTeam

# re: Windows PowerShell RC2 Release Notes (DRAFT)

How do cmdlet developers create the equivalent of a LiteralPath parameter?  From Reflector it appears PoSH is using a NoGlob property in your internal CoreCommandBase class. But we subclass from Cmdlet or PSCmdlet.
Saturday, September 09, 2006 3:38 PM by Keith Hill

# re: Windows PowerShell RC2 Release Notes (DRAFT)

Excellent question, Keith.

If you're writing a cmdlet provider, you'll get the -LiteralPath parameter for free (as we write the cmdlets that interact with your provider.)  If you're writing a cmdlet, and that cmdlet accepts wildcards on its "name" parameter, then you should offer an alternate parameter set that instead offers a "LiteralName" parameter.

In the section of your cmdlet that does the wildcard processing -- bypass that resolution when the user specifies the LiteralName parameter.
Monday, September 11, 2006 11:24 AM by PowerShellTeam

# re: Windows PowerShell RC2 Release Notes (DRAFT)

As someone who used to manage systems using scripts and has seen my ability to do so reduced as functions and information migrated to the registry and AD, powershell looks like it might make my job interesting again. Thanks very much.

You confirm that native ADSI should be in RC2, how about remote registry access? Or have I missed this elsewhere?

Thanks again. Powershell looks like 'I.T. as it should be'.
Thursday, September 21, 2006 9:42 PM by SteveW

# re: Windows PowerShell RC2 Release Notes (DRAFT)

>You confirm that native ADSI should be in RC2, how about remote registry access? Or have I missed this elsewhere?

Correct - native ADSI support is in but Remote Registry access did not make it.  You can however access remote Registries by accessing the raw .NET libraries to do this.

Jeffrey Snover [MSFT]
Windows PowerShell/Aspen Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
Friday, September 22, 2006 1:12 AM by PowerShellTeam

# PowerShell RC2 is available...

Sort of. Perhaps, within a couple of hours it will really be available, but right now, all I can point
Wednesday, September 27, 2006 5:49 AM by Talking Out Loud with ASB

# PowerShell Remote Registry Access

I've tried pulling up remote registries using .NET in PowerShell, and it doesn't seem to get all the subkeys.  For instance, on a machine where I know HKCU has at least 12 subkeys, when I retrieve it remotely from that machine, it only pulls up 10.  And there are subkeys of HKCU/software that I know are present, but they aren't retrieved.  For HKLM, I can get all subkeys, so why can't I get them all for HKCU?

Thursday, November 02, 2006 11:56 AM by JonP

# remote shell

I'm in a unix shop who is very accustomed to REXEC. Is there going to be a way to remotely administrate servers/run scripts from 1 central location? I found something 'similar' here http://www.gotdotnet.com/workspaces/releases/viewuploads.aspx?id=ce09cdaf-7da2-4f1c-bed3-f8cb35de5aea but my company does not allow .EXE's unless provided by primary vendor (in this case, microsoft).  Thanks!

Tuesday, November 07, 2006 12:25 PM by dave cole

# re: Windows PowerShell RC2 Release Notes (DRAFT)

This is definitely on our radar, Dave.

Lee

Tuesday, November 07, 2006 1:15 PM by PowerShellTeam

# re: Windows PowerShell RC2 Release Notes (DRAFT)

Just wondering...

When I get email notifications of additions to this blog they do not come with an active link.  I am reading my mail in Outlook.    It looks like this

posted at: http://blogs.msdn.com/powershell/archive/2006/08/25/Windows-PowerShell-RC2-Release-Notes-.aspx#1018910

Is this by design?  Cutting and pasting to the RUN Command is a 'drag'.

Tuesday, November 07, 2006 1:28 PM by Fred Jacobowitz

# re: Windows PowerShell RC2 Release Notes (DRAFT)

Hi Fred;

This is a design feature of Outlook --  I believe if you add the sender address to your contacts, the links will become active.

Lee

Tuesday, November 07, 2006 1:59 PM by PowerShellTeam

# Having to uninstall PowerShell (still) makes me sad

This isn’t new to Windows 7 (I got the same when upgrading from XP to Vista). However, it still feels

Monday, January 26, 2009 7:33 AM by James Manning's blog

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker