Topic: Introduction to the Language Constructs

Notice: This post is a part of the PowerShell Monday series — a group of quick and easy to read mini lessons that briefly cover beginning and intermediate PowerShell topics. As a PowerShell enthusiast, this seemed like a beneficial way to ensure those around me at work were consistently learning new things about Windows PowerShell. At some point, I decided I would share these posts here, as well. Here’s the PowerShell Monday Table of Contents.

I’ve long had this feeling that people that learn and use PowerShell don’t really ever get  a fair opportunity, to learn the language constructs. Instead, they just learn them as necessary. In an effort to correct this, I believe we should spend some time in the coming weeks, covering each of them.

Well then, what’s a language construct, right? Well, it’s a control structure, of course. Okay, well then what’s that?

Within a language — PowerShell in our instance — we have to have a way to handle conditional situations, in order to take appropriate action(s). Language constructs are the If statement and its variations, it’s the switch statement, it’s the foreach loop and ForEach-Object, the for, the Do variations, and the While loop, too.

In the coming weeks, we’ll spend some time with each of the constructs, so that you’ve seen and used them all, or simply reviewed them, if you’ve used them before. Knowing which to use when, is a vital skill, and best left to second nature once you’ve had experience with them all. I’ll be sure to include some of the times you might choose one over the other, when you can do the same thing with more than just one of the constructs. We’ll start next Monday with If, If-Else, and If-ElseIf.

Topic: PowerShell’s Importance

Notice: This post is a part of the PowerShell Monday series — a group of quick and easy to read mini lessons that briefly cover beginning and intermediate PowerShell topics. As a PowerShell enthusiast, this seemed like a beneficial way to ensure those around me at work were consistently learning new things about Windows PowerShell. At some point, I decided I would share these posts here, as well. Here’s the PowerShell Monday Table of Contents.

Today is the 26th PowerShell Monday. That means I’ve been writing these for a full half year.

I want to use this morning to point some things out. If you take the time to study each of these emails, then you’re going to be better at your job, where PowerShell can be utilized, in just a year’s time. Take the time to read these whether you already know the content, or not. Now, in conjunction, it’s important to practice what you’re reading, too. Do things in the GUI and then consider how you might complete the same task at the ConsoleHost. Ask questions if you have them, as I’m always willing to help.

I learned early on that PowerShell is going to be a requirement for Windows systems administration. Microsoft keeps proving this, as do other companies that are using it in conjunction with their own products. The inventor of PowerShell is now a Microsoft Technical Fellow — that’s the highest technical title one can receive from Microsoft. He’s the lead architect for the Enterprise Cloud Group and the Microsoft Azure Stack. He presides over Windows Server and the System Center products. Don’t think for a moment that PowerShell won’t continue to play a part at Microsoft. You’re going to need this skill. Keep in mind that we’re not going to need a bunch of click-next admins, as they’re called, in the coming years.

After writing a PSMonday each week for a half of a year, I plan to place the first 26 weeks’ worth of content into a single PDF and distribute that in the coming weeks. If you haven’t read all of them, then this might be a nice way to do that.

On a final note, PowerShell was recently introduced on Linux and Mac. My first thought was, great, soon Windows administrators can support Linux, too. It was after a recent trip to Phoenix for a PowerShell Saturday event, however, where Jason Helmick — a PowerShell MVP — made an interesting point: Linux administrators are going to be able to support Windows, too. It’s time to learn PowerShell, and maybe more about both operating systems. In fact, Jason told a room full of Windows administrators, the same thing.

Topic: $PSDefaultParameterValues

Notice: This post is a part of the PowerShell Monday series — a group of quick and easy to read mini lessons that briefly cover beginning and intermediate PowerShell topics. As a PowerShell enthusiast, this seemed like a beneficial way to ensure those around me at work were consistently learning new things about Windows PowerShell. At some point, I decided I would share these posts here, as well. Here’s the PowerShell Monday Table of Contents.

Now that we have some understanding about commands, cmdlets, functions, and parameters, we can start to discuss the $PSDefaultParameterValues preference variable. This variable allows you to specify default parameter values for cmdlet or function parameters.

This is to say, that you can ensure a specific parameter value is always used for a specific parameter name, for a specific cmdlet or function, even when you don’t explicitly include them. Let’s say you use the Get-ADComputer cmdlet and you always want to use the DC01 Domain Controller to perform the lookup. That’s probably not the best idea, but without $PSDefaultParameterValues, you’d have to type the parameter each time.

Get-ADComputer -Identity membersrv05 -Server DC01

If we defined a default parameter value, we could drop the -Server DC01 from the command and it would still be included. There’s a couple different ways to add an entry to $PSDefaultParameterValues. We’ll use the Add method this week.

$PSDefaultParameterValues.Add('Get-ADComputer:Server','DC01')
$PSDefaultParameterValues

Name                           Value
----                           -----
Get-ADComputer:Server          DC01

Again, with this value set, the command below would still be certain to use DC01.

Get-ADComputer -Identity membersrv05

While we’re here, let’s also look at the Remove method. This is how we’d remove an already existing entry in the $PSDefaultParameterValues variable.

$PSDefaultParameterValues.Remove('Get-ADComputer:Server')

All gone, and all done. We’ll discuss this topic some more next Monday.

 Topic: Commands, Cmdlets, and Functions

Notice: This post is a part of the PowerShell Monday series — a group of quick and easy to read mini lessons that briefly cover beginning and intermediate PowerShell topics. As a PowerShell enthusiast, this seemed like a beneficial way to ensure those around me at work were consistently learning new things about Windows PowerShell. At some point, I decided I would share these posts here, as well. Here’s the PowerShell Monday Table of Contents.

Before we jump into the next topic, I think it would be wise to ensure we discuss the differences between commands, cmdlets, and functions. In doing that, we’ll also learn, or clarify, the differences between parameters, parameter names, and parameter values.

As we’ve learned, in a roundabout way, cmdlets and functions have the potential to include parameters. Scripts in fact, can also include parameters. A parameter is made up of a parameter name and a parameter value, or values.

A cmdlet, such as Get-Service, Stop-Process, Get-EC2Instance, and Set-ADUser, is likely written in C#, and is compiled code. A function, which can be written in a simple text editor, isn’t compiled, as the source can be easily read. These include Get-Volume, Get-Verb, New-SmbShare, and many more, including those we might write ourselves using the ISE, or Visual Studio Code. Those products are both better alternatives to using a simple text editor.

Let’s take a look at a command, break down each part, and then call it a day.

Get-EventLog -ComputerName DC01,DC02 -LogName Application -Verbose

Get-EventLog
This is the command. The term command can be used for just the cmdlet or function, or a cmdlet or function that includes parameters. You might also just call it by its CommandType: cmdlet or function. I’m not completely sure if it’s been mentioned before or not, but cmdlet is pronounced command-let.

-ComputerName DC01,DC02
This is a parameter.

-ComputerName
This is the parameter name.

DC01,DC02
These are the parameter values.

-LogName Application
This is also a parameter.

-LogName
This is the parameter name.

Application
This is the parameter value.

-Verbose
Even this, is a parameter.

Before we wrap up, I want to quickly discuss the last parameter mentioned: Verbose. There are parameter names that don’t require any specified parameter value be included. These are called switch parameters. If they’re included, their parameter value — even though you can’t see it — is True ($true), and if they’re not included, their parameter value is False ($false). Therefore, their default value is always $false.

Alright, back with more next time.