Prof. Powershell

Practical PowerShell Part 1: 1-Line Commands

Before you can run, you have to learn to walk.

• By Jeffery Hicks
• 07/08/2014

More on this topic:

• Practical PowerShell Part 2: Property Value
• Practical PowerShell Part 3: Create Custom Objects Quickly
• Practical PowerShell Part 4: Output Formatting
• Practical PowerShell Part 5: Remoting

Sometimes the most difficult part of PowerShell is trying to figure out what to do with it. This is especially true for beginners where you are in a "chicken or egg" situation -- you don't know enough PowerShell to know what you can do with it and you can't do much with it because your knowledge is limited. So over the next few lessons, let's see how we can overcome this paradox. We'll start with a simple one-line command and see where it leads us. The command itself isn't necessarily that important but rather the journey it takes us on. Everything we're going to look at should run on at least PowerShell v3.

I'm going to begin with a simple command to list some information from the registry:

PS C:\> Get-ItemProperty -Path HKLM:\SOFTWARE\RegisteredApplications

As you can see in Figure 1 this registry key lists registered applications. The value points to a relative registry path that should provide more information about each application. Ideally, I'd like to be able to get a comprehensive view of each application, perhaps pulling information from that value.

One of the first things to do is to determine what type of object Get-ItemProperty is writing to the pipeline so I can figure out what properties I have to work with.

PS C:\> Get-ItemProperty -Path HKLM:\SOFTWARE\RegisteredApplications | get-member

Interesting. Instead of a "normal" object, this is a custom object where each registry entry is a property name. It might help to see the corresponding registry view.

Back in Figure 1 you can see Get-ItemProperty also includes some custom PowerShell properties like PSPath. Those are going to get in the way so I need a way of excluding them. One technique can be to use Select-Object and the –ExcludeProperty parameter.

PS C:\> Get-ItemProperty -Path HKLM:\SOFTWARE\RegisteredApplications | Select * -exclude PS*

As you can see in Figure 4, using a wild card works. But in terms of a technique, it is possible there might be a registry entry that starts with PS. In this case, being more explicit is a better choice.

PS C:\> $exclude = "PSParentPath","PSChildName","PSDrive","PSProvider","PSPath"
PS C:\> $regentry = Get-ItemProperty -Path HKLM:\SOFTWARE\RegisteredApplications | Select –Property * -ExcludeProperty $exclude

Remember, to exclude a property you need to also specify what properties to include, which I'm doing with the wildcard (*). Now for the tricky part. Because the property names are dynamic and unpredictable, I am going to need to know what they are.

PS C:\> $regentry | Get-Member -MemberType NoteProperty

I could also have used this trick to enumerate names:

PS C:\> $regentry.psobject.properties.name
Paint
Windows Search
Windows Disc Image Burner
Windows Photo Viewer
Wordpad
Windows Media Player
Internet Explorer
Windows Address Book
PhotoManager
File Explorer
Google Chrome
WinRAR
Thunderbird
Thunderbird (News)
Excel.Application.15
OneNote.Application.15
PowerPoint.Application.15
Publisher.Application.15
Word.Application.15
Lync.Application.15
SnagIt.11
Nitro Reader 3
Skype
WDExpress.12.0
VisualStudio.11.0

Interestingly, $regentry is NOT an array of objects.

PS C:\> $regentry.count
PS C:\> $regentry | measure-object

Count    : 1
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

But that's all the time we have this week. We'll pick up here next week and see what we can do with this object and its properties.