Understanding Important Windows PowerShell Concepts

The Windows PowerShell design integrates concepts from many different environments. Several of them are familiar to people with experience in specific shells or programming environments, but very few people will know about all of them. Looking at some of these concepts provides a useful overview of the shell.

Commands are not Text-based

Unlike traditional command-line interface commands, Windows PowerShell cmdlets are designed to deal with objects - structured information that is more than just a string of characters appearing on the screen. Command output always carries along extra information that you can use if you need it. We will discuss this topic in depth in this document.

If you have used text-processing tools to process command-line data in the past, you will find that they behave differently if you try to use them in Windows PowerShell. In most cases, you do not need text-processing tools to extract specific information. You can access portions of the data directly by using standard Windows PowerShell object manipulation commands.

The Command Family is Extensible

Interfaces such as Cmd.exe do not provide a way for you to directly extend the built-in command set. You can create external command-line tools that run in Cmd.exe, but these external tools do not have services, such as help integration, and Cmd.exe does not automatically know that they are valid commands.

The native binary commands in Windows PowerShell, known as cmdlets (pronounced command-lets), can be augmented by cmdlets that you create and that you add to Windows PowerShell by using snap-ins. Windows PowerShell snap-ins are compiled, just like binary tools in any other interface. You can use them to add Windows PowerShell providers to the shell, as well as new cmdlets.

Because of the special nature of the Windows PowerShell internal commands, we will refer to them as cmdlets.

Note:

Windows PowerShell can run commands other than cmdlets. We will not be discussing them in detail in the Windows PowerShell Primer, but they are useful to know about as categories of command types. Windows PowerShell supports scripts that are analogous to UNIX shell scripts and Cmd.exe batch files, but have a .ps1 file name extension. Windows PowerShell also allows you to create internal functions that can be used directly in the interface or in scripts.

Windows PowerShell Handles Console Input and Display

When you type a command, Windows PowerShell always processes the command-line input directly. Windows PowerShell also formats the output that you see on the screen. This is significant because it reduces the work required of each cmdlet and ensures that you can always do things the same way regardless of which cmdlet you are using. One example of how this simplifies life for both tool developers and users is command-line help.

Traditional command-line tools have their own schemes for requesting and displaying help. Some command-line tools use /? to trigger the help display; others use -?, /H, or even //. Some will display help in a GUI window, rather than in the console display. Some complex tools, such as application updaters, unpack internal files before displaying their help. If you use the wrong parameter, the tool might ignore what you typed and begin performing a task automatically.

When you enter a command in Windows PowerShell, everything you enter is automatically parsed and pre-processed by Windows PowerShell. If you use the -? parameter with a Windows PowerShell cmdlet, it always means "show me help for this command". Cmdlet developers do not have to parse the command; they only need to provide the help text.

It is important to understand that the help features of Windows PowerShell are available even when you run traditional command-line tools in Windows PowerShell. Windows PowerShell processes the parameters and passes the results to the external tools.

Note:

If you run an graphic application in Windows PowerShell, the window for the application opens. Windows PowerShell intervenes only when processing the command-line input you supply or the application output returned to the console window; it does not affect how the application works internally.

Windows PowerShell Uses Some C# Syntax

Windows PowerShell has syntax features and keywords that are very similar to those used in the C# programming language, because Windows PowerShell is based on the .NET framework. Learning Windows PowerShell will make it much easier to learn C#, if you are interested in the language.

If you are not a C# programmer, this similarity is not important. However, if you are already familiar with C#, the similarities can make learning Windows PowerShell much easier.

Posted in: Windows| Tags: Windows PowerShell PowerShell Windows Command Family binary commands internal commands cmdlets Text-based C# programmer C# .NET framework command-line

---

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"

Posted in: Windows| Tags: Windows PowerShell PowerShell Windows Windows PowerShell RC2 ADSI LDAP PID Microsoft.PowerShell_profile WindowsPowerShell readability host.privatedata ConsoleColorProxy get-member

---

Several improvements to Get-WMIObject cmdlet in Windows PowerShell

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.

Posted in: Windows| Tags: Windows PowerShell PowerShell Windows processstartup CIMDATETIMES ConvertToDateTime Win32_Process.Handle Get-WMIObject Miscellaneous

---

Windows PowerShell setup changes

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'

Posted in: Windows| Tags: Windows PowerShell PowerShell Windows Setup Access Directory Special Character

---