If you're familiar with Linux and
installing software, you'd be comfortable
with the concept of package managers for
software, such as APT, YUM, and RPM. When
it comes to Windows, however, historically
there hasn't been a streamlined approach
for PackageManagement and automation of
software deployment. The concept of a
package manager at its core is relatively
straightforward. It should keep track of
what software is installed on your
computer while allowing you to easily
install new software and remove software
you've previously installed. Somewhere
around 2015, Microsoft released a feature
named PackageManagement, and formerly this
was referred to as OneGet. So, if you see
OneGet referred to in any of your research
or reading, know that OneGet and
PackageManagement are one and the same.
The PackageManagement feature is a
PackageManagement aggregator. It aims to
create a consistent approach for the
discovery, installation, and
uninstallation of software. That's what
this PackageManagement core component is
responsible for that we're looking at
onscreen at the moment. PackageManagement
comes with a PowerShell module and a set
of PowerShell commands that can be used to
manage the PackageManagement core
components. The module is simply named
PackageManagement, and although in this
architecture diagram it does say End User,
that's not really what you and I think of
as being the end user. The targeted end
user here is really the IT practitioner,
you know, you and I. The commands in this
module allow you to perform tasks, like
finding packages, installing packages, and
uninstalling packages, so on and so forth.
You might be thinking that this
PackageManagement PowerShell module is
what we're going to be working with in the
rest of this course, and to that I would
say yes and no, and you'll see why in a
moment. The next piece of this
architectures are the PackageManagement
providers. The PackageManagement core
framework provides an extensible plug‑in
model that allows different installer
platforms to plug into the framework, and
these are known as package providers.
There are a key set of providers that come
in the box with Windows, shown in green,
but there are additional providers that
can be added into this framework. The key
provider I want to point out here at this
point is a default provider named
PowerShellGet. We will speak more about
PowerShellGet in a moment, but this is the
component that we'll mostly be working
with as we move forward in this course.
The final piece of the PackageManagement
architecture are package sources, so the
providers need somewhere to get the
software from that you want to discover
and install on your machine or other
machines in your company, and that's where
the package sources come in. And sometimes
these are referred to as repositories. In
summary here, that's an overview of the
PackageManagement feature within Windows.
Now remember, this framework is used to
manage any software on your machine. As
long as the software is located in one of
the package sources, you can use a
provider to manage that software. When I
say any software, I mean everything from
web browsers to media players to PDF
readers, collaboration tools, you get the
idea. You may be wondering why I'm telling
you about Windows software
PackageManagement in a PowerShell course,
and the reason for that is that this is
the framework that we end up using to
discover and manage PowerShell modules,
which, when you think about it, are just
software packages. A lot of this is
abstracted for us because we use commands
from the PowerShellGet provider, but it is
important to understand how this framework
looks, especially as you move forward and
maybe look at adding and exploring other
providers and sources. PowerShellGet is a
PackageManagement provider, and it's the
package manager for PowerShell packages.
Under the hood, PowerShellGet heavily
leverages the PackageManagement Framework.
Simply put, it's a PowerShell module that
contains commands for managing PowerShell
modules, scripts, and DSC resources,
providing capabilities such as
discovering, installing, updating, and
publishing PowerShell packages. By
default, PowerShellGet connects to the
PowerShell Gallery, which is the most
common and popular public PowerShell
repository, and we'll touch more on
repositories in a moment. PowerShellGet is
an inbox module if you have Windows 10 or
newer, Server 2016 or newer, PowerShell 6
or newer, or the Windows Management
Framework 5.0 or newer. And it requires
PowerShell 3 or later, as well as the .NET
Framework 4.5 or newer. As I mentioned in
passing earlier, the commands inside of
the PowerShellGet module are what we'll be
looking at with the remainder of this
course. A few moments ago on the
PackageManagement architecture overview,
we saw package sources, and in the world
of PowerShell, you'll mostly find these
referred to as PowerShell repositories.
PowerShell repositories are central
locations to share, store, and discover
PowerShell content. As a publisher of
PowerShell modules, you should look to
publish your code to a PowerShell
repository, and as a consumer of
PowerShell, a repository is where you'd go
to discover and install modules. You can
use the commands in a PowerShellGet module
to discover, install, update, and publish
code to and from any PowerShell
repository. Repositories can be public or
private. In the demo, I will quickly show
you an example of creating a private
repository based on a Windows file share.
You may want to explore the use of private
repositories if you or your company
creates PowerShell content that you don't
want to publish on a public repository.
I've also seen examples of where security
teams within a company like to review
PowerShell content before users install it
on their machines, so they block access to
public repositories and set up a private
repository. The security team is then
responsible for reviewing packages from a
public repository and making them
available to internal users via that
private repository. By far, the PowerShell
Gallery is the widest used public
repository, and it is also configured as
the default public repository. The
PowerShell Gallery is provided by
Microsoft, and you'll see in the demos
without having to configure anything at
all, we can start searching through the
PowerShell Gallery for PowerShell modules.
But Matt, what does this actually look
like when it's all put together? Well, I'm
glad you asked. Let's conceptualize this
at Globomantics, and we'll start with the
PowerShell Gallery, which is that public
repository, and it's configured by
default. Jill is also wanting to set up a
private repository, just a file share to
get things going and to start testing out
how to use and manage a private
repository. Nothing too fancy. Jill has
her computer, which is a Windows 10
desktop machine, and she now needs to
integrate with these repositories to find
and install modules. And that's exactly
where the PowerShellGet module comes in.
This module includes commands like
Find‑Module, Install‑Module,
Update‑Module, et cetera, and we'll get
into a heap of those in the next few
clips. Jill can leverage these commands to
search the PowerShell Gallery and then
install modules locally on her machine
directly from the gallery. Because the
PowerShellGet module is built on top of
the PackageManagement Framework, those
exact same commands can be used by Jill to
look inside the private repository and
install PowerShell modules on her machine
directly from the private repository as
well. Moving forward in this course, apart
from creating a private repository just to
show you what that looks like, we'll be
doing all tasks with the PowerShell
Gallery. But the nice thing is that when
you've learned the commands and the
workflow of how to manage modules once, it
doesn't matter which repository or how
many repositories you need to work with
moving forward, as the processing commands will be exactly the same.