Using Windows PowerShell in an Exchange Server 2010 Environment : What Is Windows PowerShell?

Windows PowerShell is easy to learn and use because it works in your existing IT environment, and you can leverage your existing scripting investments. It is as powerful (or more powerful) than some programming languages. It plugs into the .NET runtime, also called the common language runtime. An administrator can sit at a PowerShell prompt and access, control, and automate almost everything in Windows.

Windows PowerShell is extremely powerful, in which virtually anything can be written and scripted from the shell. PowerShell is a fully featured command-line shell, similar to a Bash prompt. It is also an extremely powerful administrative scripting tool—think Perl or Ruby with AWK, SED, and Grep thrown in. And all this is based on .NET—so administrators have direct access to the entire .NET common language runtime, plus the ability to script existing COM (ActiveX) and Windows Management Instrumentation (WMI) objects, similar to what can be done with VBScript but with much more power and ease.

Windows PowerShell includes many system administration utilities, a consistent syntax and naming convention, and improved navigation of common management data such as the Windows Registry, certificate stores, or Windows Management Instrumentation (WMI) repositories. The PowerShell command-line interface uses a common verb-noun structure that makes it easy to read, as well as write.

Versions 1.0 and 2.0 of Windows PowerShell are available for free download from the Microsoft Download Center (www.microsoft.com/downloads/en/results.aspx?pocId=&freetext=powershell). The differences between these versions will be discussed in the next section. PowerShell runs on Windows XP, Windows Vista, and Windows Server 2003. Windows PowerShell is included as part of Windows Server 2008 as an optional feature that can be added to the operating system. It is installed by default in Windows 7 and Windows Server 2008 R2.

Understanding the Evolution of PowerShell

This section provides a brief history of Windows PowerShell, so you have an understanding of how and why it was developed. We discuss how Windows PowerShell relates to Exchange Server 2010 and why it is so important for you to master this important and powerful technology.

Monad

The first version of Windows PowerShell was called Monad (also known as Microsoft Shell or MSH). A team at Microsoft, led by the brilliant architect of PowerShell, Jeffrey Snover, realized that Windows needed a new command-line interface that would allow administrators to do everything from the command line. GUIs can do only as much as they are written to do. Changes are sometimes made in the Registry, some in Active Directory (AD) through Active Directory Services Interface (ADSI), and others in less often used or difficult to manage components such as the Exchange Server metabase or Internet Information Services (IIS).

The team developed a fresh, new shell whereby everything in the Windows environment is accessed as an object, and a common set of verbs are used to act upon these objects. These verb-object commands are sometimes combined into useful combinations call cmdlets (pronounced “commandlets”) that are specialized .NET classes designed expressly to expose a functionality via PowerShell. The Monad team compiled some of these cmdlets into PowerShell, making them native commands available to all end users.

Various betas of Monad were made available on Microsoft’s Download Center between June 2005 and April 2006 when Monad was renamed to Windows PowerShell.

Windows PowerShell v.1.0

The idea that was Monad started to become a full-fledged command-line shell in Windows PowerShell 1.0. Because it is based on .NET classes, PowerShell requires the .NET Framework version 2.0. It is available on both the Microsoft Download Center as a redistributable package and through the Windows Update and Microsoft Update services. The final Release to Web (RTW) version of PowerShell 1.0 was released in November 2006.

The user interface offers tab-completion, in which PowerShell commands and parameters can be viewed or completed by entering the beginning portion of a command and pressing the Tab key. For example, entering “get-” and pressing tab repeatedly steps though all the objects that PowerShell can act upon.

PowerShell also introduced the concept of a pipeline to the shell. PowerShell pipelines are used to compose or combine complex commands, enabling the output of one command to be passed as input to another. A pipeline is created by piping the output of one command to another command, using the | operator. You can even pipeline the output of one pipeline into another.

Scripts written using PowerShell can be saved in a .ps1 file. However, as a security precaution, script execution is disabled by default and must be enabled explicitly within PowerShell. PowerShell scripts can be signed to verify their integrity and use .NET Code Access Security.

Windows PowerShell 1.0 is the underlying platform used by Microsoft Exchange Server 2007. The Exchange Server team built upon that platform to develop and operate Exchange Server 2007, and they developed the Exchange Management Shell (EMS) for administration. EMS is an extension of PowerShell 1.0 with custom cmdlets that were written specifically for Exchange Server administration. When the administrator launches the Exchange Management Shell, PowerShell 1.0 is invoked and special Exchange Server 2007–only cmdlets are loaded, such as the move-mailbox cmdlet. There are 402 cmdlets unique to Exchange Server 2007, and each cmdlet has its own set of help.

One major missing feature in PowerShell 1.0 is the lack of remoting, or the ability to run a PowerShell command on a remote computer. This shortcoming hampered PowerShell 1.0 from being adopted and utilized in large enterprise-class IT centers with thousands of computers. It also prevents administrators from loading the Exchange Management Console or Exchange Management Shell on a workstation for remote administration of Exchange 2007 servers. Plans began for a remotable version of PowerShell.

Windows PowerShell v.2.0

PowerShell V2 includes changes to the scripting language and hosting API, and includes more than 240 new cmdlets.

Major changes in PowerShell V2 include the following:

• Background Jobs enables a command sequence, script, or pipeline to be invoked asynchronously.

• Transactions enable cmdlets to perform transacted operations. PowerShell V2 includes transaction cmdlets for starting, committing, and rolling back a transaction.

• Modules enable script developers and administrators to organize and partition PowerShell scripts in self-contained, reusable units.

• Script Debugging enables breakpoints to be set in a PowerShell script or function.

• Windows PowerShell Integrated Scripting Environment. PowerShell V2 includes a new GUI-based PowerShell environment that provides an integrated debugger, syntax highlighting, tab completion, and up to eight tabbed PowerShell runspaces.

Most important of the changes in PowerShell V2 is the ability to perform remoting using Windows Remote Management (WinRM) 2.0. This enables administrators to invoke scripts on a remote machine or a large collection of remote machines. It is this capability that lends itself to Exchange Server 2010 and remote management using the Exchange Management Shell (EMS).

Now with Exchange Server 2010, administrators can invoke EMS commands from a remote server or workstation. Because EMS uses WinRM for remote connectivity, it lends itself very well to firewall and cross-forest scenarios. WinRM uses the standard ports 80 and 443 for all communications to and from the target computer, making it easier than ever to perform remote management, even in complex environments.