Now that we've seen some examples of early filtering with parameters,
let's take a look at Where object.
Once again, let's do Get‑Vegetable,
and I'm going to filter this where the color is equal to green,
and I'm using the simplified syntax.
Sure enough, you can see that that works.
Here is the same expression,
but using the more traditional syntax with the script block and $_.
We get the same result.
But remember, you can use any property that you see with Get‑Member,
and sometimes you need to look at Get‑Member
because PowerShell will deceive you.
Here is what I'm talking about.
Let's do Get‑Vegetable, and let's filter where the color is equal to green,
and I want the state to be raw.
Do you see there on the screen?
So I just want the raw vegetables that are green.
Now, why is it cookedstate and not state?
That's because I know from previous experience that the state property that
you see listed there is something that PowerShell has added.
That's not the real property name.
The real property name that I see with Get‑Member is cookedstate,
so that's the value that I need to use.
So I'm going to pipe that result then and Sort on the
Count property in Descending order, and there we go.
So now I have all of the raw green vegetables sorted in
descending order by the number of vegetables.
Let's try an example that's more PowerShell, truly PowerShell related.
Let's use the example from the slides where I'm going to
Get‑Service for all the services that start with W where
the Status is equal to running.
Good.
That worked just the way I wanted it to.
Let's try something maybe that's a little more complex.
Let me save a variable to hold the date for today to a variable called $now.
So what I want to do is I'm going to get a directory listing of my
scripts files Where the CreationTime property,
which is something that I discovered in Get‑Member,
is greater than 7 days ago,
so I'm adding this little .NET trick here that Get‑Date,
which has saved to $now, is a DateTime object.
That DateTime object has an AddDays method, and I'm just subtracting 7 days.
Now, I'm not sure I'm going to get anything,
but hopefully I won't get an error, but let's see what happens.
Oh, good.
Alright, so there are a couple of files there that show up.
And if I wanted to,
I could also have done Get‑ChildItem ‑Recurse to search for all
files because I have some subfolders there,
but you can see that that worked.
So Get‑ChildItem, the first part is limiting the search to just ps1 files,
early filtering.
The second half of that statement is using Where object,
so it's saying, given all of the ps1 files now,
now do the second set of filtering, look at the CreationTime,
and if it's greater or equal to 7 days ago,
keep that file object in the pipeline and send it on,
and that's exactly what it did.
I also want to point out or make sure you understand that you can
use any code you want in that script block.
I have a text file with some servers and my little test domain here,
and I'm going to get the content of that file,
so it's just going to be a list of names,
and I'm going to pipe that to Where object,
and now the script block for this is going to take that
ComputerName from the text file and plug it into the parameter
for ComputerName for Test‑Connection.
This is kind of a PowerShell alternative to ping.
So I'm going to do two pings, and the ‑Quiet will just return true or false.
So what this will do is go through, and if the ComputerName can be pinged,
then pass that name on into the pipeline.
Any code can go in that script block as long as it returns true or false.
And in this case, Test‑Connection with that ‑Quiet parameter,
that's exactly what it's doing.
It's returning either true or false.
Alright, so finally,
let's talk a little bit about this performance
difference I've been talking about.
I'm going to just take a look for discovery purposes.
I'm going to get the win32_process class from Get‑Ciminstance
and just grab a couple to take a look at,
first 5.
So I want to get that WorkingSetSize, and I'm going to do this,
well,
I'll use that text file of ComputerNames. So let's
save the ComputerNames to a variable, and now what I'm going to do is I'm not,
I don't really care about the results,
I want to see how long it takes to get the results,
so I'm going to use a new command called Measure‑Command.
Measure‑Command, you then put whatever code you want to run in a script block,
and it will run the code and then tell you how long
it took for that code to run.
I won't see the results of the command, only the results of how long it took.
I want to measure how long does it take to do
Get‑Ciminstance for all of the server names Where the
WorkingSetSize is greater or equal to 50 MB,
and that took about 252 ms.
Make sure we understand what's going on here.
I'm telling PowerShell,
get all of the Win32 process objects from all, from my four or five servers,
and then filter,
and only keep the ones where the WorkingSetSize is greater or equal to 50 MB.
That took 252 ms.
That's not really the best way to do that.
So let's do it what I think is the better way, the PowerShell way.
So we'll do Get‑CimInstance again, same class,
same number of computers, except this time,
I'm going to apply filtering.
So I'm going to say, using Get‑CimInstance,
query on the server as you're looking at the Win32 processes,
like a SQL query, if you will,
only give me the objects Where the WorkingSetSize is greater or equal to,
and that's the equivalent for 50 MB, that's the value then in bytes,
and that took 66 ms.
So that is significantly faster.
And if you take this idea and scale it out,
if you were doing, say, 100 servers,
you'd really begin to see the benefits of filtering
and doing things the right way.
I can't stress enough the importance of getting into the
habit of using good filtering practices.
You never know when it will truly matter,
so if you do it all the time, you don't have to think about it.
And that brings our time in this course to an end.
The key takeaway here is to learn and embrace the
PowerShell paradigm of objects in the pipeline.
Once you really understand this idea,
you'll find PowerShell easier to use and wonder why
you waited so long to learn it.
Objects aren't complicated or mysterious.
Use Get‑Member and Select‑Object to discover them.
Once you know property names, you can use them everywhere.
In fact, if you master the commands and concepts in this course,
you can tackle just about anything in PowerShell.
Need to work with something new, like Azure or VMware?
Not a problem.
Since you already know how PowerShell works,
all you need to learn are the commands related to that technology.
This course hopefully is a good start,
but there's a lot more fundamentals that you'll need to learn,
so I hope you'll join me in a future course. Thanks for watching.