PowerShell tutorial for admins – Part 4: Environment variables and system information

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Install Ansible on Windows - Thu, Jul 20 2023
• Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
• Azure Virtual Desktop: Getting started - Fri, Apr 14 2023

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!

Preliminary Terminology

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:

dir Env:

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:

$Env:<variable_name>

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:

$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:

$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:

$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:

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:

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

Conclusion

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