Those of you familiar with Linux administration have probably become accustomed to managing the software on your endpoints via the command line through the use of package managers such as APT and YUM. Windows has long lacked this capability which has caused many administrators to turn to third party solutions such as Chocolatey. However, with the release of PowerShell 5.0, Microsoft aimed to resolve this long-standing lack of functionality through stark improvements to the package management capabilities within PowerShell. Specifically, via the addition of the PackageManagement Module.
What is a package manager?
Before we get into the PowerShell-specific implementation, let’s dive into what exactly a package manager is and how it is beneficial to administrators. A package manager is a set of software tools that provide a central interface for installing, configuring, removing, and upgrading software in a consistent manner. Many times this is facilitated through a command line interface which allows administrators to programmatically manage installations. This vastly increases an administrators ability to automate any package management needs within their environment, potentially saving multiple hours in the workday.
The PackageManagement module
As mentioned, the PackageManagement module is Microsoft’s implementation of a package manager. With it, you can easily manage a variety of different installations through the use of providers. Each provider affords the administrator with additional functionality for management of other types of installations. Out of the box providers include:
- Msi - Provides the ability to manage MSI installations present on the endpoint
- Msu - Provides the ability to manage Windows Updates present on the endpoint
- PowerShellGet - Repository used for management of PowerShell modules
- Programs - Provides the ability to inventory applications listed in Add Remove Programs
In addition, the NuGet gallery can be added to provide access to over 136,000 unique packages. The first time you use the Find-Package cmdlet, you will be prompted with the option to install nuget:
What else can you do with the PackageManagement module? Well, let’s take a look at the cmdlets that ship with the module. You can do this easily by using the Get-Command cmdlet:
You will notice that much of the cmdlet use is pretty self-explanatory, but let’s see some of them in action.
Managing MSI installations
In previous installments, we talked about ways to manage MSI installations on multiple occasions. Assuming PowerShell 5.0 is on your endpoint, you can also accomplish this using our new cmdlets. For example, let’s install Orca on our endpoint, verify that it’s present, and then uninstall it:
Now, keep in mind that we did a whole blog post on this a while back. With PowerShell 5.0 and the PackageManagement module, we managed to go over the same operations in one paragraph and three lines of code.
New package installation
But, MSI installations still require the installation file, so how is it possible to install packages directly from PowerShell without having to worry about distributing a file? That’s where the NuGet repository comes in. You will remember that we were asked to install the provider earlier on, however, you may have noticed in the results of the Find-Package cmdlet that no NuGet packages were returned. This is because we still need to configure the package source for NuGet (see below). You can also install the Chocolatey provider for access to additional packages.
Now, you will be able to see packages offered by your preferred provider. We will be using the Find-Package cmdlet again, only this time we will be filtering on the source. It’s important to note that both Chocolatey and NuGet have extensive libraries. Because of this, you will want to filter with an additional parameter such as Name. Once you find your desired package, you can then install it using the Install-Package cmdlet:
But be careful with package management
In theory, you could consider the PackageManagement module to be the package manager of package managers. As seen in the examples above, we added NuGet and Chocolatey as providers and package sources. Both are package management solutions in their own right. One thing I noticed while playing around with these is that certain errors generated by Chocolatey were not properly reported up to the package management module. So, while it seemed my package had installed successfully, it was nowhere to be seen. It took a bit of digging to figure out what exactly was causing these problems.
Execution policy
The first was user error on my part. I had just spun up a new VM to test all this in and forgot to set the PowerShell execution policy to unrestricted in order to allow execution of the PowerShell scripts needed in order for proper functionality. Note - you should not just set the Execution Policy to unrestricted for all of your endpoints because this poses a potential vulnerability. I tend to do it for lab VMs that I destroy right after.
So, what were the effects? Well, when I ran the Install-PackageProvider for Chocolatey it failed to install the modules necessary for Chocolatey package management. As such, no Chocolatey installations were functional.
Community sourced repositories
The second issue occurred when I tried to install specific packages which were not properly maintained or configured. Since these packages are community sourced there is not a guarantee that they will be completely functional. In this example, I attempted to install a Google Chrome package which references a URL for downloading the MSI installer. Unfortunately, the version that was being installed was somewhat older and the MSI installer located at the URL was no longer available. Again, no error was reported from the package management module and the installation seemed to have functioned correctly. However, when I tried to access the application it was nowhere to be found.
Wait, there's more
You may have also noticed that anytime we attempted to install an application we were prompted with a message that stated “The package comes from a package source that is not marked as trusted. Do you still want to install software?” You can get rid of this message by using the Set-PackageSource cmdlet to set the respective source as trusted.
However, this is not recommended because there is no guarantee that the packages you are referencing can be trusted. It is instead recommended that you set up your own package source which you can populate with trusted packages and reference in your environment.
Automox for Easy IT Operations
Automox is the cloud-native IT operations platform for modern organizations. It makes it easy to keep every endpoint automatically configured, patched, and secured – anywhere in the world. With the push of a button, IT admins can fix critical vulnerabilities faster, slash cost and complexity, and win back hours in their day.
Grab your free trial of Automox and join thousands of companies transforming IT operations into a strategic business driver.
