Now let's explore how modules get imported
into your PowerShell session, both
explicitly and also by using the auto‑load
feature. There's a number of modules
installed on a Windows system by default
out of the box, and I'd like to spend a
few minutes working with those before we
look at installing and managing
non‑default modules. You can use the
command Import‑Module to explicitly import
a module into this session. But before we
do, let's check out the help quickly by
running Get‑Help Import‑Module. You'll see
here in the first syntax block that the
only mandatory parameter we need to
specify for the Import‑Module command to
run is ‑Name. And additionally, it is
positional, so we aren't required to use
the name parameter, but we will to start
with. Seems reasonably straightforward,
right? Before I import a module, if I run
Get‑Module, you'll see the modules that
are imported into our current session. And
remember, as we discussed in the last
clip, this only shows us modules that have
bean imported into this particular
session. So let's import a module, and
I'll do that by running Import‑Module
‑Name BitsTransfer. That's all the help
said that I need to specify, so we should
be good. If I run Get‑Module again, you'll
see that the BitsTransfer module is now
loaded into this session and is ready for
use. Now there's a command that I happen
to know about named Get‑SmbShare that is
not included in any of these modules that
have been imported into this session so
far. It is a command that's a part of a
module named SMBShare. Because of the
auto‑loading feature we spoke about
previously, I do have the ability to just
run the command, and, as the SMBShare
module is sitting in one of those PS
module paths, PowerShell will go and find
which module the command is a part of and
then import the module for me. Let's try
it out. I'll run Get‑SmbShare, and the
command executed, and I can see a list of
shares on this machine. If I run
Get‑Module again, you will notice that the
module named SmbShare has automatically
been loaded into my PowerShell session
because I used a command that is included
in that module. In a nutshell, that's how
the auto‑load feature works. Again, let me
just reiterate so this really hits home.
Auto‑load won't work if the module is not
sitting in one of the paths included in
the PS module path variable. I hope with
these examples, you've seen the power of
having modules in the PS module path and
the benefits it can provide. With that
said, there may be times where you don't
have the module stored in one of those
paths, and you just want to load it in ad
hoc from somewhere else on the file
system. This can be achieved by specifying
the full path to the folder that contains
the module when running the Import‑Module
command. You might want to do this if
you're doing some testing of a development
or test module and you just want to
quickly load it into your session. I've
got a web browser here, and I'm on a
Github page that is the home for a
PowerShell module created by a good friend
of mine that allows you to query a popular
data breach service named Have I Been
Pwned, which, as an aside, is a great
service created by another Pluralsight
author named Troy Hunt. The PowerShell
module itself is named Have I Been Pwned.
Now this module is actually on the
PowerShell Gallery, so I don't need to
come to Github to get this module, and
I'll show you in the next module in this
course how to install from the Gallery.
But I'm just using this as an example of
maybe getting a dev or test branch of a
module from somewhere like Github that you
might want to try or test out. If I click
on this code icon at the top, I can
download a zip of this code repository
down to my computer. Let's open that
download location, and I'll unblock the
file in the properties and then extract it
and put it in the root of this downloads
folder. I'll just rename that extracted
folder to remove the ‑master. So now we've
got this folder named haveibeenpwned and
inside of that are all the script files
that make up this module. I don't want to
go too far into this, but let's take a
look inside of this public folder and
you'll see all of the commands for this
module are stored there as discreet script
files. So that's just a quick under the
covers look at what it actually looks like
inside of a module folder. Okay, so now
we've got a PowerShell module in a path
that is not listed in the PS module path
variable because it's currently in my
downloads folder. Let's go back to the
PowerShell console and try doing an
Import‑Module ‑Name haveibeenpwned, and
we'll see what happens. And you'll notice
it fails because PowerShell wasn't able to
find a valid module file in any module
directory. But I can explicitly import the
module into this PowerShell session by
running Import‑Module ‑Name and then
specify the full path to the module
folder, which in this case, is
C:\Users\Matt\Downloads\haveibeenpwned.
I'll run Get‑Module again and you can see
the haveibeenpwned module is now imported
into this session, and the commands are
available for me to start using. Finally,
let's explore one of the use cases we
spoke about in the earlier theory clip
where you can use Import‑Module to define
a prefix for all commands included in a
module. You may want to do this to avoid
conflicts between commands in different
modules that have the same name. I know of
a default module named Scheduled Tasks, so
let's run Import‑Module ScheduledTask and
I'll specify the prefix parameter and
we'll use a prefix of PS for Pluralsight.
If I run get module, you'll notice the
module has been imported successfully. And
if you look closely at the commands, they
all have a prefix of PS. So normally this
first command would simply be
Disabled‑ScheduledTask, but due to us
importing the module with a prefix, to run
this command now, we would need to run Disabled‑PSScheduledTask.