Powershell registry access multiple options

1
votes

To access or make changes to registry in a windows machine by powershell, I see two ways

  1. cd HKLM:\ (or set-location -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion)

    Get-childitem

    or

    Get-Item -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

  2. Get-ItemProperty , New-ItemProperty , Set-ItemProperty

When to use one over the other?

1
powershell

1 Answers

2
votes

They are both necessary, because the property values aren't accessible on the Item objects (and you can't see the nested "child" container items with the ItemProperty commands).

My 2c: the registry provider was written by someone as a demo, and then shipped and now they're afraid to change it ... it's the only way to explain the whole "ItemProperty" thing.

Basically, when they mapped the registry to the PowerShell Provider semantics, instead of having "Container" and "Leaf" items, there are only containers, and each container has properties (and/or child containers).

So if you do Get-ChildItem HKCU:\SOFTWARE\Microsoft you get a response back listing the "Name" of each of the child containers (which the Registry Editory (Regedit.exe) would show as folders), and listing the values in them under the heading "Property" -- but that listing is purely in the display, and the Property field on the object you got back is actually just a string array listing the names of the properties so you know what you can do next:

  • If you want to actually read the values in a way that makes them accessible to your script, you need to use Get-ItemProperty
  • If you want to change the value, you need to use Set-ItemProperty
  • To create new ones, you need to use New-ItemProperty

In your example, for instance, you might see SecurityHealth:

The Run key has a SecurityHealth property pointing at SecurityHealthSystray.exe

But it's like the screenshot above, as a human, you can see the value, but your script can't read the value...

You have to use Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to get an object back that actually has the SecurityHealth property with the C:\WINDOWS\System32\SecurityHealthSystray.exe value...