Powershell

Microsoft Scripting Guy, Ed Wilson, is here. This morning it is cold. At least, it is Charlotte, North Carolina—it is nearly freezing. That is enough to keep me inside with a nice cup of English Breakfast tea, and a freshly made Blueberry Scone. I decided to check the email sent to scripter@microsoft.com on my Surface Pro 3. Today is one of those days…one where I try to get some work done before the weekend so I do not have to worry too much about the week to come. It is all a balancing act—a bit of preplanning and a modicum of luck

DB, you want to know, “What is Windows PowerShell?” To define Windows PowerShell is a bit of a trick, it is much easier to describe what Windows PowerShell does, or why one needs it—but I hate that. In fact, I hate it when I am doing research and I come across a great sounding article. I am looking for a quote for my paper, and nowhere is there to be found any quotable material. Ugh. It provides great for background, but I need a nice succulent quote to support my thesis. It is a common dilemma. So here goes—a nice quote:

Windows PowerShell is an interactive object-oriented command environment with scripting language features that utilizes small programs called cmdlets to simplify configuration, administration, and management of heterogeneous environments in both standalone and networked typologies by utilizing standards-based remoting protocols.

This quote is my definition, and it is not an official definition by any means. It is not even a comprehensive definition, but it should be a pretty good one for a point of departure.

Windows PowerShell is both interactive and script

One thing that confuses people when talking about Windows PowerShell is that they see what looks like a big blue Command Prompt window, and they think “Oh, that is Windows PowerShell.” Then at other times, they see what looks like a really complicated bunch of code, and they think, “Oh, that is Windows PowerShell.”

Of course, one of the great things about Windows PowerShell is that it is interactive. I can easily type a short command, and retrieve tons of information. Here is an example that returns a lot of information about every process running on my laptop:

The command is simple, and rather logical. It is Get-Process. The logical part is that I want to get information, so the command begins with get. That I want to retrieve process information also carries through because the second part of the command is process. Therefore the command Get-Process makes sense—at least once I begin to understand the naming conventions used in Windows PowerShell.

But what about the scripting language aspect of Windows PowerShell? Well, that generally takes place via the Windows PowerShell Integrated Scripting Environment (ISE). The cool thing is that I can use the same commands in my script that I might have used in the interactive Windows PowerShell environment. In fact, in its most simple form, a Windows PowerShell script is a file that contains a collection of Windows PowerShell commands. A Windows PowerShell script has the following advantages:

I can share it with other people.
I can run it again as often as I want to—each time exactly as I ran it previously.
I can use it easily in a scheduled task so that it runs at specific times on specific servers by using specific credentials.

A simple Windows PowerShell script is shown here:

The common information model

I can use the common information model (CIM) to run commands on remote systems and to administer various systems in a heterogeneous environment. This is because the CIM cmdlets adhere to the CIM and the WS-Man standards that are defined by the Distributed Management Task Force (DMTF). For more information about this, refer to the Introduction to CIM Cmdlets.

One thing to keep in mind, is that Windows PowerShell is a .NET Framework application. As such, any user can use Windows PowerShell to perform whatever actions they would have the ability to do. Therefore, Windows PowerShell is not a super tool. If, for example, a user does not have the rights to manage printers or to install device drivers, that user cannot run a script that manages printers or installs device drivers. A user can only do what a user has the ability to do.

In that same mode, an improperly configured system will permit a user to do things that may be destructive if the user could otherwise perform those actions. There is no security by obscurity. In fact, Windows PowerShell is so easy to use. There are many things I know how to do by using Windows PowerShell that would take me time searching the web to figure out how to perform the same action by using a graphical tool.

An example of this is that I know the Export-StartLayout Windows PowerShell cmdlet. By using that, I can export my start screen layout and save it. I have no idea how to do that by using a graphical tool. In fact, I have no idea where I would begin, if it is not somewhere off of the Settings tab..