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.

The "Getting Started Guide" is now available with the Windows PowerShell RC1 Documentation Pack along with the "Windows PowerShell User Guide" on http://www.microsoft.com/downloads/details.aspx?FamilyId=B4720B00-9A66-430F-BD56-EC48BFCA154F&displaylang=en . These guides answer your basic questions about Windows PowerShell and help you get started with the product.

Changes from Windows PowerShell "Monad" Beta 3 (for .NET Framework 2.0 RTM)

Product name changes

This release incorporates the new Windows PowerShell name change. The terms "MSH" and "Monad" are no longer used and are now replaced by the terms "PS" and "Windows PowerShell" respectively. The name change introduced a number of changes that would affect everyone self hosting previous PowerShell "Monad" beta releases. The following is a summary of the changes that were made because of the product name changes:

  • "MSH" which was the acronym for "Microsoft Monad Shell" is now replaced across the product with "PS" as the acronym for "Windows PowerShell"
  • "Msh.exe" is now replaced with "PowerShell.exe"
  • The registry entries of the product have also changed from "HKLM:\SOFTWARE\Microsoft\MSH" to "HKLM:\SOFTWARE\Microsoft\PowerShell"
  • The root key for a PowerShell installation is now PowerShell
  • Changed MshEngine to PowerShellEngine
  • Changed MshVersion to PowerShellVersion
  • Changed MshSnapins to PowerShellSnapins
  • Changed Microsoft.Msh shell id to Micorosoft.PowerShell shell id

A large number of our public API names have been changed to reflect the "MSH" to "PS" changes as follows:

  • 'CustomMshSnapIn' has been changed to 'CustomPSSnapIn'
  • The "MSH c:\>" Prompt has been changed to "PS c:\>"
     

Extension changes:

  • Changed .mshxml to .ps1xml
  • Changed .msh to .ps1
  • Changed .mcf to .psc1

The number at the end of PowerShell’s script extension  ".ps1" indicates the version of PowerShell that the script is compatible with and allows the script to call the appropriate version of Windows PowerShell. The script extension ".ps1" means that the script is compatible with PowerShell Version 1.0 (which requires the .NET Framework 2.0). We know that scripts that are used in an IT production environment can remain unchanged for an extended period of time. The addition of the version number to the script extension enables the side-by-side execution of scripts that are written for the current version of PowerShell as well as future versions of PowerShell.

PowerShell does not allow side-by-side installation with previous Monad releases. You must first completely uninstall Monad before installing Windows PowerShell RC1 release.
 

Eventlog changes:

  • The event log message file is not psmsg.dll
  • The event log name is PowerShell instead of MonadLog
  • Event log Messages now refer to PowerShell instead of Monad

Assembly name changes:

Replaced Msh in the product assembly names with PowerShell.

Parameters changes due to product name change

CmdletName ParameterName
Get-PSProvider MshProvider to PSProvider
Get-PSDrive MshProvider to PSProvider
New-PSDrive MshProvider to PSProvider
Remove-PSDrive MshProvider to PSProvider
Trace-Command MshHost to PSHost
Set-TraceSource MshHost to PSHost
Get-Command MshSnapin to PSSnapin
Get-Location MshProvider to PSSnapin
Get-Location MshDrive to PSDrive

 

Other changes introduced in this release

The Windows PowerShell team did a complete pass of all cmdlets to ensure all cmdlets shipping as part of the Windows PowerShell product conform to the developer guidelines specified in the SDK. The following is a list of all changes which were done as part of this cleanup process.

   Cmdlet cleanup changes

This release incorporates the "Cmdlet cleanup" changes to the Windows PowerShell. The Windows PowerShell team performed a complete pass to ensure that all cmdlets that are shipping as part of the Windows PowerShell product conform to the developer guidelines that are specified as part of the SDK. The following is a list of all changes which were done as part of this cleanup process:

General

  • All "boolean" parameters across all cmdlets are now SwitchParameters. This is highly backward-compatible, however the name and "sense" of parameters which formerly defaulted to true have been switched.
  • Parameter binding is changed for "bool" and "SwitchParameter". Previously, the full ETS algorithm for conversion to bool was used. That algorithm would accept virtually anything and cast it to either true or false. Now, you must specify either $true or $false, or an int value (0 is false, everything else is true).
  • Default formatting is improved for a number of object types.
  • The profiles directory is now named "PSConfiguration" instead of "Msh".
  • Cmdlet name casing has been changed to conform to PascalCasing according to guidelines.
  • Many updates to types and formatting files to improve the usability of the shell.
  • The MshPath attribute has been removed.
  • The Openmode parameter has been replaced by a combination of –Append –NoClobber. -Append has precedence over –NoClobber.
  • The Force parameter has been added to cmdlets which writes to a file to overcome the readonly attribute, including Out-File, Start-Transcript, Export-Alias, Export-Csv, Export-Clixml, Trace-Command, Set-TraceSource, and Set-AuthenticodeSignature.
  • The ValueFromPipeline and ValueFromPipelineByPropertyName have been modified to a number of parameters across the board.
Cmdlet name changes
  • CMDLET RENAME: combine-path -> join-path
  • CMDLET RENAME: parse-path -> split-path
  • CMDLET RENAME: match-string -> select-string
  • CMDLET RENAME: time-expression -> measure-command
  • CMDLET RENAME: write-object -> write-output
  • CMDLET RENAME: All *-property cmdlets renamed to *-itemproperty: clear-itemproperty, copy-itemproperty, get-itemproperty, move-itemproperty, new-itemproperty, remove-itemproperty, set-itemproperty
  • CMDLET RENAME: trace-expression -> trace-command
  • CMDLET RENAME: invoke-command -> invoke-expression
  • CMDLET RENAME: Import-SecureString -> ConvertTo-SecureString
  • CMDLET RENAME: Export-SecureString -> ConvertFrom-SecureSring
  • CMDLET RENAME: Get-Provider -> Get-PSProvider
  • CMDLET RENAME: Get-drive -> Get-PSDrive
  • CMDLET RENAME: New-drive -> New-PSDrive
  • CMDLET RENAME: Remove-drive -> Remove-PSDrive

Removed cmdlets

New-SecureString was removed, you can use Read-Host –AsSecureString for the same functionality


New cmdlets

  • Set-ExecutionPolicy
  • Get-ExecutionPolicy

These cmdlets support changing the execution policy of the shell, which by default, does not allow scripts to execute. To permit, script execution, type:

Set-ExecutionPolicy RemoteSigned

This allows local scripts to be run without a valid signature.


New aliases

  • % is now an alias for foreach-object
  • ? is now an alias for where-object
  • write is now an alias for write-output
  • diff is now an alias for compare-object
  • group is now an alias for group-object
  • tee is now an alias for tee-object
  • gwmi is a new alias for Get-WmiObject

Class renames

All classes implementing CmdletAttribute have been renamed to VerbNounCommand. Some of their base classes have also been renamed. This does not affect clients which access them as cmdlets, only clients directly accessing Cmdlet (not PSCmdlet) classes via the new API.

Other minor parameter fixes:

Changes in how Windows PowerShell uses parameters: Previously, a parameter of type Boolean would not require a value, and when a Boolean parameter was used, the value would default to true. This behavior has been changed. Parameters of type Boolean now require a Boolean value to be provided.

We have in most cases moved away from "-FilePath" as a parameter name and toward -Path alias to PSPath. We should use “FilePath” when the Cmdlet only works with file system path, even when this is planned for a future date. Both “FilePath” and “Path” are aliased to PSPath. We use “FilePath” in the following Cmdlets:

Get-AuthenticodeSignature __AllParameterSets
Get-PfxCertificate __AllParameterSets
Out-File __AllParameterSets
Set-AuthenticodeSignature __AllParameterSets
Set-TraceSource optionsSet
Tee-Object File
Trace-Command expressionSet
Trace-Command commandSet


 

CmdletName Description Before Fix
Get-Date The -To parameter has been changed to -Date.

Only -Date accepts pipelined input, either by property name or by type.

The -Unix parameter has been changed to -UFormat.
-To,

-Unix

-Date,

-Uformat

Set-Date The -To parameter has been changed to -Date.

Only -Date accepts pipelined input, either by property name or by type.

-To -Date
New-TimeSpan The -From parameter has been changed to -Start.

The -To parameter has been changed to -End.

The -Day parameter has been changed to -Days.

The -Hour parameter has been changed to -Hours.

The -Minute parameter has been changed to -Minutes.

The -Second parameter has been changed to -Seconds.

The -Start parameter accepts pipelined input, either by property name or by type and will produce a result for each valid object piped to it.
-From

-To

-Day

-Hour

-Minute

-Second

 

 

-Start

-End

-Days

-Hours

-Minutes

-Seconds

 

Add-member Added -New parameter.

The -Type parameter has been changed to -MemberType.

The type of the -InputObject parameter has been changed from an array to a singleton.

Added a -PassThru parameter.

  -PassThru

-New

*-Object New aliases.   new, tee, write, Diff
Measure-Object Parameter renaming for measure-object. -Max, -Min, -Words, -Characters,

-Lines

-Maximum, -Minimum, -Word, -Character,

-Line

Group-Object Fixed the functionality of GroupInfo object formatting.    
New-Object Added a new -Strict parameter. -Arguments -Argument;

-Strict

Select-Object Changed -Expand to -ExpandProperty; The -First and -Last parameters now take 0. -Expand -ExpandProperty
Compare-Object Changed -RecordDifference to -ExcludeDifferent with a default value of false.

Changed -RecordEqual to -IncludeEqual

-RecordDifference -ExcludeDifferent
Where-Object Changed -RecordEqual to -IncludeEqual -ScriptToApply -FilterScript
Tee-Object Changed -FileName to -PSPath aliased to Path; removed -encoding ASCII and Width 1024 hard coded Out-File call. -FileName -FilePath aliased to PSPath
Set-ItemProperty -Property parameter has been renamed to -Name parameter. -Property

-PropertyTable

-Name

-InputObject

Clear-ItemProperty -Property parameter has been renamed to -Name parameter. -Property -Name
Copy-ItemProperty -Property parameter has been renamed to -Name parameter. -Property -Name
Get-ItemProperty -Property parameter has been renamed to -Name parameter. -Property -Name
Move-ItemProperty -Property parameter has been renamed to -Name parameter. -Property -Name
New-ItemProperty -Property parameter has been renamed to -Name parameter. -Property -Name
Remove-ItemProperty -Property parameter has been renamed to -Name parameter. -Property -Name
Rename-ItemProperty -Property parameter has been renamed to -Name parameter. -Property;

-Name

-Name;

-NewName

*-Service    -PathToExecutable

-ServiceName

-Input
-BinaryPathName

-Name aliased to ServiceName

-InputObject
*-Drive and *-Provider *-Drive and *-Provider cmdlets are renamed to *-PSDrive and

*-PSProvider.

*-Drive;*-Provider *-PSDrive;*-PSProvider
*-Acl Removed ValueFromPipelineByPropertyName from all -include, -Exclude, and -Filter.  
Export-SecureString; Import-SecureString -SecureString of Export-SecureString and -String of Import-SecureString Cmdlets now support ValueFromPipeline attribute.    
*-Process Changed -ProcessName to -Name alias -ProcessName, add alias ProcessId to -Id -ProcessName

-ProcessId

-Name aliased to ProcessName

-Id aliased to ProcessId

Format-* -WriteErrors property name parameter is changed to -WriteError; -DisplayErrors parameter is changed to -DisplayError -WriteErrors; -DisplayErrors; -Columns -WriteError; -DisplayError; -Column
Out-Printer Renamed –Printer to –Name with –Printername alias for Out-Printer -Printer -Name aliased to PrinterName.
Get-Eventlog -Newest parameter accepts 0 as a valid value.    
Read-Host The -SecureString param for read-host is boolean, it conflicts with -SecureString parameter of Import/Export-SecureString which is [SecureString].

It is now renamed to -AsSecureString to be consistent with -AsString parameter of Get-Unique and Get-EventLog.

-SecureString -AsSecureString
Get-Command   -CommandArguments -Argument
Trace-Command   -CommandArguments -Argument
Set-PSDebug Added -Strict Parameter. You can now do Set-PSdebug –Strict and the interpreter will throw an exception if the referenced variable hasn’t been set yet.   -Strict

 

 

Design changes:

1- Numbers that are entered as parameters to functions, the original token text will be preserved and used when doing a ToString() on the number. This only applies to parameters. Numbers created in an expression are just numbers. To make this work, we added an internal member on PSObject to hold the token text.

Also, when trying to convert a number to a type that has no direct conversion, a secondary conversion attempt will be made with the string representation of the number.

Example:
new-item -type directory -name:0100

...which would have created a directory called "100" previously will create one called "0100" with this change.

2- PowerShell is now consistent with how it treats collections in adding and multiplying. The rule now treats enumerable objects as collections. Method lookup is used for indexing on anything that is not a string, Type.IsArray, or IDictionary.

3- In this release we implemented the ability for Windows PowerShell to support Cmdlet logging and command-line execution. Cmdlets that reside within a PSSnapin that have been designated for logging will result in EventLog entries in the Windows PowerShell EventLog when they are executed. The designation for logging is handled on a PSSnapin basis. If no logging designation is made, then no logging will take place.

4- At depth 1, we serialize all non basic types using ToString(). Since an array is not a basic type, it is serialized as a string. [Note: We use PSObject.ToString() which for IEnumerables does ToString() on each item and returns a concatenated string.] For collections (array, list, queues), ToString() is no longer called on the collection. Instead, a collection of strings is returned by calling ToString() on each item in the collection.

5- Added a public API to resolve the current path. The change adds a public overload method to GetUnresolvedProviderPathFromPSPath that returns the provider that the path resolved to.

6- We added support for parameters and variables tab completion. This was done by having the host call a PowerShell function TabExpansion that takes two parameters – the line being entered and the last token on that line.

7- To improve usability of the multiple snapin model, we made the following changes.

- Added the .psc1 extension to PATHEXT

- Associated .psc1 files with PowerShell.exe

That way, a user can simple do:

Start-Run-> MyConsoleFile

or

Start-Run-> MyConsoleFile.psc1

or

[Double click] MyConsoleFile.psc1

8- Profiles directory is now named "PSConfiguration" instead of "Msh".

9- Add a new preference variable: FormatEnumerationLimit which allows you to set the maximum DEPTH we go into for formatting. The default value is set to four.

10- Change $ConfirmPreference to be of type ConfirmImpact (none, low, medium, high), default is High. Confirmation occurs on all cmdlets with ConfirmImpact equal or higher to $ConfirmPreference.

11- You can now do set-PSDebug –strict and the interpreter will throw an exception if the referenced variable hasn’t been set yet.


 

Changes from Windows PowerShell Beta 2 (for .NET Framework 2.0 Beta RC/RTM)

Although this release uses essentially the same code base as the previous Beta 2 release (except moved to the RTM version of .NET Framework 2.0), a few changes were made:

"Single Shell" Changes:

This release incorporates the "Single Shell" changes to the Windows PowerShell.

The user-visible operation of Monad at startup is the same; however, Monad now groups cmdlet assemblies into "MshSnapins" and dynamically loads MshSnapins at startup based on registry settings. To learn more about the Monad MshSnapins simply type: get-help about_MshSnapins. This help topic also talks about how to create and save console files.

Monad added the following cmdlets to control MshSnapins:

  • add-mshsnapin [-Name] String[] [-PassThru]
  • get-mshsnapin [[-Name] String[]] [-Registered]
  • remove-mshsnapin [-Name] String[] [-PassThru]
  • export-Console [[-Name] String] [-Force]

More details are available by running get-help on each one of these cmdlets.

Note: The new MshSnapins cmdlets are not available in a custom shell.

To learn more about how to create a MshSnapin, refer to the GettingStarted.rtf documentation and look up: Appendix D - Creating a SnapIn.

Literal numbers Cmdlet parameters:

Cmdlet parameters that are literal numbers will now be treated as numbers, whereas previously they were treated as strings. This may affect a script if the type of the parameter can be converted from a string but not from an integer. The user fix is to enclose the literal number in quotes. This change was in the earlier Monad Beta 2 but was not well communicated before.

The remaining notes are unchanged from the ones included with the prior Windows PowerShell Beta 2 (for .NET Framework 2.0 Beta 2) release.

MAML Cmdlet help schema

Cmdlet help now adhere to the Microsoft MAML schema. All Cmdlet help content are in the *help.xml files in the Monad application folder under the correct culture folder:

System.Management.Automation.Commands.Management.dll-Help.xml
System.Management.Automation.Commands.Utility.dll-Help.xml
System.Management.Automation.ConsoleHost.dll-Help.xml
System.Management.Automation.dll-Help.xml
System.Management.Automation.Security.dll-Help.xml

New add-member Cmdlet

We have introduced a new add-member cmdlet. To learn more about this Cmdlet, please check its usage by simply typing get-help add-member.

Monad assemblies are now NGEN'ed/GAC'ed

All Monad assemblies are installed using the Native Image Generator Ngen.exe and are installed in the Global Assembly Cache folder "GAC" by the Monad MSI installer. This allows the assemblies to load and execute faster, because it restores code and data structures from the native image cache rather than generating them dynamically.

Preference variables interaction changes

The effective settings which govern the behavior of ShouldProcess, ShouldContinue etc. emerges from the following:

- Command-line options: -WhatIf, -Confirm, -ErrorAction, -Debug, -Verbose
- Preference variables: $WhatIfPreference, $ConfirmPreference, $ErrorActionPreference, $DebugPreference, $VerbosePreference, $WarningPreference, $ProgressPreference

The following are the algorithms for determining the effective setting. In priority order:

WhatIf (true/false)

-WhatIf (or –WhatIf:$false)
$WhatIfPreference
default: false


Confirm (ActionPreference)

-Confirm:$true => Inquire
-Debug –Confirm:$false => Continue
-Debug => Inquire
-Confirm:$false => SilentlyContinue
$ConfirmPreference
default: SilentlyContinue


ErrorAction (ActionPreference) (note that –ErrorAction is of type ActionPreference)

-ErrorAction <preferencesetting> => <preferencesetting>
-Debug => Inquire
$ErrorActionPreference
default: Continue


Debug (ActionPreference)

-Debug:$true => Inquire
-Debug:$false => SilentlyContinue
$DebugPreference
default: SilentlyContinue


Verbose (ActionPreference)

-Verbose:$true => Continue
-Verbose:$false => SilentlyContinue
-Debug => Inquire
$VerbosePreference
default: SilentlyContinue


Warning (ActionPreference) (note that there is no –Warning flag)

-Debug => Inquire
-Verbose => Continue
$WarningPreference
default: Continue


Progress (ActionPreference) (note that there is no –Progress flag)

$ProgressPreference
default: Continue

Monad refactoring work:

In this release, the Cmdlet base class has been factored into two separate classes. If your cmdlets do not require any of the Monad engine core services (access to session state or providers) or use any of the engine intrinsic APIs, then you should continue to derive from Cmdlet. If you require any of these services, then you should change your code to derive from MshCmdlet. In migrating to this new release, the best approach is to compile any existing cmdlets while still deriving from Cmdlet and only change the derivation for those cmdlets that have errors.

This change was made to reduce unnecessary dependencies on Monad core data structures for cmdlets that do not require those services. A positive consequence of this change is that if your cmdlets which derive only from Cmdlet can be directly invoked as standalone objects. For example, the get-process cmdlet only derives from Cmdlet and can therefore be used directly as shown in the following code:

using System;
using System.Collections;
using System.Diagnostics;
using System.Management.Automation;
using System.Management.Automation.Commands;

public class process

{
    public static void Main()
    {
        GetProcessCommand g = new GetProcessCommand();
        g.ProcessName = new string[] {"[a-t]*"};
        foreach (Process p in g.Invoke<Process>())
            {
                System.Console.WriteLine(p.ProcessName);
            }
    }
}



IMPORTANT NOTE: As always, our developer guidance is to develop your service as a proper API, then write cmdlets to surface that API to Monad. It is strongly recommended that little or no business logic be contained in the cmdlet code itself. Although this refactoring allows cmdlets to be used directly as an API, it should not be construed as a replacement for proper API design.

Miscellaneous bug fixes

- Match-string: match-string -list used to write the match object before closing the file which used to cause an exception. This issue is now fixed. The following example should now work as expected:

ls -rec -filter *.cs | match-string "cmdlet" | foreach { (cat $_) -replace "cmdlet","MshCmdlet" > $_ }

- Constants expressions after a variable were not being handled properly. The following example describes the new fixed behavior:

MSH:\> $a = "this is a test"
MSH:\> 80 - 8 - $a.length
    58

- Credential parameter of remove-item is now correctly passed to the provider.

- write-progress now uses "ooo.." instead of "%%%"

Changes from Windows PowerShell Beta 2 (for .NET Framework 2.0 Beta 2)

MSH execution policy changes

Monad's ExecutionPolicy is now configured to "Restricted" by default. This is a new value for ExecutionPolicy. In the Restricted mode, scripts (.msh files) cannot be run and .mshxml files (types.mshxml and *.format.mshxml files) can only be run if they are signed by a trusted publisher (.mshxml files are treated the same as they are by the "AllSigned" policy). For msh.exe, this value is controlled via the registry setting "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSH\1\ShellIds\Microsoft.Management.Automation.msh\ExecutionPolicy". The earlier Beta 2 release defaulted to an ExecutionPolicy of "RemoteSigned".

For other shells,  the ExecutionPolicy is controlled via the registry setting "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSH\1\ShellIds\<YourShellId>\ExecutionPolicy" where "<YourShellId>" can be obtained from the $shellid variable inside the shell.

When Monad first starts up, it may ask a question "Do you want to run software from this untrusted publisher?" for the file "types.mshxml", published by Microsoft. You can choose to not load the file, but the file (and the *.format.mshxml files, which Monad will also prompt for if you do not select [A] for "Always run" for types.mshxml), controls the display and formatting of Monad and the experience in Monad will be degraded if it is not loaded. To avoid this prompt in the future, either select [A] for "Always run", or change the ExecutionPolicy from "Restricted" to "RemoteSigned".

The error text for certain execution errors references the "about_signing" help file. Simply type get-help about-siging to learn more about the new changes in Monad's ExecutionPolicy.

If you see an error at startup "The file "C:\Documents and Settings\All users\Documents\msh\profile.msh cannot be loaded. The execution of scripts is disabled on this machine" then either change the ExecutionPolicy from "Restricted" to "RemoteSigned", or sign the files using the set-authenticodesignature cmdlet (the error message is misleading; execution of .mshxml files is not entirely disabled when ExecutionPolicy is "Restricted", but they must be signed by a trusted publisher). The "about_signing" help file has more details. You can also delete the file; in the initial configuration, the profile.msh file does not add any functionality to Monad.

Profile.msh possible errors:

If you load the profile.msh file, and you have previously installed an earlier version of Monad, then on startup you may see a series of errors like:

set-alias : The AllScope option cannot be removed from the alias 'cat'.
At C:\Documents and Settings\All Users\Documents\msh\profile.msh:9 char:10
+ set-alias <<<< cat get-content

To fix this, either delete the file named ("C:\Documents and Settings\All Users\Documents\msh\profile.msh" in this example), or remove all the "set-alias" lines from it. Aliases defined in profile.msh in earlier versions of Monad are now defined internally by Monad before the profile is run; therefore, the definitions in profile.msh will generate an error attempting to redefine the alias.

Known Issues with Monad Beta 2

MSH crashes while get-content –wait is running on a file that is updated frequently.

UTF7 file encoding is not supported.

Set-item on an existing alias returns an error instead of writing a new value if –option ReadOnly is specified. Set-alias should be used instead.

Regardless of the file extension, the following reserved device names should not be used as the name of a file. If used, unpredictable behavior and data loss may occur.

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9

Help content for write-warning and script-signing are missing.

Help content for new-object is incorrect.

Important Changes in Monad Beta 2

  • add-mshsnapin [-Name] String[] [-PassThru]
  • get-mshsnapin [[-Name] String[]] [-Registered]
  • remove-mshsnapin [-Name] String[] [-PassThru]
  • export-Console [[-Name] String] [-Force]

The COM interop feature has been added in this release. Documentation about how to use this feature is included in the "Getting Started Guide."

The concept of separate shells has been introduced in this version of MSH. If you are developing Cmdlets, review the information about Shells in the "Getting Started Guide."

When you run setup, it will automatically register an MSHSIP.dll to support script signing. To learn how to sign a script type:

MSH> Set-AuthenticodeSignature -?

and follow the instructions.

The following cmdlets have been added:

compare-object, convert-HTML, export-clixml, import-clixml, start-transcript, stop-transcript, update-FormatData, update-typeData, write-warning

The script block delegates feature is enabled in this release. However, the feature only works when the delegates are called on the same thread.

Changes from the Beta 1 release

A system-wide profile is installed at "All Users\Documents\MSH\profile.msh". User specific profiles should go in at "users\My Document\MSH\profile.msh"

The registry entry for Monad now has shellId - HKLM:\SOFTWARE\Microsoft\msh\1\ShellIds

The format.mshxml file allows the user to define what properties will be displayed and in what format for any type. Setup will install a read only format.mshxml file. You can add additional format data in a separate file with a .mshxml extension for your formatting requirements. Documentation about how to use this file is included in the "Getting Started Guide."

The types.mshxml file allows the static extension of types with added properties (which can be used by format.mshxml). Setup will install a read only types.mshxml file. You can add additional types data in a separate file with a .mshxml extension for your formatting requirements. Documentation about how to use this file is included in the "Getting Started Guide."

There are three execution policies - AllSigned, RemoteSigned, Unrestricted. The default execution policy is RemoteSigned. For more information about the execution policy, see "Getting Started Guide."