Tag: PowerShell

Windows PowerShell is an extensible automation engine from Microsoft, consisting of a command-line shell and associated scripting language. Windows PowerShell is built on top of, and is integrated with, the Microsoft .NET Framework.

Additionally PowerShell enabled easy access to COM and WMI to provide an environment in which administrators perform administrative tasks on both local and remote Windows systems.

Windows PowerShell 2.0 installs under the System32/WindowsPowerShell/V1.0 folder. PowerShell 2.0 is backward-compatible with PowerShell 1.0. However, the following points should be noted: 

Breaking changes from PowerShell 1.0

• The value of the PowerShellVersion registry entry in HKLM\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine is changed to 2.0.
• New cmdlets and variables have been added. These additions might conflict with variables and functions in profiles and scripts.
• The -IEQ operator performs a case-insensitive comparison on characters.
• The Get-Command cmdlet gets functions by default, in addition to getting cmdlets.
•  Native commands that generate a user interface cannot be piped to the Out-Host cmdlet.
• The new Begin, Process, End, and Dynamic Param language keywords might conflict with similar words used in scripts and functions. Interpreting these words as language keywords might result in parsing errors.
• Cmdlet name resolution has changed. In Windows PowerShell 1.0, a runtime error was generated when two Windows PowerShell snap-ins exported cmdlets with the same name. In Windows PowerShell 2.0, the last cmdlet that is added to the session runs when you type the command name. To run a command that does not run by default, qualify the cmdlet name with the name of the snap-in or module in which it originated.
• A function name followed by ‘-?’ gets the help topic for the function, if one is included in the function.
• Parameter resolution for Microsoft .NET Framework methods have changed. In Windows PowerShell 1.0, if you called an overloaded .NET method that has more than one best-fit syntax, no error was reported. In Windows PowerShell 2.0, an ambiguity error is reported. In addition, in Windows PowerShell 2.0, the algorithm for choosing the best-fit method has been revised significantly to minimize the number of ambiguities.
• If you are enumerating a collection in the pipeline and you try to modify the collection in the pipeline, Windows PowerShell throws an exception.

For example, the following commands would work in Windows PowerShell 1.0 but would fail after first pipeline iteration in Windows PowerShell 2.0:
$h = @{Name=”Hello”; Value=”Test”}
$h.keys | foreach-object {$h.remove($_)}

To avoid this error, create a sub-expression for the enumerator by using the $() characters. For example:
$($h.keys) | foreach-object {$h.remove($_)}

Restricted verbs and characters:

If you use the Import-Module  cmdlet to load commands that use unapproved verbs or restricted characters in the command name, you will receive a warning. Use the Get-Verb command to see a list of the approved verbs. Do not use any of the following characters in command names: [ # , ( ) { } [ ] & – / \ $ ^ ; : ” ‘ < > | ? @ ` * ~ % + =

Reserved keywords and parameter names:

Windows PowerShell 2.0 has reserved certain keywords as part of language syntax and some names that can be used as parameters to commands, as follows: 

• Reserved language keywords: USING, CLASS, DEFINE, and VAR
• Reserved parameter names: –SelectProperty and –SelectObject

Windows Presentation Foundation (WPF) hardware acceleration:

The graphical elements of Windows PowerShell Integrated Scripting Environment (ISE) might not render correctly if you are using Windows Presentation Foundation (WPF) hardware acceleration. If the graphical elements do not render correctly, disable the WPF hardware acceleration, especially if you are using older video drivers or virtualization software. For more information, see http://go.microsoft.com/fwlink/?LinkId=144711.

Help over remoting might not work:

If a user is calling the get-help Windows PowerShell command over Windows PowerShell remoting from a highly/partially (not fully) localized operating system, the help content will not be displayed. Users will see only the command syntax, but no help content for the command and its parameter. To work around this issue, users should copy a localized help file (whichever one they want to make the default) from the localized folder under c:\windows\system32\WindowsPowerShell\v1.0\<locale> to the application/module base folder. (The default path for Windows PowerShell commands is c:\windows\system32\WindowsPowerShell\v1.0.)

Courtesy: Windows Management Framework Relese Notes – Here