Now the whole point of working with variables is to
make it easier to use PowerShell.
For example,
I'm going to create a variable called $logs and it's going to
contain the results of the Get‑Winevent command and that's going
to get the 1000 most recent events.
I'm giving you some command examples that might take a long time to run,
although in this case, it's really not going to take that long at all.
But now I have a variable that holds the results of that command.
I can now work with those objects just as if I had run Get‑Winevent so
I can say take $logs and pipe it to Group‑Object.
And so, I want to group on the LevelDisplay Name with NoElement.
So I just want to see hey,
what types of entries have I gotten in the system log for the
last 1000 record or maybe I want to take all those logs and
group them on the provider name.
Same idea. What sources of problems or information
am I getting in the event log?
I don't have to rerun Get‑WinEvent.
I can use the results that are saved to that variable.
Now here is one that's a little more complicated.
So let's take $logs and I'm going to pipe this to where object where the
provider name is equal to service control manager, and I want to select the
TimeCreated LevelDisplayName and the Message.
So there we go.
So again, I don't have to rerun Get‑Winevent.
I can use the saved results really quite handy. Now
sometimes the variable might change.
So let me show you what I'm talking about.
Let's go back and rerun that veg command to Get‑Vegetable,
everything vegetables starts with c, save it to $veg.
Alright, so there we can see. Now look at the corn object there,
see there are 12.
I'm going to use Set‑Vegetable and change the corn value to 1 and
I'm using ‑Passthru so it'll update the results.
Go back and look at the variable now, that changed the value.
This doesn't happen all the time.
Sometimes it does, sometimes it doesn't, there is no way for you
to know unless you try it and see for yourself.
It doesn't always, but it might. For example, here, look at this.
Get‑Service BITS, we'll save that to variable $bits, and if I select the
name and StartType, you can see it is set to Manual.
If I change the StartType to Disabled and then select it
again because I'm going to do ‑PassThru, so that changed the
actual service and it disabled it.
However my bits object, the variable, shows a StartType of Manual.
So in this case, there is no connection between the
variable and the source object.
The next thing to take into account with variables is type.
So let's go back and recreate $a equals to 2.
And as I have shown you, $a, if I pipe this to Get‑Member, is an integer.
The variable itself really is meaningless as what's
inside the variable that count.
I can do things like $a + $a and I get 4.
So let's assign a variable $i. Now notice here I'm putting this
in single quotes, which makes it a string.
You can even see the color coding change that PowerShell did.
Now let's try to add this because I think oh yeah,
it's going to be, it didn't work.
Nope. I was expecting 10, but I got 55 because PowerShell saw that I was
treating that as a literal string 5, and so it just gave me 2 literal
strings put together. And you can verify this if I pipe $i to Get‑Member
and you can see that it is a string. Get‑Member will be a cmdlet that you
will use all the time.
Now what you could do is I can cast or tell PowerShell hey create $i,
but make it an int32 and give it a value of 10.
Normally, PowerShell if I just $i equals 10, it would do that automatically.
You don't always have to do that.
Sometimes it makes more sense to you if you see it go oh
yeah that reminds me that's an int32.
Now if I multiply that variable by 2, I get the value that I am expecting.
Where it gets tricky or sometimes helpful is with dates. So I can take a
string 12/31/2022 and turn that into a datetime object saved to variable $d
and you see PowerShell treats it as a datem and if I pipe to Get‑Member,
sure enough you can see that it is a system.datetime object. Now this is
where it gets tricky and where you have to be careful. So I have $d,
remember I just created it as a date. Now I'm trying to assign it a value
of the string foo, and PowerShell will complain because it says,
hey,
$d is a datetime object and you're trying to give me a string and I can't
make foo into a date so I'm going to give you an error.
This is where you need to be careful with your variable names so that
you make them meaningful and you're not reusing variables, although I do
all the time and you probably will too, although just be aware that you
may encounter this problem if you created a variable and forgot what
type that you cast it to.
So there are ways around that. I can say hey take $d and
create a string of foo and now that will work.
So you really need to be careful with the variable
names and how you are using them.
Let me show you one more slightly advanced alternative.
So I'm going to take $t and assign a string to it.
And now you can see $t, it looks like a date, but really if I pipe to
Get‑Member, you can see, sure enough, it is a string, but I can tell
PowerShell, hey I want to treat that as a datetime object.
Take $t and treat it as a daytime object and PowerShell certainly does.
This doesn't change the value of t.
T Is still a string which has a length property.
So all I did was a one‑time operation that just said take $t,
turn it into a date, write it to the pipeline.
It leaves t alone, it doesn't change that at all.
That's again,
something we'll cover a little bit later in the course,
but I wanted to give you a taste.
Alright, so that's a look at using variables in PowerShell and why you might
want to do them, some of the things you might run into. Let's go back and look at some more slide.