Introducing Windows PowerShell
Windows PowerShell is the evolution of the Windows command-line shell, which provides a scripting environment for MS-DOS and the Windows operating system. In MS-DOS and Windows 9X, the shell was command.com, and it was cmd.exe for Windows NT family of the operating system. In the UNIX world, there are different shells such as SH, KSH, CSH, and BASH.
Almost all of these shells provide an environment to execute a command or utility and present the output as text. These shells have some built-in commands such as dir in cmd.exe in Windows NT or later versions, but these built-in commands are limited; and hence, new utilities are written to fill the gap. Shells supported the use of a scripting language (batch files) to automate tasks. There were limitations when it came to creating complex scripts and automating all other aspects provided by a
Graphical User Interface (GUI) as equivalent commands are not exposed and the scripting language was basic.
Windows scripting host (Wscript.exe) and its command-line counterpart called Cscript.exe was introduced in 1998 with the release of Windows 98 to address some of the challenges. It is a language-independent scripting environment and allows scripts written in Jscript and VBScript using the APIs exposed by applications. There were deficiencies in this scripting environment due to limited documentation and interoperability issues with shell and security vulnerabilities. There were several security breaches as computer viruses exploited features provided by WSH. There were a few other attempts made by Microsoft to build utilities for specific purpose—for example, netsh—with their list of supported command sets, but they were not integrated with the shell and were inoperable.
In 2005, Microsoft released a new shell called Monad (also known as Microsoft Shell(MSH)), which is designed to automate a wide range of administrative tasks and is based on a new design as opposed to its predecessors.
Similar to the command.com and cmd.exe shells, Windows PowerShell can run three types of programs: built-in commands, external programs, and scripts. However, unlike a command shell, the built-in commands are not embedded into the shell environment but are available as modules in one or more .DLL files. This allows both Microsoft and vendors to write custom modules to manage their applications using PowerShell. Now, most of Microsoft and vendor's applications support management through Windows PowerShell, for example, Windows Server, Exchange Server, SharePoint, Lync Server/Skype for business, and VMWare.
Windows PowerShell is different than its predecessors in the following ways:
- Windows PowerShell processes objects instead of text that are based on the .Net framework and provide lots of built-in commands
- All commands use the same command parser instead of different parser for each utility, which makes the use of PowerShell consistent and easier as compared to the earlier shell environments
- Administrators can still use the tools and utilities that they are used to in Windows PowerShell such as Net, SC, and
Reg.exe - As PowerShell is based on the .NET framework, one can write their own cmdlets using Microsoft Visual Studio and languages supported by the Common Language Runtime (CLR) such as C#
With the release of PowerShell 2.0, some APIs (application programming interface) were released that could be used to invoke PowerShell commands right from within your applications. Applications can then use certain PowerShell commands to perform a specific operation, which earlier could only be performed by GUI.
Starting from Exchange Server 2007, this capability has been used to its best advantage as will be explained over the course of the book. Learning PowerShell will help you in managing Microsoft, vendor applications, and services that support PowerShell. It will provide you the skillset required to manage and automate different aspects of Microsoft cloud-based offerings such as Office 365 and Windows Azure. Both of these support PowerShell and have specific modules for management. However, our focus in this book will be on managing Exchange through Windows PowerShell. At times, GUI is strictly used for illustration.
If you are interested in a .Net development, you can write your own cmdlet (pronounced as command-lets) in PowerShell that will perform a specific operation. For this, you will need PowerShell 2.0 Software Development Kit (SDK) and Visual Studio Express Edition. Both of these are free downloads.
Tip
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
The following table summarizes the history of the different versions of Windows PowerShell:
|
Version |
Year released |
Operating systems |
Features |
|---|---|---|---|
|
1 |
2006 |
Windows Server 2003, Windows Server 2008, Windows XP SP2, and Windows Vista |
First release |
|
2 |
2009 |
Windows XP SP3, Windows Server 2003 SP2, Windows Vista SP1, Windows Server 2008 R2, and Windows 7 |
Remoting, Eventing, jobs, modules, ISE, and Exception handling |
|
3 |
2012 |
Windows Server 2012 and Windows 8 |
Session connectivity, Scheduled jobs, update-help, and resumable sessions |
|
4 |
2013 |
Windows Server 2012 R2, Windows 8.1, Windows 7 SP1, Windows Server 2008 R2 SP1, and Windows Server 2012 |
Desired State Configuration, Enhanced debugging, exportable help, and network diagnostics |
|
5.0 |
2015 |
In Public Preview at the time of writing this book |
OneGet, PowerShellGet, class definitions, and switch management improvements |
