Windows PowerShell 5.0 includes support for a Windows package manager. The relevant built-in module, OneGet, supports the community repository Chocolatey. By the time you finish this blog post, you’ll have a solid, if preliminary, understanding of how this new Windows package manager works.
Latest posts by Timothy Warner (see all)

Have you worked with software package managers yet? If you are strictly a Windows professional, the answer is probably “no.” However, if you use UNIX, Linux, or Apple OS X to any degree, you’ve most likely installed software from the command line using one of the following package managers:

  • apt (Advanced Package Tool)
  • rpm (RPM Package Manager)
  • homebrew (OS X add-on)

In the *Nix world, repositories (also called repos) are web-based storage locations that make source code-compiled software packages available to users. One of the cool things about package manager software is that it automates frustrating tasks, such as resolving software package dependencies, upgrading to newer versions, and, of course, uninstalling applications.

Preparing the environment

Your first step is to download and install the latest build of Windows Management Framework (WMF) 5.0 Preview from the Microsoft Download Center. As you probably know, the Microsoft PowerShell development team makes preview builds available to us periodically by releasing pre-release WMF versions.

Windows 10 Technical Preview also has Windows PowerShell 5.0 built in, as you’d expect. You should also be aware that only Windows 8.1, Windows Server 2012 R2, and Windows 10 client and server support Windows PowerShell 5.0 in the first place.

Next, fire up an elevated Windows PowerShell console session and verify that you are indeed running 5.0:

PS C:\> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
5      0      9883   0

All the relevant package management commands are contained in the OneGet module; let’s enumerate these commands now by running Get-Command:

PS C:\> Get-Command -Module OneGet | Select name


Not too many commands to learn, right? That’s cool. A repository, as I said earlier, is an online source for available software packages. The person or persons running the repository decide what software to include, how many versions to maintain, and so on.

If you’re a security-minded IT professional, you’re probably thinking, “Should I really trust that the software packages hosted by a given repo are legitimate?” Microsoft’s PowerShell team, if you listen to the talks, tries to temper our concerns by promoting a particular community repository named Chocolatey—more on that in a moment.

For now, let’s run Find-Package just to see what packages are available to us by default:

PS C:\> find-package

The provider 'nuget v2.8.3.6' is not installed.
'nuget' may be manually downloaded from
'' and copied to 'C:\Program
Would you like OneGet to automatically download and install 'nuget' now?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):

What in the world? What’s “nuget”?! Let me break it down for you: NuGet (pronounced like the confection “nougat”) is the “bare metal” package development engine that underlies the Windows PowerShell OneGet module. NuGet works hand-in-glove with the Chocolatey provider, which is defined as a sort of “apt-get for Windows,” if you understand the reference. All you need to know is that Chocolatey is both the IT pro-facing Windows package manager and our default software package provider.

By the way, YES, these terms are confusing! It’s not just you.

Meanwhile, if we run Get-PackageSource:

PS C:\> get-packagesource

Name                 ProviderName     IsTrusted  IsRegistered IsValidated
----                 ------------     ---------  ------------ -----------
PSGallery            PSModule         False      True         False
MSPSGallery          PSModule         True       True         False
chocolatey           Chocolatey       False      True         False

We can see that Windows PowerShell installed not only the Chocolatey repository but also providers called “PSGallery” and “MSPSGallery.” Remember that OneGet is part of a pre-release Windows PowerShell version, so documentation on a lot of this (including the default PSGallery and MSPSGallery package sources) is scant at best, non-existent at worst. For instance, I was bummed to receive largely empty help files when I tried to get help on OneGet commands:

Get-Help Get-PackageProvider –ShowWindow

Locating and installing a package

As an experiment, we’ll locate a small piece of software and install it on our test Windows 8.1 system.

Just for grins, we can use Find-Package and Measure-Object to find out how many packages are visible to us right now in the Chocolatey repo:

PS C:\> Find-Package | Measure-Object

Count    : 2481

Gee, I wonder if Chocolatey has the nifty 7-Zip archive manager tool in its repository. Yep:

PS C:\> find-package -Name 7zip

Name      Version      Status       ProviderName     Source           Summary
----      -------      ------       ------------     ------           -------
7zip Available    Chocolatey       chocolatey       7-Zip ...

Deep breath—I choose to trust the software stored at the Chocolatey gallery, so I can now invoke Install-Package to install the software with no muss, fuss, or greasy aftertaste:

Find-name example

Who would have thought we’d be installing software from the command line in Windows?

I want you to look at the previous screenshot and pay particular attention to the yellow highlighted text. We get this error if the package source is not marked as trusted. I added the -Confirm switch parameter just to give myself a quick “sanity check” before proceeding with the software installation. At the end of this article, I’ll teach you how to formally mark a repository as “Trusted” so you don’t get additional prompts during installation.

The following image confirms that 7-Zip has been successfully installed on my computer:

Installing software from PowerShell

Installing software from Windows PowerShell means that we don’t have to be held captive by poorly designed graphical installation routines.

Here’s a nice PowerShell one-liner that gives you an alphabetized list of all available software from your active repositories:

Find-Package | Sort-Object –Property Name | Out-GridView

I show you what my output looks like in the following screenshot. Note that you can’t save any data from the GridView. If you need this data in, say, CSV format, use Export-Csv:

Find-Package | Sort-Object- Property Name | Export-Csv –Path C:\”available_software.csv”

View and export output

As you know, Windows PowerShell has myriad ways in which you can view and export output.

We know that one of PowerShell’s great strengths is multitasking and automation. To that point, the -Name parameter of Install-Package accepts an array of package names. Thus, you can run the following to install three packages simultaneously:

Install-Package –Name skype, jing, git

Managing your installed software

If you run Get-Package thinking you’ll see only the software you installed through OneGet, you’ll be sorely disappointed because this command returns all software installed on your computer. It’s essentially a command-line representation of the Programs and Features Control Panel item.

Instead, you can supply all or part of the target package name in your code:

PS C:\> get-package -name vim | format-table -AutoSize

Name        Version Status    ProviderName Source
----        ------- ------    ------------ ------
vim         7.4.493 Installed Chocolatey   C:\Choc..
Vim         7.4.493 Installed ARP

As you can see above, I used OneGet to install the vim editor. Now, I’ll attempt an uninstallation by using the Windows PowerShell pipeline and the Uninstall-Package cmdlet. You can see this process taking place in the following screenshot:

Uninstalling a package with get-package

I don’t have a good reason as to why my run of Uninstall-Package invoked the GUI routine from the source app. Can you please ask Jeffrey Snover this question for me?

Weird, huh? I didn’t expect to see the source software’s graphical installation routine when I attempted a command-line uninstallation. Once again, we need to remember that we’re dealing with experimental, pre-release code here.

Managing your package providers

Because the Chocolatey default repository is untrusted by default, we have to use Set-PackageSource to flip the trust switch:

PS C:\> Set-PackageSource -Name chocolatey -Trusted

Name           ProviderName     IsTrusted  IsRegistered   IsValidated
----           ------------     ---------  ------------   -----------
chocolatey     Chocolatey       True       True           True

From what I’ve gathered from Windows PowerShell inventor Jeffrey Snover’s talks on the subject, the PowerShell OneGet framework will support the ability of IT administrators to stand up their own internal package providers for internal use. This way, you definitely have the trust factor because you’re populating the package repository with your hand-selected software packages.

Of course, if you decide later that you no longer want to use a particular package repository, you can use Unregister-PackageSource to do just that:

Unregister-PackageSource –name Chocolatey
  1. Garrett Serack 9 years ago

    >> I don’t have a good reason as to why my run of Uninstall-Package invoked the GUI routine from the source app. Can you please ask Jeffrey Snover this question for me?

    You’re seeing a common failing with Chocolatey packages.

    The VIM Chocolatey package downloads and runs the EXE Installer for VIM. The VIM Chocolatey package doesn’t contain the instructions to actually *uninstall* the EXE that it ran.

    Since OneGet isn’t a Package management systes per se, but rather a package management system aggregator, what you’re actually seeing is both the Chocolatey package (reported byt he chocolatey provider) and the EXE installer (which was recorded in Add/Remove Programs [ aka ‘ARP’]).

    The ARP provider is literally pulling out the uninstall command and executing it, which at this point is popping up the GUI for the actual uninstaller.

    In the next few months, we’ll be cleaning up some of the rough edges, and hopefully we’ll be entirely UI-free for stuff like that.

    By the way, If you want to have your own repository, you can do this in one of two ways, right now.

    By putting the packages (.nupkg) into a share and creating a package source for that (ie, register-packagesource -provider chocolatey -name myrepo -location \\server\share\repo ) you can create ad-hoc package repos.

    The second way, is to download ‘proget’ — and host a package repository on your own (see )… you can add packages to that server and it works fine for chocolatey.

  2. Author

    Garrett, thanks so much for sharing your thoughts here. You added a lot of value to my original article. Kindest regards, Tim

  3. Garrett Serack 9 years ago

    Hey no problem Tim,

    OneGet is different from every other Windows feature out there, since not only is it being built from the ground up as Open Source software, but because anyone can try literally any build I publish, I can get instantaneous feedback as to where we might be a bit weak.

    And, I hear you — the help is needed badly (got someone on that right now!) and we’re going to need to look at determining if we can connect unspecified dependencies so that you can just uninstall a primary package and dependencies go along with it.

    Keep up the good work!


  4. Author

    Garrett, if you need help with documentation, I’m willing! Thanks!

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account