After last weeks story, hopefully youve got your problem users accounts identified. With that worked out, lets see about finding problem applications.
We all need a handle on what applications are installed on workstations for a number of reasons
- to make sure that when upgrade time comes, that nobody gets left behind
- that older apps that have security vulnerabilities or have limited function get taken care of - old versions of putty or Java for instance
- that users dont install applications that the organization hasnt paid for
- and finally, its a decent shot at finding installed malware that your AV product might have missed.
First, lets look at the powershell command to list installed software. This is a rough equivalent of control panel / programs, or wmic product list">Get-WmiObject -Class Win32_Product -computername
If you run this, youll see that this is *really* verbose (I wont show the output), and the list view is not so useful. Let">Get-WmiObject -Class Win32_Product -computername . | select vendor, name, version | format-table
or, to make the display more useful, replace format-table with out-gridview or output-csv" />
But that just gives us programs that use the Microsoft installer process to install (msis and similar packages). How about single exe type apps, things like putty.exe, sed.exe and so on?">Name : sed.exe
Length : 186880
CreationTime : 9/4/2012 1:33:52 PM
LastWriteTime : 3/31/2009 3:32:34 PM
LastAccessTime : 9/4/2012 1:33:52 PM
VersionInfo : File: C:sed.exe
InternalName: sed
OriginalFilename: sed
FileVersion: 10.0.7063.0
FileDescription: SUA Utility
Product: Microsoftr Windowsr Oper
ProductVersion: 10.0.7063.0
Debug: False
Patched: False
PreRelease: False
PrivateBuild: True
SpecialBuild: False
Language:">
But we want a table view, and again just a few of those fields. The name, the original name (to account for users renaming EXE files), the file and application versions, and maybe the publisher. Some of these are a bit tricky to get, as theyre lower down in the heirarchy of the object, but it">get-childitem ssh.exe | format-list name,creationtime,lastwritetime,@{label=ProductVersionexpression={$_.versioninfo.productversion}},@{label=FileVersionexpression={$_.versioninfo.fileversion}},@{label=Original FileName">Name : ssh.exe
CreationTime : 5/30/2011 4:50:57 PM
LastWriteTime : 8/6/2013 6:12:44 PM
ProductVersion : Release 0.63
FileVersion">
OOOPS - looks like Im a rev back on putty!">">">Name : excel.exe
Length : 20400288
CreationTime : 5/22/2015 7:11:54 PM
LastWriteTime : 5/22/2015 7:11:54 PM
LastAccessTime : 6/11/2015 3:58:19 PM
VersionInfo : File: C:Program Files (x86)Microsoft
OfficeOffice14excel.exe
InternalName: Excel
OriginalFilename: Excel.exe
FileVersion: 14.0.7151.5001
FileDescription: Microsoft Excel
Product: Microsoft Office 2010
ProductVersion: 14.0.7151.5001
Debug: False
Patched: False
PreRelease: False
PrivateBuild: False
SpecialBuild: False
Language: Language Neutral
Great, you say, how is inventorying things one file at a time useful? Lets use get-childitem recursively and pull all the EXEs in one shot. This is a reasonable way to grab everything. With that in a spreadsheet or database, you">get-childitem c:*.exe -recurse | format-table name,creationtime,lastwritetime,@{label=ProductVersionexpression={$_.versioninfo.productversion}},@{label=FileVersionexpression={$_.versioninfo.fileversion}},@{label=Original FileNameexpression={$_.versioninfo.originalfilename}},@{label=Product">$Path | Select-Object `
@{n=Namee={$Filename}},`
@{n=FilePathe={$Item}},`
@{n=Original Namee={$originalname}},`
@{n=Createde={$Age}},`
@{n=Product Vere={$product}},`
@{n=File Vere={$filever}}`
}| Export-Csv d:sansResults.csv -NoTypeInformation
" />
Note that not all values are populated in the metadata for every file - thats just the way it is when youre processing standalone files like this.
Using this approach, you can see that with maybe an afternoon of scripting effort, you can set up a system that you might otherwise pay thousands or tens of thousands of dollars for - assuming that youre OK running your software inventory system from the CLI. For me, running my inventory from the CLI would be prefered, but I guess you figured that out !
Have you found a trick to process information like this more efficiently? Got a better script to collect this info more simply? Please, share using our comment form!
===============
Rob VandenBrink
Metafore