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:SOFTWAREMicrosoft
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:
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:SOFTWAREMicrosoftWindowsCurrentVersionRun
to get an object back that actually has the SecurityHealth
property with the C:WINDOWSSystem32SecurityHealthSystray.exe
value...
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…