Part I PowerShell for Fundamentals COPYRIGHTED MATERIAL Exchange

Download Part I PowerShell for Fundamentals COPYRIGHTED MATERIAL Exchange

Preview text


Part I
PowerShell for Exchange
Chapter 1: Getting Started with Windows PowerShell Chapter 2: Using Exchange Management Shell Chapter 3: Using PowerShell to Deploy Exchange Server 2007 Chapter 4: Working with User and Group Objects Chapter 5: Public Folders

Getting Started with Windows PowerShell
Windows PowerShell is the next-generation command-line shell and scripting language for Windows. Exchange Server 2007 is the first Microsoft application to utilize Windows PowerShell for deployment and administration. This chapter introduces Windows PowerShell and explains the basic concepts you’ll need to know to use Windows PowerShell effectively.
The first section, “What Is Windows PowerShell?” includes command shell history and describes the features that make Windows PowerShell the ideal management platform for Exchange Server 2007.
The section that follows, “Windows PowerShell Basics,” covers the fundamentals of Windows PowerShell. This section describes the components of Windows PowerShell and how to find commands and then learn how to use them.
To understand Windows PowerShell and its benefit to Exchange administrators, this chapter covers the following key areas:
❑ Command shells vs. Graphical User Interfaces ❑ Windows PowerShell components ❑ Windows PowerShell built-in help ❑ Composing commands using pipelines
What Is Windows PowerShell?
Windows PowerShell is a new command-line shell and scripting language for Windows. It was designed by Microsoft specifically to give administrators an extensible command shell for managing Windows environments with greater control and flexibility. This section includes a brief discussion of some traditional administrative interfaces to help you understand why there is a

Part I: PowerShell for Exchange Fundamentals
need for an advanced interface like Windows PowerShell. What follows is a discussion of the main features that set Windows PowerShell apart from other management interfaces and make it the most powerful administrative interface that Microsoft has ever produced.
Shell History
Before there was the Graphical User Interface (GUI), there was the Command Line Interface (CLI). The CLI was born of a need to quickly interact with the operating system at a time when computers were mostly controlled using punch card or paper tape input. The first CLIs used teletype machines to enter commands directly into the computer for execution, with the results returned to the operator as printed output. Teletypes were later replaced with dedicated text-based CRT terminals that offered an even greater advantage in speed and the amount of information available to the operator.
All CLIs rely on a program that interprets textual commands entered on the command line and turns them into machine instructions. This program is known as a command-line interpreter or shell. Every major operating system includes some sort of shell interface. UNIX administrators may be familiar with several shells (SH, KSH, CSH, and BASH) as well as the text processing languages AWK and PERL. Windows users may also be familiar with cmd.exe, the Windows command-line interpreter and the Windows Script Host for running scripts.
All these shells make possible direct communication between the operating system and the user. They include built-in commands and provide an environment for running text-based applications and utilities.
When Shells Are Better than GUI Interfaces
GUI interfaces came later in computer development and opened the door to less-technically-advanced users looking for a more “comfortable” way to interact with the operating system. Although they provide a simple-to-use interface, GUI applications are prone to user error because their use requires direct interaction between the user and the interface through menus, controls, and fields. For each administrator in the organization to complete the same tasks as all other administrators, they must learn and then use the correct menu choices and controls in order to get consistent results.
GUI-based management programs also constrain administrators to predetermined properties and controls. They lack provisions for special or one-off tasks because they are designed and written with specific functionality that is appropriate for general purposes.
Shells offer a powerful solution for overcoming these GUI shortcomings by providing a method to gather commands into a batch file, also known as a script, and then run them as if they had been entered one at a time at the command line. Administrators create and run scripts to automate everyday tasks and resolve difficult issues GUI interfaces are not designed to handle. Scripts allow a reliable, sustainable method for administering an environment.
Once a script has been written and proven to work for its intended purpose, it can be distributed throughout an organization and used as needed by any administrator, with expected and consistent results. Examples of some common script solutions you might find in most organizations are used for unattended machine deployments, user account provisioning, and nightly database backups.

Chapter 1: Getting Started with Windows PowerShell
Common Shell Limitations
The traditional shells mentioned earlier offer an administrator greater control and flexibility for tackling everyday or even unusual management tasks, but they all suffer from significant drawbacks.
Command shells operate by executing built-in commands that run within the process of the shell, or by executing a command or application in a new process outside of the shell. Many applications lack command-line equivalents for controls found in their GUI management programs. And the number of built-in commands offered by most shells is usually small, requiring more applications and utilities to run outside the shell to accomplish critical tasks. Most organizations lack the resources to develop special applications and utilities on their own and may struggle to accomplish more complex tasks using available commands alone.
Another drawback shared by most shells is the way in which they handle information. The results of running a command or utility is returned as text to the command line. If you need to use this text as input for another command, which is common in scripting, it has to be parsed. Parsing is the process of evaluating text and extracting the meaningful values in a form that can then be properly interpreted by another command. Parsing is prone to error and can be time consuming because the format required for preparing the textual input can vary greatly between different commands, applications, and utilities.
One final limitation to consider is the lack of integration between a shell and the scripting languages you would use in that shell. For example, Windows Script Host provides a method for implementing a variety of scripting languages from the command line (via cmd.exe), but it is not integrated with cmd.exe and is thus not interactive. It also lacks readily accessible documentation from the command line as you would find in many other shells and scripting environments.
The Power Behind PowerShell
What sets Windows PowerShell apart from all other command shells is that it is built on top of .NET Framework version 2.0. Windows PowerShell exposes .NET classes as built-in commands. When these commands are executed they create a collection of one or more structured objects as output. Instead of text, all actions in Windows PowerShell are based on .NET objects.
Windows PowerShell objects have a specific type based on the class used to create them. They have properties (which are characteristics) and methods (which are actions you can take). Because objects have a defined structure, a collection of objects created by one command can be passed to another command as input without the need for parsing the data in-between.
Windows PowerShell includes a fully integrated and intuitive scripting language for managing .NET objects. The language is consistent with higher-level languages used in programming .NET. Those administrators familiar with the C# programming language will find many similarities in the grammar, syntax, and keywords used by the Windows PowerShell scripting language.
Windows PowerShell includes more than 130 built-in commands for performing the most common system administrative tasks. The commands are designed to be easy to understand and use because they share common naming and parameter conventions. Learning how to use one command makes it easy to understand how similar commands are also used.

Part I: PowerShell for Exchange Fundamentals
Because Windows PowerShell is fully extensible, software developers can create their own custom built-in commands to handle those administrative tasks not already addressed in the default built-in command set. Exchange Management Shell is an example of Windows PowerShell extended to include more than 500 built-in commands.
Windows PowerShell not only allows access to the local disk drives as a file system, but it also exposes the local Registry, certificate store, and system environment variables and allows you to navigate them using the same familiar methods you would use for navigating a file system. Windows PowerShell also provides additional data stores for variables, functions, and alias definitions used inside the shell.
GUI management applications can be built on top of Windows PowerShell. Software developers can ensure that all administrative functions found in a GUI management application built on Windows PowerShell have a corresponding scriptable equivalent in the Windows PowerShell CLI. Exchange Management Console is an example of a GUI management application built on top of Windows PowerShell.
PowerShell Basics
You may be asking yourself why a book about Exchange Management Shell is spending so much time in the beginning talking about Windows PowerShell. Because Exchange Management Shell is built on top of Windows PowerShell, you need to understand the basic concepts and components of Windows PowerShell first.
The Command-Line Interface
Windows PowerShell operates within a hosting application. The default application is powershell.exe, a console application that presents a command line to the user. To start PowerShell from the Start menu select All Programs Windows PowerShell 1.0 Windows PowerShell. This opens Windows PowerShell with the default console application as shown in Figure 1-1.
Many first-time users of Exchange Management Shell may be confused when after opening the default Windows PowerShell console application that they are unable to run any Exchange-specific commands. This is because Exchange Management Shell is an extension of Windows PowerShell. The default Windows PowerShell hosting application does not include any Exchange-specific commands. Windows PowerShell is extended by the use of a component called a snap-in. A snap-in provides a method for loading custom PowerShell commands and functionality contained in an application extension file.
To start Exchange Management Shell from the Start menu, select All Programs Exchange Server 2007 Exchange Management Shell. The target definition for this program shortcut contains the following
underlying command line:
C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell.exe -PSConsoleFile ”C:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -noexit -command “. ’C:\Program Files\Microsoft\Exchange Server\bin\Exchange.ps1’”

Chapter 1: Getting Started with Windows PowerShell
Figure 1-1 While invoking Windows PowerShell, this command specifies a console definition file identified by the PSConsoleFile parameter. The exshell.psc1 file contains a pointer to the Exchange Management Shell snap-in definition stored in the Registry at HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management .PowerShell.Admin. The ModuleName value stored in this location contains the path to the application extension file Microsoft.Exchange.PowerShell.Configuration.dll, located in the %ProgramFiles%\ Microsoft\Exchange Server\Bin directory. Windows PowerShell loads this .dll file to make the Exchange commands available. In addition to loading the snap-in for Exchange Management Shell, the underlying command also uses the command parameter to specify additional commands to run at startup, in this case the script file Exchange.ps1. This script file contains definitions for aliases, functions, and variables specific to

Part I: PowerShell for Exchange Fundamentals
Exchange management. It also defines the appearance of the command-line prompt and the initial welcome banner shown in Figure 1-2. As you can see, the appearance of the Exchange Management Shell is a bit different from the default Windows PowerShell console application, yet all the functionality of the core shell remains intact. Because Windows PowerShell is hosted in a console application, all the familiar properties and controls for a console application are available. Later in this section you learn how to set up your Exchange Management Shell for the best user experience when following the examples in this book.
Figure 1-2
The most basic component of Windows PowerShell is the built-in commands, called cmdlets (pronounced command-lets). Almost all the work done through Windows PowerShell is done through the use of cmdlets. Cmdlets are similar to built-in commands found in other shells; for example, the built-in command DIR found in cmd.exe. In Exchange Management Shell, cmdlets that perform a specific administrative function are often referred to as tasks. All cmdlets share the same basic structure. They have a name and take one or more parameters as input. Entering the name of a cmdlet, followed by any necessary parameter names and values, will result in the

Chapter 1: Getting Started with Windows PowerShell
execution of the cmdlet. For example, the cmdlet Get-ExchangeServer returns a list of all Exchange servers in the organization in a formatted list as shown in Figure 1-3.
Figure 1-3
Windows PowerShell commands are case-insensitive. The examples given in this section use the default form of capitalizing the first letter of each distinct word in the command elements. Only spelling and syntax count when entering Windows PowerShell commands.
Cmdlet Names: The Verb-Noun Pair
Cmdlet names always take the form of two or more words, separated by a dash or hyphen (-). The first word is known as the verb and refers to an action the cmdlet will take. The second word or group of words is known as the noun, and refers to the target of the verb. The verb and noun describe the action and the target of the action. Using this convention for naming cmdlets makes discovering and learning cmdlets more intuitive.
Cmdlet nouns may contain multiple words but have no spaces between them.
Common Verb Names
Microsoft has produced a list of common verb names recommended for use by software programmers developing Windows PowerShell cmdlets. This helps maintain a well-known list of verb names an administrator needs to know when learning about cmdlets. Here are some common verb names used in Exchange Management Shell cmdlets and what they do:
❑ Get: The Get verb retrieves information about the target of the cmdlet. In the previous example, Get-ExchangeServer, the cmdlet retrieved information about Exchange servers.
❑ Set: The Set verb sets a condition or makes a configuration change to the cmdlet target. ❑ New: The New verb creates a new instance of the cmdlet target. ❑ Remove: The Remove verb deletes the cmdlet target.

Part I: PowerShell for Exchange Fundamentals
The Get verb is the most common verb used in Exchange Management Shell cmdlets. It is also known as the default verb. When a cmdlet noun name is entered without a verb, Windows PowerShell assumes that the Get verb was implied and runs that cmdlet. In the preceding example, entering ExchangeServer instead of Get-ExchangeServer would yield the same results.
Noun Names
Nouns always represent the target of the cmdlet, in other words the thing on which the cmdlet will act. Noun names are usually straightforward and simply describe the target item. For example, consider the cmdlet Get-ClusteredMailboxServerStatus. From looking at this cmdlet’s name you should be able to figure out that its purpose is to retrieve the status of Clustered Mailbox Servers. When you apply this logic to other cmdlet names you quickly begin to understand how easy it can be to discover and learn cmdlets.
Another concept of noun names you should understand is that many cmdlet names share the same noun. For example, there are 10 different cmdlets that all affect mailbox items. Here are examples of just a few of these cmdlets:
❑ Get-Mailbox is used to retrieve information about one or more mailbox-enabled users. ❑ Set-Mailbox is used to change configuration settings for one or more mailbox-enabled users. ❑ New-Mailbox is used to create a new mailbox-enabled user. ❑ Move-Mailbox is used to move one or more mailboxes from one mailbox database to another.
As you can see, these examples all use a common noun name, yet each cmdlet yields very different results when it is coupled with a different verb name.
Parameter names are preceded by a dash or hyphen (-) and can be made up of a single word or multiple words with no spaces between them. Parameter names are typically followed by one or more values that are used either to provide input data for setting property values or to dictate the behavior of the cmdlet. Parameters that dictate behavior act as switches and typically do not require an input value.
Parameters have certain characteristics that determine how they are used. You can find out these characteristics via the built-in help information for each cmdlet that is readily available from the command line. Later this section covers how to get help and how to interpret that information to know how to use parameters effectively.
Parameter Input Values
Parameter input values are typically integer (numbers), string (words), or Boolean (true or false) data types. Other more specialized data types are also possible as defined by the class the cmdlet represents. For example, many cmdlets specific to Exchange Management Shell have data type input values specific to Exchange configuration components. The parameter data type is set when the cmdlet is defined. Windows PowerShell validates parameter input values as the cmdlet executes. If an invalid value is used or the format of the input data does not meet the cmdlet’s specification, the cmdlet fails to execute. For example, if a parameter takes as input an integer value, but a string value is entered instead, the cmdlet fails with an error that states the wrong data type was used.

Preparing to load PDF file. please wait...

0 of 0
Part I PowerShell for Fundamentals COPYRIGHTED MATERIAL Exchange