Exchange Server 2010 : Using the Exchange Management Shell - Using Windows PowerShell

Not unlike the less sophisticated Windows command prompt, the UNIX command shells operate by executing built-in commands, external commands, and command-line utilities and then returning the results in an output stream as text. The output stream can be manipulated in various ways, including redirecting the output stream so that it can be used as input for another command. This process of redirecting one command's output to another command's input is called piping, and it is a widely used shell-scripting technique.

C Shell is one of the more sophisticated UNIX shells. In many respects, C Shell is a marriage of some of the best features of the C programming language and a full-featured UNIX shell environment. The Windows PowerShell takes the idea of a full-featured command shell built on a programming language a step further. It does this by implementing a scripting language based on C# and an object model based on the Microsoft .NET Framework.

Basing the scripting language for Windows PowerShell on C# ensures that the scripting language can be easily understood by current C# developers and also allows new developers who work with PowerShell to advance to C#. Using an object model based on the .NET Framework allows the Windows PowerShell to pass complete objects and all their properties as output from one command to another. The ability to redirect objects is extremely powerful and allows for a much more dynamic manipulation of a result set. For example, not only can you get the name of a particular user, but you can also get the entire related user object. You can then manipulate the properties of this user object as necessary by referring to the properties you want to work with by name.

Windows PowerShell Version 2.0 (PowerShell V2) is built into Windows 7, Windows Server 2008 Release 2, and later releases of the Windows operating system. Windows PowerShell V2 has both a command-line environment and a graphical environment for running commands and scripts. The PowerShell console (powershell.exe) is a 32-bit or 64-bit environment for working with PowerShell at the command line. On 32-bit versions of Windows, you'll find the 32-bit executable in the %SystemRoot%\System32\WindowsPowerShell\v1.0 directory. On 64-bit versions of Windows, you'll find the 32-bit executable in the %SystemRoot%\SysWow64\WindowsPowerShell\v1.0 directory and the 64-bit executable in the %SystemRoot%\System32\WindowsPowerShell\v1.0 directory.

You can start the PowerShell console by using the Search box on the Start menu. Click Start, type powershell in the Search box, and then press Enter. Or you can click Start; point to All Programs; point to Accessories, Windows PowerShell; and then choose Windows PowerShell V2. On 64-bit systems, the 64-bit version of PowerShell is started by default. If you want to use the 32-bit PowerShell console on a 64-bit system, you must select the Windows PowerShell V2 (x86) option.

You can start Windows PowerShell from a Windows command shell (cmd.exe) by typing powershell. To exit Windows PowerShell and return to the command prompt, type exit.

Usually, when the shell starts, you will see a message similar to the following:

Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

You can disable this message by starting the shell with the –Nologo parameter, such as:

powershell -nologo

Figure 1 shows a PowerShell window. Typically, the window is 120 characters wide and displays 50 lines of text by default. When additional text is to be displayed in the window or you enter commands and the PowerShell console's window is full, the current text is displayed in the window and prior text is scrolled up. If you want to pause the display temporarily when a command is writing output, press Ctrl+S. Afterward, press Ctrl+S to resume or Ctrl+C to terminate execution.

Figure 1. Working with Windows PowerShell.

When you start Windows PowerShell, the working environment is loaded automatically. Many features of the working environment come from profiles, which are a type of script that run when you start PowerShell. However, the working environment is also determined by imported modules, snap-ins, providers, command paths, file extensions, and file associations.

You can start Windows PowerShell without loading profiles using the –Noprofile parameter, such as:

powershell -noprofile

Whenever you work with scripts, you need to keep in mind the current execution policy and whether signed scripts are required. Execution policy controls whether and how you can run configuration files and scripts. Execution policy is a built-in security feature of Windows PowerShell that is set on a per-user basis in the Windows registry. Although the default configuration depends on which operating system and edition are installed, you can quickly determine the execution policy by typing get-executionpolicy at the PowerShell prompt.

The available execution policies, from least secure to most secure, are:

You can use the Set-ExecutionPolicy cmdlet to change the preference for the execution policy. Changes to the policy are written to the registry. However, if the Turn On Script Execution setting in Group Policy is enabled for the computer or user, the user preference is written to the registry, but it is not effective, and Windows PowerShell displays a message explaining the conflict. You cannot use Set-ExecutionPolicy to override a group policy, even if the user preference is more restrictive than the policy setting.

To set the execution policy to require that all scripts have a trusted signature to execute, type the following command:

set-executionpolicy allsigned

To set the execution policy so that scripts downloaded from the Web execute only if they are signed by a trusted source, type:

set-executionpolicy remotesigned

To set the execution policy to run scripts regardless of whether they have a digital signature and work in an unrestricted environment, you can type the following command:

set-executionpolicy unrestricted

The change occurs immediately and is applied to the local console or application session. Because the change is written to the registry, the new execution policy will be used whenever you work with PowerShell.

Windows PowerShell introduces the concept of a cmdlet (pronounced commandlet). A cmdlet is the smallest unit of functionality in Windows PowerShell. You can think of a cmdlet as a built-in command. Rather than being highly complex, most cmdlets are quite simple and have a small set of associated properties.

You use cmdlets the same way you use any other commands and utilities. Cmdlet names are not case sensitive. This means you can use a combination of both uppercase and lowercase characters. After starting Windows PowerShell, you can type the name of the cmdlet at the prompt and it will run in much the same way as a command-line command.

For ease of reference, cmdlets are named using verb-noun pairs. As Table 1 shows, the verb tells you what the cmdlet does in general. The noun tells you what specifically the cmdlet works with. For example, the Get-Variable cmdlet gets a named Windows PowerShell environment variable and returns its value. If you don't specify which variable to get as a parameter, Get-Variable returns a list of all Windows PowerShell environment variables and their values.

You can work with cmdlets in several ways:

You can enter any command or cmdlet you can run at the Windows PowerShell command prompt into a script by copying the related command text to a file and saving the file with the .ps1 extension. You can then run the script in the same way you would any other command or cmdlet.

From the Windows command-line environment or a batch script, you can execute Windows PowerShell cmdlets with the –Command parameter. Typically, when you do this, you also want to suppress the Windows PowerShell logo and stop execution of profiles. After doing this, you can type the following command at a command prompt or insert it into a .BAT script:

powershell -nologo -noprofile -command get-service

Finally, when you are working with Windows PowerShell, the current directory is not part of the environment path in most instances. Because of this, you typically need to use "./" when you run a script in the current directory, such as:

./runtasks

Because Windows PowerShell runs within the context of the Windows command prompt, you can run all Windows command-line commands, utilities, and graphical applications from within Windows PowerShell. However, remember that the Windows PowerShell interpreter parses all commands before passing off the command to the command prompt environment. If Windows PowerShell has a like-named command or a like-named alias for a command, this command, and not the expected Windows command, is executed.

Non–Windows PowerShell commands and programs must reside in a directory that is part of the PATH environment variable. If the item is found in the path, it is run. The PATH variable also controls where the Windows PowerShell looks for applications, utilities, and scripts. In Windows PowerShell, you can work with Windows environment variables using $env. If you want to view the current settings for the PATH environment variable, you type $env:path. If you want to add a directory to this variable, you can use the following syntax:

$env:path += ";DirectoryPathToAdd"

where DirectoryPathToAdd is the directory path you want to add to the path, such as

$env:path += ";C:\Scripts"

To have this directory added to the path every time you start Windows PowerShell, you can add the command line as an entry in your profile. Keep in mind that cmdlets are like built-in commands rather than standalone executables. Because of this, they are not affected by the PATH environment variable.