Chapter 1: Getting Started

In this chapter, we will take a brief tour of PowerShell and introduce you to some of its most important concepts. Many of these concepts will be covered in more detail in later chapters. For now, we want to help you become oriented with this new environment.

What is PowerShell, and Why Should I Care?

Administrators of UNIX and Linux systems (collectively referred to as "*nix" throughout this book) have always had the luxury of administrative scripting. In fact, most *nix operating systems are built on a command-line interface (CLI). While most *nix systems also feature a graphical user interface (GUI), the real work is done from the CLI. Every variant of *nix supports some sort of shell scripting language such as Bash that enables CLI commands to be strung together to automate administrative tasks.

Microsoft Windows has traditionally been built on a GUI rather than on a CLI, which is the exact opposite of a typical *nix system. Automating tasks performed in a GUI is significantly more difficult than automating tasks performed in a CLI. For example, you must address the question of how to write a script that tells a computer to check a certain checkbox if the contents of a text box are such-and-such? The answer is that you really can't. To help administrators automate various tasks, Microsoft has traditionally included a variety of CLI tools - command-line executables. These tools provide a CLI-based way of performing tasks by stringing these commands together in batch files that are also called scripts. Administrators could automate these tasks. However, the CLI tools typically only exposed a portion of Windows' functionality, which meant you could only automate the things for which Microsoft provided CLI tools.

In the late nineties Microsoft introduced Visual Basic Scripting Edition, which was commonly referred to as VBScript. This scripting language was compatible with Microsoft's Component Object Model (COM) that forms the building blocks of Windows itself. Because most GUI administrative tools were built on and utilized COM, it was felt that VBScript would provide a better automation environment. Unfortunately, VBScript still only automated a fraction of Windows' capabilities. However, it can do far more than the simple CLI batch language that evolved from Microsoft's earliest MS-DOS operating system.

Both CLI tools and VBScript have other problems, the primary problem being consistency. Because both evolved over time, and were created by various groups within Microsoft who had no shared standards to work from, each CLI tool and COM interface (as used by VBScript) works a bit differently. This means every new tool or COM interface you use presents a new learning curve, which takes additional time that you may not have. All of this stems from the fact that Microsoft was never really committed to scripting and automation for Windows. In fact, the feeling was that it was Windows, which meant you primarily used the GUI to run it. However, as Windows' penetration into large companies and enterprises increased, managers and administrators accustomed to *nix began to demand the same scripting and automation capabilities from Windows.

This brings us to PowerShell, which is Microsoft's first comprehensive, from-scratch effort to create a scriptable automation shell for Windows. PowerShell is built on the Microsoft .NET Framework, which has deep ties into almost every aspect of the operating system. Because Microsoft has made a strategic commitment to .NET, PowerShell's future is fairly secure since it will be built on the same platform on which most of Microsoft's other products will be built. In addition, above all else, PowerShell is consistent: There are clear guidelines for how PowerShell is to be built and extended, which means you won't have to learn an entirely new way of doing things every time you start a new script.

It's critical to recognize that PowerShell isn't a new scripting language a la VBScript. While PowerShell has a scripting language, it's actually an entirely new administrative interface. You can use it interactively without scripting, to issue commands to Windows and other Microsoft server products. You can also script it to automate more complex tasks. PowerShell is designed to be the place where an experienced administrator spends most of his or her time, replacing the GUI interfaces you've primarily used in the past in favor of a more productive, CLI-based administrative experience.

Exchange Server 2007 is perhaps the best example of how PowerShell can be leveraged. PowerShell was built into this version of Exchange from the outset. In fact, all of the product's administrative functionality was built in .NET and exposed through PowerShell, with the administrative GUI, or console, simply utilizing that underlying functionality. This means any Exchange administrative task can be performed in PowerShell, which, in turn, means any task can be scripted and automated in a consistent fashion. Whether or not the future use of PowerShell is equally comprehensive is up to the individual product groups within Microsoft. However, with Microsoft's strategic commitment both to .NET and administrative automation, it's probably a safe bet that PowerShell will finally offer a clear, consistent, and comprehensive tool for Windows administrative scripting.