Don’t Learn PowerShell, Use PowerShell

Hey, Scripting Guy! I get it. I need to learn Windows PowerShell—I see it mentioned everywhere. The problem is that I don’t have five years to learn the stuff. And besides that, by the time that five years has passed, you guys will probably come out with at least two new versions of Windows PowerShell. So if I spend five years trying to learn Windows PowerShell 4.0, by the time I am done learning it, I will still be three or four versions behind. I feel like I can never catch up—like a hamster running around on a wheel. I never seem to make any progress. What can I do?

—GM

Hello GM,

Microsoft Scripting Guy, Ed Wilson, is here. I just got back from the gym. Luckily, the gym I go to is open 24 hours a day, so I can get up early and get back to still start my day. I kind of know what you are talking about. I did three miles on the treadmill this morning—and in the end, I never really moved an inch of distance.

GM, I can see what you are talking about, but you are basing your argument on a false argument. You do not need to learn everything there is about Windows PowerShell to use it. In fact, the vast majority of IT pros never write a single Windows PowerShell script. The difference between Windows PowerShell and VBScript (or some other scripting language) is that Windows PowerShell is not only a scripting language. In fact, it is possible to use Windows PowerShell without learning Windows PowerShell at all. This is because Windows PowerShell is an interactive environment in addition to a scripting language. Your problem has given me a good reason to introduce Don't Learn PowerShell Week.

Windows PowerShell ISE: Not only for scripts

The Windows PowerShell ISE is not only for writing scripts. In fact, I use it nearly all the time. The reason is that it is a great interactive console, and if I have more than a single command I want to type, I can move to the script pane, type my commands, and then run them. I do not have to write a script. The Windows PowerShell ISE is shown here:

The upper white box is the script pane. The bottom blue box is the interactive Windows PowerShell console. It is also where the output from the script pane appears. The right pane is the Command Add-on. By default, when the Windows PowerShell ISE first launches, the Command Add-on appears. If I close it by clicking the “X” in the upper-right corner of the Command Add-on or by clearing the Show Command Add-on menu item (as shown in the following image), the next time I launch the Windows PowerShell ISE, the Command Add-on does not open. If I later decide that I want the Command Add-on, I select Show Command Add-on in the View menu.

What good is the Command Add-on anyway?

The Command Add-on is a great tool because it permits me to build commands on the fly. It also permits me to find Windows PowerShell cmdlets without knowing anything about the cmdlet name or about Windows PowerShell verbs or nouns. For more experienced Windows PowerShell users, it is a great tool to use when demonstrating to beginners how Windows PowerShell works.

First find the command

Obviously, the first thing to do is find the appropriate Windows PowerShell command. Windows PowerShell commands are often cmdlets—as in a little command. Notice that by default, the Modulestext box is set to All. If I know what module contains the command I want to use, I can select that module from the drop-down list. But when starting out, I would not even know what a module is, and I would definitely not know which module might contain the command I am interested in using. So I leave Modulesset to All, and I begin typing in the Nametext box. As I type, the cmdlets filter out until I am left with only a few cmdlets, as shown here:

I look at the commands, and I see that some of them contain the word VMProcessor. I might guess that it has something to do with a virtual machine (because of the letters VM). Other commands, such as Debug-Process, Start-Process, and Stop-Process appear to be self-explanatory: Debug-Process probably has something to do with debugging a process, and Start-Process and Stop-Process probably permit me to start or stop a process.

One of the nice things about Windows PowerShell is most of the cmdlet names tend to make sense. (This is unlike the old-fashioned type of command names, such as SC, which seem to have very little relationship to anything.)

If I select the Get-Process cmdlet from the filtered Command window, the bottom pane immediately changes to display the parameters for Get-Process. This is shown here:

Each parameter set (ways of using the cmdlet) appears on a different tab. The default is Name, and it appears as the one that is automatically selected. I can add the target ComputerName. I can also choose to display file versioning or module information by selecting the FileVersionInfo or Module options. In addition, I can limit the information that is returned to a specific process by entering the process name in the Nametext box.

When I have completed my selections, I have three choices. I can run the command immediately and display the output from the command by pressing the Run button. This is shown here:

Alternatively, if I press the Insert button, the command appears in the interactive Windows PowerShell command window, but it does not execute. This permits me to make changes to the command, or to add additional commands to the command line prior to running the command.

In the following image, I have cleared the output from the previous command by pressing the Window wiper, squeegee, which is located on the Add-ons menu. Notice that the Get-Process command appears on the first line in the Windows PowerShell console, but it has not yet run.

If I want the command in the script pane, I need to click the Copy button to place the command on the clipboard. I then paste it into the script pane at the appropriate location. This is shown here:

So, by using the Windows PowerShell Command Add-on pane, I can easily find, create, and execute Windows PowerShell commands on the fly without having an in-depth knowledge of Windows PowerShell.

GM, that is all there is to using the Show-Command command. Don’t Learn PowerShell Week will continue tomorrow when I will talk about more cool stuff.

The new version of the ISE.is terrific. I found that the easiest way to lean is to solve a problem you have in your current environment. It could be as simple as searching AD for expiring accounts or more complicated as automating new account creation.
I mainly use Powershell to automate tasks in my Citrix environment or to answer questions about my environment.

> So if I spend five years trying to learn Windows PowerShell 4.0, by the time I am done learning it, I will still be three or four versions behind.

I think that you don’t necessarily need to keep up with all the new functionality all of the time. There’s some great stuff in the later versions and it’s good to be up to date, but you can still get lots of value from just the bits that were in Powershell
2.0.

I can only presume there are different versions of Powershell_ise around. I’m on Windows 7 Enterprise SP1 and do not have ‘Show Command Add-on in the View menu’ meaning that it is virtually impossible to perform anything useful without learning about the
language.
I want to do something fairly simple, produce some means of automating the set up of AppLocker at the end of an automated install.