Three PowerShell queries to obtain critical system information

When it comes to getting information about Windows clients and servers, administrators are sometimes left in the dark. These simple scripts will help you gather succinct info about a computing environment.

There is nothing worse than being given a system requirement and not knowing whether it can be applied to a number of systems. There are countless examples, such as free space on local computers or what levels of JAVA or .NET framework are installed. Sometimes, we may be given more difficult requirements that we may or may not be able to easily determine.

Here are three scripts you can use to get detailed information for specific questions about Windows clients and servers. The scripts are based on PowerShell 2, which can be applied to Windows XP and higher on the client side as well as on Windows Server 2003 and higher on the server editions. For PowerShell 2, it is recommended that you install the Windows PowerShell PowerPack.

Note: This article is also available as a PDF download.

#1: Determine primary screen resolution

When a software package requires a certain resolution or minimum resolution, you can query the local computer to return the resolution of the primary monitor. Multiple monitors are not reported in this command. The code to perform this task is the simple one-liner Get-DisplaySetting, shown in Figure A.

Figure A

This PowerPack command does not (currently) support execution against a remote computer, which is the biggest limitation to its usage for a broad-reaching inventory. In this case, you could couple the installation of the PowerPack with a Group Policy software installation package and run it locally to report the results for a number of systems. Couple the command with a variable to determine the computer's name and export it to a local (or central file):

$NetBIOSName = gc env:computername
Get-DisplaySetting > C:\$NetBIOSName.txt

#2: Enumerate USB devices

Determining what USB devices are in use on a system can be tough. Administrators bemoan the day that PC makers replaced PS/2 interfaces for keyboard and mice with USB ports. This is simply because it is easier to make a generic USB device policy, and PS/2 input devices would function fine outside that policy. The Get-USB PowerShell module will enumerate the devices currently attached to the USB interfaces of a server or workstation. A sample output is shown in Figure B.

Figure B

In this example, the caption section has the string "Blue Snowball" listed as the connected USB device. This is a microphone, and for organizations wanting to restrict the device types for systems, this can inventory what USB devices are attached to the system. Likewise, if a USB Mass Storage device is enumerated in the list, this can roll into the auditing of a policy that may or may not be enforced.

Unlike the previous command, you can run this command against remote systems natively. Running the command with the -computername variable will connect the command to a remote system and return the same results as if it were executing locally. This doesn't require PowerShell PowerPack to be installed when executing remotely, which is handy. The command would execute as shown below:

Get-USB -Computername System.FullyQualified.Domain

#3: Retrieve detailed processor information

The current inventory of processors for servers, workstations, and virtual machines can be mind-boggling. The Get-Processor PowerShell command can help centralize this information for quick information on how many cores or CPUs are available to a system. The Get-Processor command is shown in Figure C.

Figure C

In this example, you can see how the virtual machine in this case is provisioned with one CPU with core including the model and frequency. If the -Computer parameter is omitted; it will return the local results. Different processor configurations will return different values and information comparable to old-school tools like CPUID.

Tools for the arsenal

These PowerShell scripts are a key way for administrators to gather succinct information about the computing environment. What other PowerShell tools have you used for inventory functions? Share your comments below.


Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.


WIN 7 Home Premium - and I'm not that well-versed with Powershell, but none of the three cmdlets above appear to be in my version of Powershell. Am I missing something? (get-help get-* showed the whole list of get-cmdlets and none of the referenced ones appear in my list).


Good tips, can't wait to try 'em out. You mention checking versions of java, .net and I assume applications could be checked. Can you give an example of how you would check what level of java and .net are installed? Visually checking what ver of java is deployed is a matter of security. You never know if some machine is/has been having problems updating, for instance. I saw this happen more than once, something was broken with java updates and a machine would get stuck on an older ver. Obviously a risk. But more important I have a project right now that requires .net 2.0 or later. (the dev says he would prefer 2.0 specifically, for whatever reason...) These systems haven't required .net until now, so the versions are all over the place. (it hasn't been included in any updates heretofore) I know several of them have 1.0. :\ I plan on basically bothering every employee one by one, sitting down at their computer for a couple minutes, firing up add/remove programs and write down the version info from there. It would be great if I could sit at one less-used machine in a back office and access this information across the network via the shell. Possible? Anyone know how to do this? Can it be done remotely? Thanks, Rick. I'm not as familiar with a windows shell as I should be. Slow day today (so far) so I'll scroogle up some powershell tutorials.


The last line of the second paragraph shouldn't say the PowerShell PowerPack is *recommended*, it should say 'The features discussed in this article are ONLY available if you install the PowerShell PowerPack." Once I downloaded and installed the PowerPack then these commands were available. I did get several error messages when I ran the command 'Import-Module PowerShellPack', but the get-processor and get-usb commands seemed to work properly anyways.


...issuing WMI calls via VBScript/CScript can retrieve Add or Remove Program information, and can work remotely - I have a hard time believing it cannot be done in Powershell as well.