In this article you will learn how to leverage PowerShell to obtain system information in Windows Server 2008 and Windows desktop systems.
This is the fourth installment of a multi-part series on Windows PowerShell for Windows systems administrators. To get caught up on our subject matter, you might want to read the three previous article about cmdlets and pipeline, aliases and drives, and running scripts.
Now that we have a preliminary understanding of Windows PowerShell, it is time to turn our attention to practical application of the technology. To wit, in this blog post we will learn how to leverage PowerShell in order to ascertain metadata (that is to say, data about data) from a Windows Server 2008 computer. Of course, the same cmdlets apply for obtaining metadata from Windows client machines as well. Let’s get to work!
Before we begin, it is imperative that we have our terminology down pat. First, let’s define environment variables and WMI. According to Microsoft, an environment variable is “a string that contains information about the environment for the system, and the currently logged on user.”
In current Windows systems, the traditional ways to access environment variables are either through the System Control Panel item or the SET command-line program.
Accessing environment variables in Windows
Wikipedia defines Windows Management Instrumentation (WMI) as “a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification.”
In Windows Server 2008, we use WMI not only to discover computer metadata, but we can also create employ WMI for local and remote system administration. In addition, we can define WMI filters in Group Policy to target Group Policy Objects (GPOs) based upon hardware and software-specific criteria.
Accessing Environment Variables in PowerShell
To begin with, fire up an administrative command prompt and type powershell to enter the PowerShell v2 environment. Next, issue the following command to return a list of all defined environment variables for the system:
NOTE: You might recall that dir represents an alias for the Get-ChildItem cmdlet, and that Env: represents a PowerShell drive. See the earlier installments of this series for more information.
To query the value of an existing environment variable, use the following syntax:
Here is a nice list of examples to get you started:
- $env:username (Displays the name of the currently logged-on user)
- $env:userdomain (Displays the logon domain for the current user)
- $env:computername (Displays the hostname of the local system)
- $env:os (Displays the operating system kernel name)
- $env:path (Displays the search path for executable files)
Some PowerShell cmdlets, specifically those that access and modify system information for local and remote systems, require authentication credentials.
We can define a PowerShell variable, for instance $cred1, and instantiate an instance of the Get-Credential cmdlet. That is:
PS>$cred = Get-Credential
Storing a credential in PowerShell
Do you see what’s going on here? The PowerShell script author is prompted for those credentials, which can then be used later on in an interactive session or PowerShell script file.
For greater flexibility, we can hard-code a credential:
PS>$cred2 = Get-Credential –credential corpdomain\admin
In this case, you are prompted for the password and PowerShell stores the password as an encrypted string, safe and secure. We can then call the password later in our PowerShell script or interactive session like so:
PS> $user2 = $cred2.username
$pw = $cred2.password
Now let’s link our understanding of stored credentials with the magic of WMI.
Obtaining System Information in PowerShell
If you have ever tried to use WMI before, you doubtless have found that the WMI Query Language (WQL) used to perform these actions is a bit obtuse. Okay, maybe more than a bit obtuse. Yes, WQL is a subset of the Structured Query Language (SQL) that we database administrators know and love, but the syntax is just so non-intuitive!
Regardless, let’s dive right in with some examples:
PS>Get-WMIObject –Class Win32_ComputerSystem
The above statement lists detailed information about one or more target computers. We can extend that statement big-time by adding additional computer names and attaching our previously defined credential:
PS>Get-WMIObject –Class Win32_ComputerSystem –ComputerName server01, server02, host144, host 255 –Credential $cred1
You can also use this same syntax, substituting only the specific WMI objects to be retrieved. To wit:
- Win32_OperatingSystem (Detailed OS metadata)
- Win32_UserAccount (Lists user accounts)
- Win32_Group (Lists groups)
Enumerating Windows groups with PowerShell
In a future installment of this series I will share with you some tools that will make your PowerShell WMI querying a much more painless process. In the meantime, please feel free to leave your questions, comments, and suggestions for new topics in the comments. Thanks for reading and take care!
For Further Study:
- Creating and Modifying Environment Variables
- About Environment Variables
- WMI Reference
- Exploring WMI with PowerShell V2