1 00:00:00,940 --> 00:00:02,640 If you're familiar with Linux and 2 00:00:02,640 --> 00:00:04,800 installing software, you'd be comfortable 3 00:00:04,800 --> 00:00:06,730 with the concept of package managers for 4 00:00:06,730 --> 00:00:10,650 software, such as APT, YUM, and RPM. When 5 00:00:10,650 --> 00:00:13,040 it comes to Windows, however, historically 6 00:00:13,040 --> 00:00:15,090 there hasn't been a streamlined approach 7 00:00:15,090 --> 00:00:17,340 for PackageManagement and automation of 8 00:00:17,340 --> 00:00:20,010 software deployment. The concept of a 9 00:00:20,010 --> 00:00:22,730 package manager at its core is relatively 10 00:00:22,730 --> 00:00:24,780 straightforward. It should keep track of 11 00:00:24,780 --> 00:00:26,450 what software is installed on your 12 00:00:26,450 --> 00:00:28,850 computer while allowing you to easily 13 00:00:28,850 --> 00:00:31,320 install new software and remove software 14 00:00:31,320 --> 00:00:34,220 you've previously installed. Somewhere 15 00:00:34,220 --> 00:00:37,540 around 2015, Microsoft released a feature 16 00:00:37,540 --> 00:00:40,810 named PackageManagement, and formerly this 17 00:00:40,810 --> 00:00:43,750 was referred to as OneGet. So, if you see 18 00:00:43,750 --> 00:00:46,110 OneGet referred to in any of your research 19 00:00:46,110 --> 00:00:48,070 or reading, know that OneGet and 20 00:00:48,070 --> 00:00:50,740 PackageManagement are one and the same. 21 00:00:50,740 --> 00:00:52,970 The PackageManagement feature is a 22 00:00:52,970 --> 00:00:55,660 PackageManagement aggregator. It aims to 23 00:00:55,660 --> 00:00:57,300 create a consistent approach for the 24 00:00:57,300 --> 00:00:59,300 discovery, installation, and 25 00:00:59,300 --> 00:01:01,880 uninstallation of software. That's what 26 00:01:01,880 --> 00:01:04,040 this PackageManagement core component is 27 00:01:04,040 --> 00:01:06,000 responsible for that we're looking at 28 00:01:06,000 --> 00:01:09,010 onscreen at the moment. PackageManagement 29 00:01:09,010 --> 00:01:11,110 comes with a PowerShell module and a set 30 00:01:11,110 --> 00:01:13,170 of PowerShell commands that can be used to 31 00:01:13,170 --> 00:01:14,900 manage the PackageManagement core 32 00:01:14,900 --> 00:01:18,070 components. The module is simply named 33 00:01:18,070 --> 00:01:20,580 PackageManagement, and although in this 34 00:01:20,580 --> 00:01:23,590 architecture diagram it does say End User, 35 00:01:23,590 --> 00:01:25,480 that's not really what you and I think of 36 00:01:25,480 --> 00:01:27,800 as being the end user. The targeted end 37 00:01:27,800 --> 00:01:30,260 user here is really the IT practitioner, 38 00:01:30,260 --> 00:01:33,110 you know, you and I. The commands in this 39 00:01:33,110 --> 00:01:35,330 module allow you to perform tasks, like 40 00:01:35,330 --> 00:01:37,970 finding packages, installing packages, and 41 00:01:37,970 --> 00:01:40,630 uninstalling packages, so on and so forth. 42 00:01:40,630 --> 00:01:42,260 You might be thinking that this 43 00:01:42,260 --> 00:01:44,580 PackageManagement PowerShell module is 44 00:01:44,580 --> 00:01:45,980 what we're going to be working with in the 45 00:01:45,980 --> 00:01:48,500 rest of this course, and to that I would 46 00:01:48,500 --> 00:01:51,500 say yes and no, and you'll see why in a 47 00:01:51,500 --> 00:01:53,850 moment. The next piece of this 48 00:01:53,850 --> 00:01:56,030 architectures are the PackageManagement 49 00:01:56,030 --> 00:01:58,630 providers. The PackageManagement core 50 00:01:58,630 --> 00:02:01,090 framework provides an extensible plug‑in 51 00:02:01,090 --> 00:02:03,000 model that allows different installer 52 00:02:03,000 --> 00:02:06,090 platforms to plug into the framework, and 53 00:02:06,090 --> 00:02:08,340 these are known as package providers. 54 00:02:08,340 --> 00:02:10,650 There are a key set of providers that come 55 00:02:10,650 --> 00:02:13,640 in the box with Windows, shown in green, 56 00:02:13,640 --> 00:02:15,430 but there are additional providers that 57 00:02:15,430 --> 00:02:18,160 can be added into this framework. The key 58 00:02:18,160 --> 00:02:20,050 provider I want to point out here at this 59 00:02:20,050 --> 00:02:22,690 point is a default provider named 60 00:02:22,690 --> 00:02:25,410 PowerShellGet. We will speak more about 61 00:02:25,410 --> 00:02:27,790 PowerShellGet in a moment, but this is the 62 00:02:27,790 --> 00:02:29,560 component that we'll mostly be working 63 00:02:29,560 --> 00:02:31,840 with as we move forward in this course. 64 00:02:31,840 --> 00:02:34,390 The final piece of the PackageManagement 65 00:02:34,390 --> 00:02:37,510 architecture are package sources, so the 66 00:02:37,510 --> 00:02:39,090 providers need somewhere to get the 67 00:02:39,090 --> 00:02:41,550 software from that you want to discover 68 00:02:41,550 --> 00:02:43,560 and install on your machine or other 69 00:02:43,560 --> 00:02:45,660 machines in your company, and that's where 70 00:02:45,660 --> 00:02:48,330 the package sources come in. And sometimes 71 00:02:48,330 --> 00:02:51,400 these are referred to as repositories. In 72 00:02:51,400 --> 00:02:53,490 summary here, that's an overview of the 73 00:02:53,490 --> 00:02:56,440 PackageManagement feature within Windows. 74 00:02:56,440 --> 00:02:58,830 Now remember, this framework is used to 75 00:02:58,830 --> 00:03:01,230 manage any software on your machine. As 76 00:03:01,230 --> 00:03:02,950 long as the software is located in one of 77 00:03:02,950 --> 00:03:04,940 the package sources, you can use a 78 00:03:04,940 --> 00:03:07,700 provider to manage that software. When I 79 00:03:07,700 --> 00:03:10,230 say any software, I mean everything from 80 00:03:10,230 --> 00:03:12,590 web browsers to media players to PDF 81 00:03:12,590 --> 00:03:15,480 readers, collaboration tools, you get the 82 00:03:15,480 --> 00:03:18,610 idea. You may be wondering why I'm telling 83 00:03:18,610 --> 00:03:19,990 you about Windows software 84 00:03:19,990 --> 00:03:22,300 PackageManagement in a PowerShell course, 85 00:03:22,300 --> 00:03:24,290 and the reason for that is that this is 86 00:03:24,290 --> 00:03:26,340 the framework that we end up using to 87 00:03:26,340 --> 00:03:28,560 discover and manage PowerShell modules, 88 00:03:28,560 --> 00:03:30,530 which, when you think about it, are just 89 00:03:30,530 --> 00:03:33,070 software packages. A lot of this is 90 00:03:33,070 --> 00:03:35,380 abstracted for us because we use commands 91 00:03:35,380 --> 00:03:37,990 from the PowerShellGet provider, but it is 92 00:03:37,990 --> 00:03:39,970 important to understand how this framework 93 00:03:39,970 --> 00:03:42,380 looks, especially as you move forward and 94 00:03:42,380 --> 00:03:44,170 maybe look at adding and exploring other 95 00:03:44,170 --> 00:03:48,340 providers and sources. PowerShellGet is a 96 00:03:48,340 --> 00:03:50,920 PackageManagement provider, and it's the 97 00:03:50,920 --> 00:03:54,040 package manager for PowerShell packages. 98 00:03:54,040 --> 00:03:56,360 Under the hood, PowerShellGet heavily 99 00:03:56,360 --> 00:03:59,040 leverages the PackageManagement Framework. 100 00:03:59,040 --> 00:04:01,860 Simply put, it's a PowerShell module that 101 00:04:01,860 --> 00:04:03,930 contains commands for managing PowerShell 102 00:04:03,930 --> 00:04:07,120 modules, scripts, and DSC resources, 103 00:04:07,120 --> 00:04:08,800 providing capabilities such as 104 00:04:08,800 --> 00:04:11,670 discovering, installing, updating, and 105 00:04:11,670 --> 00:04:14,810 publishing PowerShell packages. By 106 00:04:14,810 --> 00:04:17,020 default, PowerShellGet connects to the 107 00:04:17,020 --> 00:04:19,080 PowerShell Gallery, which is the most 108 00:04:19,080 --> 00:04:21,140 common and popular public PowerShell 109 00:04:21,140 --> 00:04:23,250 repository, and we'll touch more on 110 00:04:23,250 --> 00:04:26,400 repositories in a moment. PowerShellGet is 111 00:04:26,400 --> 00:04:29,210 an inbox module if you have Windows 10 or 112 00:04:29,210 --> 00:04:32,790 newer, Server 2016 or newer, PowerShell 6 113 00:04:32,790 --> 00:04:35,240 or newer, or the Windows Management 114 00:04:35,240 --> 00:04:38,990 Framework 5.0 or newer. And it requires 115 00:04:38,990 --> 00:04:42,110 PowerShell 3 or later, as well as the .NET 116 00:04:42,110 --> 00:04:46,050 Framework 4.5 or newer. As I mentioned in 117 00:04:46,050 --> 00:04:48,310 passing earlier, the commands inside of 118 00:04:48,310 --> 00:04:50,430 the PowerShellGet module are what we'll be 119 00:04:50,430 --> 00:04:52,110 looking at with the remainder of this 120 00:04:52,110 --> 00:04:55,150 course. A few moments ago on the 121 00:04:55,150 --> 00:04:57,690 PackageManagement architecture overview, 122 00:04:57,690 --> 00:05:00,230 we saw package sources, and in the world 123 00:05:00,230 --> 00:05:02,230 of PowerShell, you'll mostly find these 124 00:05:02,230 --> 00:05:04,840 referred to as PowerShell repositories. 125 00:05:04,840 --> 00:05:06,680 PowerShell repositories are central 126 00:05:06,680 --> 00:05:09,520 locations to share, store, and discover 127 00:05:09,520 --> 00:05:12,500 PowerShell content. As a publisher of 128 00:05:12,500 --> 00:05:14,350 PowerShell modules, you should look to 129 00:05:14,350 --> 00:05:15,850 publish your code to a PowerShell 130 00:05:15,850 --> 00:05:18,180 repository, and as a consumer of 131 00:05:18,180 --> 00:05:21,030 PowerShell, a repository is where you'd go 132 00:05:21,030 --> 00:05:23,570 to discover and install modules. You can 133 00:05:23,570 --> 00:05:26,000 use the commands in a PowerShellGet module 134 00:05:26,000 --> 00:05:29,150 to discover, install, update, and publish 135 00:05:29,150 --> 00:05:31,480 code to and from any PowerShell 136 00:05:31,480 --> 00:05:34,640 repository. Repositories can be public or 137 00:05:34,640 --> 00:05:37,290 private. In the demo, I will quickly show 138 00:05:37,290 --> 00:05:39,060 you an example of creating a private 139 00:05:39,060 --> 00:05:42,040 repository based on a Windows file share. 140 00:05:42,040 --> 00:05:43,970 You may want to explore the use of private 141 00:05:43,970 --> 00:05:46,110 repositories if you or your company 142 00:05:46,110 --> 00:05:48,400 creates PowerShell content that you don't 143 00:05:48,400 --> 00:05:50,940 want to publish on a public repository. 144 00:05:50,940 --> 00:05:53,140 I've also seen examples of where security 145 00:05:53,140 --> 00:05:55,310 teams within a company like to review 146 00:05:55,310 --> 00:05:57,780 PowerShell content before users install it 147 00:05:57,780 --> 00:06:00,290 on their machines, so they block access to 148 00:06:00,290 --> 00:06:02,610 public repositories and set up a private 149 00:06:02,610 --> 00:06:05,130 repository. The security team is then 150 00:06:05,130 --> 00:06:07,540 responsible for reviewing packages from a 151 00:06:07,540 --> 00:06:09,390 public repository and making them 152 00:06:09,390 --> 00:06:11,860 available to internal users via that 153 00:06:11,860 --> 00:06:15,180 private repository. By far, the PowerShell 154 00:06:15,180 --> 00:06:17,000 Gallery is the widest used public 155 00:06:17,000 --> 00:06:19,740 repository, and it is also configured as 156 00:06:19,740 --> 00:06:22,120 the default public repository. The 157 00:06:22,120 --> 00:06:23,870 PowerShell Gallery is provided by 158 00:06:23,870 --> 00:06:26,410 Microsoft, and you'll see in the demos 159 00:06:26,410 --> 00:06:28,160 without having to configure anything at 160 00:06:28,160 --> 00:06:30,040 all, we can start searching through the 161 00:06:30,040 --> 00:06:33,040 PowerShell Gallery for PowerShell modules. 162 00:06:33,040 --> 00:06:34,900 But Matt, what does this actually look 163 00:06:34,900 --> 00:06:37,180 like when it's all put together? Well, I'm 164 00:06:37,180 --> 00:06:39,940 glad you asked. Let's conceptualize this 165 00:06:39,940 --> 00:06:42,350 at Globomantics, and we'll start with the 166 00:06:42,350 --> 00:06:44,370 PowerShell Gallery, which is that public 167 00:06:44,370 --> 00:06:46,170 repository, and it's configured by 168 00:06:46,170 --> 00:06:49,170 default. Jill is also wanting to set up a 169 00:06:49,170 --> 00:06:51,530 private repository, just a file share to 170 00:06:51,530 --> 00:06:53,660 get things going and to start testing out 171 00:06:53,660 --> 00:06:55,310 how to use and manage a private 172 00:06:55,310 --> 00:06:58,850 repository. Nothing too fancy. Jill has 173 00:06:58,850 --> 00:07:00,670 her computer, which is a Windows 10 174 00:07:00,670 --> 00:07:03,010 desktop machine, and she now needs to 175 00:07:03,010 --> 00:07:05,200 integrate with these repositories to find 176 00:07:05,200 --> 00:07:07,490 and install modules. And that's exactly 177 00:07:07,490 --> 00:07:10,240 where the PowerShellGet module comes in. 178 00:07:10,240 --> 00:07:12,260 This module includes commands like 179 00:07:12,260 --> 00:07:14,500 Find‑Module, Install‑Module, 180 00:07:14,500 --> 00:07:16,980 Update‑Module, et cetera, and we'll get 181 00:07:16,980 --> 00:07:18,370 into a heap of those in the next few 182 00:07:18,370 --> 00:07:21,210 clips. Jill can leverage these commands to 183 00:07:21,210 --> 00:07:23,160 search the PowerShell Gallery and then 184 00:07:23,160 --> 00:07:25,230 install modules locally on her machine 185 00:07:25,230 --> 00:07:27,710 directly from the gallery. Because the 186 00:07:27,710 --> 00:07:29,600 PowerShellGet module is built on top of 187 00:07:29,600 --> 00:07:31,920 the PackageManagement Framework, those 188 00:07:31,920 --> 00:07:34,690 exact same commands can be used by Jill to 189 00:07:34,690 --> 00:07:37,140 look inside the private repository and 190 00:07:37,140 --> 00:07:39,480 install PowerShell modules on her machine 191 00:07:39,480 --> 00:07:41,260 directly from the private repository as 192 00:07:41,260 --> 00:07:44,280 well. Moving forward in this course, apart 193 00:07:44,280 --> 00:07:46,340 from creating a private repository just to 194 00:07:46,340 --> 00:07:48,070 show you what that looks like, we'll be 195 00:07:48,070 --> 00:07:49,910 doing all tasks with the PowerShell 196 00:07:49,910 --> 00:07:52,390 Gallery. But the nice thing is that when 197 00:07:52,390 --> 00:07:53,580 you've learned the commands and the 198 00:07:53,580 --> 00:07:56,440 workflow of how to manage modules once, it 199 00:07:56,440 --> 00:07:58,470 doesn't matter which repository or how 200 00:07:58,470 --> 00:08:00,190 many repositories you need to work with 201 00:08:00,190 --> 00:08:05,000 moving forward, as the processing commands will be exactly the same.