Learn PowerShell - Registry Management

#Introduction

In episode 18 you managed Active Directory — the organization's identity hub. But every Windows machine also has its own equally important local configuration hub: the registry. If AD is the organization's phone book, the registry is each machine's "personal filing cabinet" — where Windows and applications store settings. The registry is famously mysterious: nested key trees, odd value types like DWord and REG_SZ, and small mistakes can stop an application — even Windows — from booting.

In this episode we pull back that veil in the most elegant way PowerShell provides: treating the registry as a filesystem. In PowerShell, HKLM: isn't just a virtual drive — it's the doorway to the entire registry structure using exactly the same commands as exploring folders.

#The Registry as a Filesystem

Since the early episodes you've been familiar with Get-ChildItem for exploring folders. Good news: the registry is a folder. PowerShell provides two registry provider drives:

Check the available drives and start exploring:

Get-PSDrive -PSProvider Registry
 
Get-ChildItem -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion" |
    Select-Object Name, SubKeyCount, ValueCount

Note the structure: keys (like folders) and values (like files). One key can contain sub-keys and several values. This is why PowerShell calls it the registry provider — all filesystem operations work, plus dedicated cmdlets for values.

#Reading the Registry

#Reading Values with Get-ItemProperty

The main cmdlet for reading values is Get-ItemProperty. The difference from Get-ChildItem: the former shows the values belonging to a key, while the latter shows the sub-keys:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion" -Name "ProgramFilesDir"
 
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion" -Name "ProgramFilesDir" |
    Select-Object -ExpandProperty ProgramFilesDir

The second line uses Select-Object -ExpandProperty to pull out only the value — not the object with metadata. This is a pattern you'll often need when a registry value is used as input to another command.

#Exploring Keys

For a list of sub-keys, use Get-ChildItem:

Get-ChildItem -Path "HKLM:\SOFTWARE" | Select-Object Name
 
Get-ChildItem -Path "HKCU:\Software" -Recurse -Depth 2 |
    Select-Object -First 20 FullName

Note: -Recurse on the HKLM: root without -Depth takes a very long time because the tree is very deep. Limit with -Depth or start from a specific key.

#Writing the Registry

#Creating New Keys and Values

New-Item creates a key; New-ItemProperty creates a value inside it:

New-Item -Path "HKCU:\Software\MyApp" -Force
 
New-ItemProperty -Path "HKCU:\Software\MyApp" `
    -Name "Version" `
    -Value "1.0" `
    -PropertyType String

The most common value types:

Choosing the right -PropertyType matters: applications read this type to decide how to interpret the value. A DWord value created as a String will be misinterpreted.

#Changing Existing Values

Set-ItemProperty changes existing values without recreating them:

Set-ItemProperty -Path "HKCU:\Software\MyApp" -Name "Version" -Value "1.1"
Set-ItemProperty -Path "HKCU:\Software\MyApp" -Name "AutoStart" -Value 1 -PropertyType DWord

Note the value 1 for DWord — a numeric type, without quotes; this sets the "auto start enabled" flag.

#Deleting Values

Remove-ItemProperty deletes a value; Remove-Item deletes a key along with its contents:

Remove-ItemProperty -Path "HKCU:\Software\MyApp" -Name "Version"
Remove-Item -Path "HKCU:\Software\MyApp" -Confirm:$true

#Common Tasks

#Reading and Changing Values Programmatically

The most common real-world pattern: read a value, compare, change if different. Example: check the Windows build version before running a script that depends on a specific version:

$currentBuild = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" -Name "CurrentBuildNumber").CurrentBuildNumber
 
if ($currentBuild -ge 22000) {
    Write-Output "Windows 11 atau lebih baru: build $currentBuild"
} else {
    Write-Output "Windows 10 atau lebih lama: build $currentBuild"
}

#Backing Up the Registry

The golden rule before touching the registry: back up first. PowerShell leverages the classic reg export to save a key snapshot to a .reg file:

$stamp = Get-Date -Format "yyyyMMdd_HHmmss"
$backupFile = "C:\Backup\MyApp_$stamp.reg"
 
reg export "HKCU\Software\MyApp" $backupFile
Write-Output "Backup tersimpan di $backupFile"

If something goes wrong, you just reg import the file to restore the original state. For small keys, also save the value list to CSV as documentation:

Get-ItemProperty -Path "HKCU:\Software\MyApp" |
    ConvertTo-Json | Out-File "C:\Backup\MyApp_values.json"

#The Registry of Remote Machines

To manage another machine's registry, PowerShell Remoting (covered in episode 16) is the way — every target machine must have WinRM enabled:

Invoke-Command -ComputerName "server-01" -ScriptBlock {
    Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion" -Name "ProgramFilesDir"
}

The script inside -ScriptBlock runs on the target machine, so the HKLM: path refers to that server's registry — not your local machine. This is how you check the configuration of hundreds of servers without logging into each one.

#Best Practices

The registry is the least forgiving place in Windows. Four habits you should internalize:

1. Back up before writing. One line of reg export is cheaper than restoring a machine that won't boot.
2. Test on a trial machine first. Develop and verify registry scripts on a test machine with the same Windows version as production — registry structure can differ between versions.
3. Document changes. Record the keys changed, old values, new values, and the reason. Your team (and you six months from now) will thank you.
4. Handle errors explicitly. A missing key throws an error. Wrap write operations in a try-catch block:

try {
    Set-ItemProperty -Path "HKCU:\Software\MyApp" `
        -Name "Version" -Value "1.2" -ErrorAction Stop
    Write-Output "Nilai berhasil diubah"
} catch {
    Write-Output "Gagal mengubah registry: $($_.Exception.Message)"
}

-ErrorAction Stop turns a non-terminating error into one that throws an exception, so the catch block really works. Without it, the script continues to the next line as if it had succeeded.

#Conclusion

In this episode 19 you've opened Windows' secret chest: the registry viewed as an explorable filesystem. You understand the two provider drives, HKLM: for machine configuration and HKCU: for user configuration; read values with Get-ItemProperty, keys with Get-ChildItem; write new keys and values with New-Item and New-ItemProperty; change with Set-ItemProperty; delete with Remove-ItemProperty; plus common tasks like backup via reg export, and managing remote machines' registry via Invoke-Command.

Key takeaways:

• The registry is a tree of keys and values — treat it as folders and files.
• Choose the correct -PropertyType; applications read this type to interpret values.
• Back up before writing, test in a trial environment, and document changes.
• Always wrap write operations with try-catch and -ErrorAction Stop.

Machine configuration is now at your fingertips. But there's one type of configuration update that has the biggest impact and is most often postponed: Windows patching. In the next episode, episode 20, we'll cover Windows Updates & Patching: the PSWindowsUpdate module for update automation, WSUS integration for large organizations, update history with Get-Hotfix, and patch verification and rollback. See you there!