Many years ago when PowerShell was first in beta, I saw an opportunity to write cmdlets that I could string together in different ways rather than writing and maintaining a bunch of one-off Windows scripts for various day-to-day tasks and customer diagnostics. I created the Windows Installer PowerShell Module to fill that role. These cmdlets are now used heavily in many tasks internally and, I hope, in the wild.
Fast-forward to today – with the release of the Windows Management Framework 5.0, which includes PowerShell and a host of other great administrative features – you can get new versions of the module even easier and in more configurations, such as installing on remote machines so you can call them remotely.
install-package MSI –provider powershellget
get-msiproductinfo
Passing the provider name is actually optional – making the command even easier to remember – but helps avoid any confusion which package to install because the PackageManagement module (OneGet) can list and install/uninstall packages from many different providers, including Add and Remove Programs (ARP) itself.
To install them on remote machines (since the Windows Installer APIs the cmdlets call are not themselves remotable), you can use either sessions (an older feature but still the basis of many other features) or DSC resources (a newer feature in WMF). Using a session, for example:
$session = new-pssession myserver
invoke-command -script { install-package msi -provider powershellget } -session $session
$products = invoke-command -script { get-msiproductinfo } -session $session
remove-pssession $session
I initially published the module to the PowerShell gallery to help test PowerShellGet and have made several improvements in recent times. To facilitate a faster feedback loop and publishing of binaries, I also moved the project to GitHub and set up continuous deployment with AppVeyor. To file feedback, please create a new issue.