- Interact with Azure Cosmos DB with PowerShell - Tue, Sep 14 2021
- Azure health services: Track Microsoft cloud outages and maintenance - Wed, Sep 8 2021
- Powerline: Customize your PowerShell console - Tue, Aug 31 2021
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:
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 Name ---- Find-Package Get-Package Get-PackageProvider Get-PackageSource Install-Package Register-PackageSource Save-Package Set-PackageSource Uninstall-Package Unregister-PackageSource
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 v188.8.131.52' is not installed. 'nuget' may be manually downloaded from 'https://oneget.org/nuget-anycpu-184.108.40.206.exe' and copied to 'C:\Program Files\OneGet\ProviderAssemblies'. 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 9.22.01.2... 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:
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 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”
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:
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