Alrighty, it's demo time. Let's kick off
by taking a look at the paths PowerShell
will look in to find any modules that have
been installed which are stored in that
environment variable we just spoke about,
PSModulePath. Over here in the PowerShell
7 console, if I run $env:PSModulePath to
take a look at the current value, we've
got a few folders in here that are
separated by a semi‑colon. Let's run that
again, but use the split operator to split
that value on the semi‑colon. There we go,
that's a bit easier to read. These are the
paths to the locations of the modules that
are installed on disk, and PowerShell uses
these paths in order to locate modules
when you don't specify the full path to a
module. Given we're working with
PowerShell 7 here, just a quick sidebar on
something I want you to be aware of. By
default, Windows PowerShell and PowerShell
7 store modules in different locations.
PowerShell 7 combines these locations in
the PSModulePath. environment variable. So
if you looked at this default environment
variable in Windows PowerShell, it
wouldn't list these two folders, but
PowerShell 7 automatically combines all of
these paths into the variable to make it
easier for you to migrate across from
Windows PowerShell. You can add a path
into this environment variable to tell
PowerShell to search for modules in
another location on your machine. Let's
say, for example, I had a folder in the C
Drive named MyPowerShellModules. You can
add this path by running $env:PSModulePath
=, then repeat $env:PSModulePath,
indicating that we want the current value
plus my additional path of
C:\MyPowerShellModules. Note there that I
have also put a semi‑colon at the start of
that, because I'm adding this value to a
string of paths separated by the
semi‑colon. If I up arrow and rerun the
value splitting it on the semi‑colon,
you'll see the path to
C:\MyPowerShellModules is now added to the
list. Now, that is only persistent for
this PowerShell session. If I close
PowerShell and then relaunch it, and then
look at the value of that environment
variable again, actually let's split it on
that semi‑colon to make it easier to see,
you will notice we no longer have our
custom path listed. There are a couple of
ways we can make sure that the value of
PSModulePath has our custom folder in
every session. The first way is to add the
previous command to a PowerShell profile,
so every time PowerShell is launched it
will amend that variable. Another way is
to make a permanent change to the
environment variable in the operating
system. Now, I could show you how to do
that using the Windows interface, but,
hey, this is a PowerShell course, so let
me show you how to do that using
PowerShell. I'll start by creating a new
variable named currentpath, and for the
value I'm going to use the
GetEnvironmentVariable method, and I want
to get the environment variable named
PSModulePath in the context of the
Machine. Let's take a look at the value of
that currentpath variable, and split it on
the semi‑colon. We've got a couple of
paths returned there that we just saw in
the previous example. We're not seeing all
of the paths that we did a few minutes
ago, because not all of them are stored in
the Machine environment variable context.
I'll create a new PowerShell variable
named $newpath, and for the value I want
those entries for the currentpath, and
similar to before, I'm going to add in the
value for C:\MyPowerShellModules. Again,
note that I'm dropping a semi‑colon at the
start because we're adding this to a
string already separated by semi‑colons.
To add our custom path, we can use the
SetEnvironmentVariable method, noting that
we want to set the PSModulePath
environment variable, and the value we
want to set is $newpath, which contains
the semi‑colon‑separated string of paths,
including our custom path, and we're
setting the Machine environment variable.
In PowerShell, no news is usually good
news, but if I up arrow back to retrieving
the value using the Get method, and then
split that on the semi‑colon, you'll see
our custom path is now listed and will be
used by PowerShell. This time, if I close
the PowerShell session and then reopen it,
and then check out the PSModulePath
variable, in a brand‑new session you'll
see the custom path is still listed,
because it's now set in the Windows
environment variable. To finish up here,
I'm going to run the command Get‑Module
with no parameters, and we'll see what
modules have been loaded into this
specific PowerShell session. We've got a
couple there that's always loaded when
PowerShell is launched. I want to repeat
that so it's clear. Get‑Module with no
parameters will show the modules that are
currently loaded into this session. It
doesn't return a list of all modules that
are installed on this computer. To do
that, you can run Get‑Module with the
ListAvailable parameter. And if I scroll
up to the top, check this out, these are
the paths that are specified in the
PSModulePath environment variable, and
PowerShell has gone and looked in each of
those paths to see if it can find any
modules. And as you can see, it's found a
heap that are installed by default.
PowerShell will only be looking in paths
that are stored in our PSModulePath
variable. If we have PowerShell modules on
our system that aren't stored in one of
those paths, neither Get‑Module nor Get‑Module ListAvailable will locate them.