This content is part of the Essential Guide: The go-to Windows PowerShell guide

Navigate a maze of installers with PackageManagement

PackageManagement -- formerly OneGet -- lets desktop admins use PowerShell cmdlets to work with several different installer technologies.

In Windows 10, Microsoft introduced PackageManagement, a systems aggregator based on PowerShell 5 that lets you work with multiple installer technologies through a common set of PowerShell cmdlets. PackageManagement -- formerly known as OneGet -- uses installers to find, install, uninstall and maintain software.

PackageManagement cmdlets are part of the PackageManagement module included in PowerShell 5. You can also get PowerShell 5 and PackageManagement through Windows Management Framework 5.0 RTM. In addition, Microsoft released the PackageManagement Preview for PowerShell versions 3 and 4. These last two options let you run PackageManagement on Windows operating systems other than Windows 10.

Inside PackageManagement

Windows desktop administrators often use multiple installer technologies to manage software. This can include basic installers such as MSI and MSU, as well as package management products such as NuGet and Chocolatey. Managing multiple technologies can complicate the software deployment, automation, management and update processes.

PackageManagement promises to ease this burden. In addition to the PowerShell cmdlets, PackageManagement includes a core component that coordinates discovery, inventory, installation and uninstallation operations. The component also provides the APIs necessary to facilitate communication between the PackageManagement cmdlets and the providers needed to connect to package sources.

Providers make it possible to access various sources of software packages. Each provider serves as a bridge between the core and one or more sources. For example, PackageManagement includes the PowerShellGet provider to access Microsoft's PowerShell Gallery, a central repository that contains PowerShell commands and Desired State Configuration resources. A source can be any supported repository of software packages, whether it's local or remote.

PackageManagement includes four providers out of the box:

  • The MSI provider allows access to local .msi package files.
  • The MSU provider grants access to local available Microsoft update files.
  • The Programs provider allows access to local software registered through Windows Add/Remove Programs, but only for the purposes of inventorying it.
  • The PowerShellGet provider gives you access to the PowerShell Gallery.

In addition to the four built-in providers, PackageManagement includes a bootstrap provider for accessing other provider types, such as NuGet, Chocolatey and GistProvider.

PackageManagement cmdlets

The PackageManagement module currently provides 13 cmdlets for retrieving package information and managing those packages. For example, you can use the Get-Package cmdlet to retrieve information about software based on MSI installer technology, as shown in the following PowerShell command:

get-package -providername msi

For each MSI program, the command returns the application name, version and source folder. You can also retrieve a list of available providers by using the Get-PackageProvider cmdlet:

get-packageprovider –listavailable

The -listavailable argument instructs the command to return a list of all locally installed providers, not just those running in the current session. At a minimum, the command always returns the four default providers because they are installed and available by default.

To view a list of currently configured sources, you can use the Get-PackageSource cmdlet, which can retrieve all sources, or only the sources available to a specific provider. For example, the following command returns a list of sources available through the PowerShellGet provider:

get-packagesource -providername PowerShellGet

By default, the command returns only one source, PSGallery, which is the PowerShell gallery. You can add providers to PackageManagement and add sources for each. Before you add a provider, you might want to use the Find-PackageProvider cmdlet to determine which providers are available to install on your local system. Initially, you can run the cmdlet without specifying any arguments. For each provider, the cmdlet will return the provider name, version, source and summary description.

The first time you run a Find-PackageProvider command, you'll receive a message saying that the NuGet provider is not installed. The provider must be installed to carry out many of the PackageManagement operations. To install the provider, click Yes in the message box. PackageManagement takes care of the rest.

From there, you can use the Install-PackageProvider cmdlet to add one of the available providers to your system. For example, when you run the Find-PackageProvider cmdlet, one of the returned providers is Chocolatey. If you decide to install this provider on your system, you can use the following command:

install-packageprovider -name chocolatey -scope currentuser

You may or may not need to include the -scope argument, depending on how you launched PowerShell and what level of permissions you have. If you run the command without the argument and receive an access error, you'll likely need to include the argument. If you launch PowerShell as an administrator, you should not need to include the -scope argument.

After you run the command, you will be prompted to trust the provider. Click Yes to confirm the trust and complete the installation. The next step after installing the Chocolatey provider is to use the Import-PackageProvider cmdlet to add the provider to your current session:

import-packageprovider -name chocolatey

Once the provider has been imported, you can use the Register-PackageSource cmdlet to add a Chocolatey-based source as a repository. When calling the cmdlet, you must specify a name for the source, the provider name and the URL pointing to the repository:

Register-PackageSource -name choc2 -providername chocolatey -location -trusted

Notice that the name assigned to the source is choc2 and that the command includes the -trusted argument, which tells PowerShell to run the command without prompting you for confirmation. You can then use the Find-Package cmdlet to return a list of packages available through the choc2 source:

find-package -provider chocolatey -source choc2

If you run this command, you'll quickly discover there are hundreds of packages available through this source. For this reason, you'll usually want to narrow your search. For example, the following command returns only packages related to Notepad2:

find-package -provider chocolatey -source choc2 -name notepad2

In this case, the command returns a single listing for the Notepad2 package, version If you want to install this package, you can simply pipe the preceding command to the Install-Package cmdlet:

find-package -provider chocolatey -source choc2 -name notepad2 | install-package

That's all there is to using PackageManagement to install a package. You can follow the same procedure for installing packages from other source types. Be aware, however, that to install a package, PowerShell's execution policy must be set to Remote Signed or Unrestricted. Otherwise, the package will be copied to the local system, but the application itself will not be installed.

Next Steps

PowerShell basics for newbies

What is Red Hat Package Manager?

Comparing PowerCLI and PowerShell

Dig Deeper on Windows 10