Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell cmdlets to do IT ops work.
Hey, Scripting Guy! I have been an IT pro for many years, and to be honest, I am really good at my job. Now it seems you guys are abandoning me. I have been a loyal Microsoft supporter for many years, and I even got my MCSE back on Windows 2000. Now it seems like you want me to learn command-line stuff like AS400 or VAX. I learned Windows because I like graphical tools. I am good with a mouse, but I hate to type. What gives?
—BV
Hello BV,
Microsoft Scripting Guy, Ed Wilson, is here. One of the basic principles of Windows PowerShell is that it honors your learning. This actually plays out in many ways. From Windows PowerShell version to Windows PowerShell version, the things you learn in one version continue to work in the subsequent version. This means that, for example, the book I wrote on Windows PowerShell 1.0 is still valid. It is a basics of Windows PowerShell kind of book. Of course, we added new features and made things much easier in later versions, but the basic principles remain the same.
BV, there is another way in which Windows PowerShell honors your learning, and that is where your Windows admin skills come into play. It is a common saying that “PowerShell is PowerShell is PowerShell.” Actually, I made up that saying, but amongst people I know, it has become a common phrase.
What I mean by that, is that when properly implemented, Windows PowerShell cmdlets for one technology behave exactly the same as Windows PowerShell cmdlets for another technology. So if I understand the basics of Windows PowerShell, such as how to use a cmdlet, and how to pipeline the results from one cmdlet to another, theoretically, Windows PowerShell fades into the background and permits me to simply do my job. (Obviously there are some cmdlets that use unapproved verbs, don’t accept pipelined input, don’t emit objects, and the like, but I was talking theoretically.)
Because I know Windows PowerShell, it does not mean that I can, for example, create a new firewall rule if I don’t know anything about firewall rules. But if I do know something about firewall rules, I can certainly use Windows PowerShell to create a new firewall rule.
Creating new firewall rules
If I want to create a new firewall rule, the first thing I do is open the Windows PowerShell ISE with admin rights (I do this by holding down the Shift key while I right-click the shortcut to the Windows PowerShell ISE.) I then select Run as Administrator from the action menu. (I can also search for Windows_ISE and then right-click the search results and select Run as Administrator).
I do this because an ordinary user probably does not have rights to create or modify the Windows Firewall configuration. When I have the Windows PowerShell ISE open with admin rights, I type the word firewallin the Name text box of the Command Add-on. The results shows many Windows PowerShell cmdlets that are related to firewalls. This output is shown here:
If I did not know anything about Windows PowerShell, I can still look over the output and see if there is anything that looks like it might help me create a new firewall rule. The command name I see is New-NetFireWallRule. When I click it, it says something about importing the module and its cmdlets.
I may not have any idea at all about this, but it does say click the Show Details button. And to be honest, the output message is a bit misleading. I mean, it talks about importing modules, and the button is called Show Details. I would imagine that when I click a button called Show Details, it might...well...you know...show details about what it was talking about—sort of a “For more information” button.
But that is not what happens. What really happens when I click the Show Details button is that it imports the module that contains the New-NetFireWallRule cmdlet and the other firewall cmdlets. It then displays the parameters of the cmdlet in such a way that I can create my command. But hey, I can certainly click the Show Details button because I know how to use a mouse. This is shown here:
When I click the Show Details button, the parameters for the New-NetFireWallRule cmdlet appear. It is now "fill-in the blank" time. This is where knowledge of how to configure a new firewall rule would certainly come in handy. Here are the first details of my new firewall rule:
Many of the parameters are configured directly from drop-down lists. This permits me to do a minimal amount of typing. In addition, it ensures that I am configuring the cmdlet in the proper manner. This is shown here where I specify the encryption requirements:
When I have completed my configuration for the new firewall rule, I am permitted to select WhatIf (this is because running the command would make changes to my system). Selecting this is a really, really, really good idea! Here is that selection:
Now I click Copy, and I paste my command into my Script pane. I then run the command by clicking the green triangle (or pressing the F-5 function key). The command and its output are shown here:
I can see that what I created is a one-line command. This means that I will need to use the scroll bar under the Script pane to see all of my command. I could also break it up by using the grave accent ( ` ) character which is line continuation. (But this is an advanced topic, and to be honest, I do not do that until I get the command to run properly in the first place.)
I made several errors in configuring my command, so my output pane is filled with red output. It is very important not to ignore this output because it tells me that I messed up, and it also tells me how to fix it.
It is entirely possible that an experienced Windows Firewall administrator would not have made the errors that I did. For example, the command tells me that I did not specify the address properly. I can use a specific IP address, a range, or even a subnet, but evidently not a generic wildcard character. It also says that I can use certain address keywords, such as LocalSubnet, DefaultGateway, or Intranet, in certain places.
I make the change, run it again, and I get another error message. This time it says that I have a mismatch between Authentication and between Encryption. So I follow the recommendations and fix it. Then it tells me that I have the wrong protocol, so I fix that. Eventually, I get it to where the command does not error out.
As shown here, it tells me that if I run the command, it will create the new rule:
Cool. So like I said, Windows PowerShell honors your learning, and doing things like configuring a new Windows Firewall rule is easier if one knows what one is doing.
I now have a functioning new firewall rule. What do I do with it?
I can copy the one-line command and make a few changes to it, then create another rule. Or I can click the Refresh button, and use the Command Add-on to make a new rule, and then paste it under my previous command in the Script pane.
If I continue to do this, I can save the file and use it as a script to configure multiple computers. That is where the real power of this stuff comes into play. In addition, as opposed to clicking through the GUI tools (of the Firewall Admin tool, for example), I now have a record of all of the changes that I made. So if I did make a mistake while configuring it, I can go back to my file and see where I messed up. By saving my Windows PowerShell commands, I also document the changes I make. That is the Windows PowerShell advantage.
BV, that is all there is to using Windows PowerShell. Don’t Learn PowerShell Week will continue tomorrow when I will talk about more way cool stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy