Microsoft Exchange Server 2007 Administrators Pocket Consultant Second Edition

Microsoft Exchange Server 2007 introduces Exchange Management Shell to compliment the expanding role of Exchange Server administrators and developers. Exchange Management Shell is an extensible command-line environment for Exchange Server 2007 that builds on the existing framework provided by Windows PowerShell. When you install Exchange Server 2007 on a server or the Exchange Server management tools on a workstation, you install Windows PowerShell and Exchange Management Shell as part of the process. This chapter introduces Windows PowerShell and its features and then details the available commands and options of the Exchange Management Shell.

Using the Windows PowerShell

Anyone with a UNIX background is probably familiar with the concept of a command shell. Most UNIX-based operating systems have several full-featured command shells available, including Korn Shell (KSH), C Shell (CSH), and Bourne Shell (SH). Although Microsoft Windows operating systems have always had a command-line environment, they've lacked a full-featured command shell, and this is where Windows PowerShell comes into the picture.

Introducing the 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.

The 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 .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 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.

Running and Using Windows PowerShell

To invoke the Windows PowerShell, you must first open a command prompt window and then start the Windows PowerShell by typing msh at the command line. To exit the Windows PowerShell and return to the command prompt, type exit.

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

Microsoft Command Shell Copyright (C) 2005 Microsoft Corporation. All rights reserved.

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

msh -nologo

Regardless of how you start the shell, you know you are using the Windows PowerShell because the command prompt title bar changes to Command Prompt – msh and the current path is preceded by MSH, as shown in Figure 6-1.

Figure 6-1: Start the Windows PowerShell.

When the shell starts, user and system profiles are run to set up the environment. The following is a listing and description of the profile files run, in the order of their execution:

1. %AllUsersProfile%∖Documents∖PSConfiguration∖profile.ps1

   A system-wide profile executed for all users. This profile is used by the system administrator to configure common settings for the Windows PowerShell.

2. %AllUsersProfile%∖Documents∖PSH∖Microsoft.PowerShell_profile.ps1

   A system-wide profile executed for all users. This profile is used by the system administrator to configure common settings for the Windows PowerShell.

3. %UserProfile%∖My Documents∖PSConfiguration∖profile.ps1

   A user-specific profile executed only for the current user. This profile is used by individual users to configure common settings for the Windows PowerShell.

4. %UserProfile%∖My Documents∖PSH∖Microsoft.PowerShell_profile.ps1

   A user-specific profile executed only for the current user. This profile is used by individual users to configure common settings for the Windows PowerShell.

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

msh-noprofile

The first time you start Windows PowerShell, you typically will see a message indicating that scripts are disabled and that none of the listed profiles are executed. This is the default secure configuration for the Windows PowerShell. To enable scripts for execution, enter the following command at the shell prompt:

set-executionpolicy allsigned

This command sets the execution policy to require that all scripts have a trusted signature to execute. For a less restrictive environment, you can enter the following command:

set-executionpolicy remotesigned

This command sets the execution policy so that scripts downloaded from the Web execute only if they are signed by a trusted source. To work in an unrestricted environment, you can enter the following command:

set-executionpolicy unrestricted

This command sets the execution policy to run scripts regardless of whether they have a digital signature.

Running and Using Cmdlets

Windows PowerShell introduces the concept of a cmdlet (pronounced "command-let"). A cmdlet is the smallest unit of functionality in the 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 the Windows PowerShell, you can enter 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 6-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 two ways:

• Executing commands directly at the shell prompt

• Running commands from within scripts

You can enter any command or cmdlet that 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 will 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:

msh -nologo -noprofile -command get-service

Finally, when you are working with Windows PowerShell, it is important to remember that the current directory may not be part of the environment path. Because of this, you may need to use "./" when you run a script in the current directory, such as:

./runtasks

Running and Using Other Commands and Utilities

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 the Windows PowerShell. However, it is important to remember that the Windows PowerShell interpreter parses all commands before passing off the command to the command prompt environment. If the 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. (See the "Using Cmdlet Aliases" section later in this chapter for more information on aliases.)

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 the 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 stand-alone executables. Because of this, they are not affected by the PATH environment variable.