If you would like to read the other parts in this article series please go to:
- PowerShell Essentials (Part 2)
- PowerShell Essentials (Part 3)
- PowerShell Essentials (Part 4)
- PowerShell Essentials (Part 5)
- PowerShell Essentials (Part 6)
- PowerShell Essentials (Part 7)
- PowerShell Essentials (Part 8)
- PowerShell Essentials (Part 9)
- PowerShell Essentials (Part 10)
Last week I received an E-mail message from an IT pro who had just lost his job to corporate downsizing. Needless to say, he was anxious to find another job, but he didn’t ask me for employment. Instead, he asked me what was the single most important thing that he should focus on learning right now.
While this question sounds really simple, it was actually quite provoking. After all, there is so much going on in IT right now. I thought about telling him to focus on server virtualization or perhaps software defined networking. Ultimately, I told him to learn as much as he could about PowerShell. PowerShell is used in most of Microsoft’s current line of server products, and there are no signs that it is going to go away any time soon. Although basic administrative tasks can usually be performed through a GUI, administrators must often delve into PowerShell to make infrastructure level configuration changes. While this certainly does not hold true in every case, it is becoming more and more common to have to perform tasks through PowerShell.
During one of my visits to Redmond a while back, I had the chance to chat with someone who worked on the Exchange Server team. I asked why so many tasks within Exchange Server had to be performed through PowerShell. The answer that I received kind of surprised me.
It was explained to me that in some ways, the extent to which Exchange Server administration requires PowerShell had to do with protecting less experienced administrators from themselves. Basic administrative tasks could be performed through the management console, but in many cases low level configuration changes or potentially destructive operations had to be performed through PowerShell. The presumption was that if an administrator knew enough to use a PowerShell cmdlet, they probably also knew enough to safely perform the intended administrative action. In other words, performing an administrative task through PowerShell requires intent. You can’t get yourself into trouble by accidentally clicking on something (at least not in PowerShell itself).
The ironic twist is that there are plenty of administrators who do not want to use PowerShell. I don’t say that as a way of being condescending, or of insulting anyone. It’s just that over the last few years I have spoken to and received email messages from quite a few administrators who have expressed frustration with PowerShell.
In some ways, I can understand the frustration. I will be the first to admit that some of the blocks of code presented in TechNet articles look like gibberish. Believe it or not though, PowerShell isn’t nearly as difficult to use as some of the blocks of code shown in TechNet articles might make it seem. The reason why some of the PowerShell examples that you might find on TechNet are so incomprehensible is because PowerShell allows for the use of command abbreviations. For example, the cmdlet (pronounced command-let) Format-List can be abbreviated as FL.
Cmdlet abbreviations are great for PowerShell experts who want to keep commands short and sweet, but when you cram together a long string of abbreviated cmdlets, the command string begins to look like a bunch of random characters.
I’m actually getting a little bit ahead of myself. I will talk about PowerShell cmdlet abbreviations later on in this article series. For right now, let me just say that I have one simple goal for this article series. Because I believe that PowerShell is an essential skill for Microsoft server administrators, my goal is to teach you the fundamentals and to make learning PowerShell as painless as I possibly can.
Basic Command Syntax
As I previously mentioned, PowerShell is based around the use of cmdlets. A cmdlet is a verb – noun combination. A verb is a word that describes an action, while a noun refers to an object. That being the case, a PowerShell cmdlet is made up of two words. The first word (the verb) tells Windows what action you want to perform, while the second word (the noun) tells Windows what type of object you want to perform the action on.
To give you a more concrete example, consider the cmdlet Clear-Host. The verb in this case is Clear and it tells Windows that you want to clear something. What needs to be cleared? The host. As such the cmdlet clears the screen.
Incidentally, if you grew up with DOS like I did, you will be happy to know that most of the old DOS commands work in a PowerShell environment. For example, the DOS command for clearing the screen was CLS. The CLS command can be used in PowerShell as an alternative to the Clear-Host command.
Why are there so Many Cmdlets?
Windows Server 2012 R2 has thousands of PowerShell cmdlets built into the operating system. As if that were not enough, PowerShell is extensible. Microsoft provides modules that add additional PowerShell cmdlets that allow you to perform more specialized tasks. Furthermore, Microsoft server products that are based around PowerShell also have their own sets of cmdlets. You can even develop your own custom cmdlets if you want.
Since there are thousands of native PowerShell cmdlets and many more cmdlets that can be added onto PowerShell, one can’t help but to feel a little bit intimidated and to wonder why Microsoft has created such a large number of cmdlets.
There are a couple of different reasons why so many cmdlets exist. The first reason is that Microsoft wanted to keep things simple. I know that sounds crazy, but hear me out.
If you have worked with some of the native Windows command line tools (executable files, not PowerShell), you probably know that some of the tools are really complicated to use. A command line executable might have a long list of switches that can be used in an effort to accomplish numerous different tasks. This is precisely the sort of thing that Microsoft tried to avoid when they created PowerShell.
Rather than creating a set of complex, multi-purpose commands, Microsoft’s vision for PowerShell cmdlets was to create super lightweight commands that do one thing, and one thing only. Since each cmdlet performs a very specific task, the cmdlets can be linked together to perform more complex, multi-step processes.
Now admittedly, many PowerShell cmdlets do support the use of optional parameters. Even so, most of the cmdlets are fairly straightforward to use.
The other reason why there are so many native PowerShell cmdlets is because of the way that the basic syntax works. As you will recall, each cmdlet is made up of a verb and a noun. Each verb has multiple uses, as does each noun. For example, there are dozens of cmdlets that use the Get verb. In other words, verbs and nouns are designed to be modular so that they can be used together in various combinations. Each combination constitutes a different cmdlet. That’s why there are so many cmdlets.
Conclusion
In this article, I have spent quite a bit of time talking about the basic syntax used in PowerShell cmdlets and the reasons behind that syntax. In Part 2, I want to begin showing you how to actually use some PowerShell cmdlets.
If you would like to read the other parts in this article series please go to:
