PowerShell can ID installed software, application services, and scheduled tasks, which can help with planning and management.
Being able to quickly identify what software is installed on your servers has value for a host of reasons. Managing software licensing costs and entitlements, planning upgrade budgets, identifying candidates for server consolidation, or even responding to security incidents are all common reasons for performing a software inventory.
There are of course enterprise tools for tracking software inventory. But these tools can be expensive and complex, or could have access limited to specific groups or individuals in your organization. Fortunately PowerShell can help with some of the leg work in analyzing the software on your systems in order to help drive your planning and incident response.
Sometimes you also need to take things further than simply listing installed software. Acquiring details on things like services or startup apps, file shares, or even open ports can be important to fully answering your business questions.
Identifying installed software
In theory retrieving a list of installed software is a straightforward proposition. Using the Get-WmiObject cmdlet to query the Win32_Product class does produce a list of installed software, but in many cases you’ll find this list to be incomplete. A better alternative is the Get-Package cmdlet, which offers several handy capabilities.
Running Get-Package with no parameters will return a list of installed software including Windows updates, which is likely more detail than you’re after. To focus just on installed applications you’ll want to exclude packages based on the MSU (Microsoft Update) provider type by using Get-Package -ProviderName Programs, MSI. Get-Package gives you the software name and version by default, as well as a couple other fields you probably don’t care about, with additional fields hidden by default. Other key fields you may care about include the FullPath property, denoting where the application is installed, and the FromTrustedSource flag, which indicates whether the software was installed from a software repository that is trusted by the enterprise.
There are a few useful bits of data that aren’t easily available using Get-Package, but they are sometimes accessible if you are willing to dig below the surface a little bit. The SwidTagText property contains XML data which includes information like a help telephone number for the software, a reference URL, and even the install date. Accessing these attributes requires a little bit of gymnastics, but here’s how you can make it work: