The Registry
The registry is a collection of hierarchical keys; a registry key may have zero or more sub-keys, and so on. Each key or sub-key may have zero or more value entries. Every value entry contains a data type and a data value. Any registry key can contain values of any data type. The registry allows you to create any key and store almost any type of data in a value entry.
The registry is implemented in Windows as a collection of registry hives. A hive is a logical collection of keys, sub-keys, and values in the Registry. Each hive contains a set of supporting files that Windows loads into memory when the operating system boots or a user logs in.
Since Windows NT 3.1, you may easily modify the registry using the built-in registry editor regedit.exe. Windows NT also included the reg.exe command, which allows you to programmatically manage the registry and can still be used today. You can also use WMI to access WMI.
The Windows PowerShell team devised a very simple approach for IT professionals to use PowerShell by utilising the Registry provider, which is the topic of this post.
Providers and the Registry Provider
Windows has a variety of data stores that are essential to the operation of Windows and its programs. These data stores include the registry, the file store, the certificate store, and others. When it came to allowing IT professionals to access all of this information, PowerShell developers had two alternatives.
The first approach was to develop a large number of distinct cmdlets for each data repository. This would be a lot of work, and it would almost certainly result in discrepancies. The second idea was to utilise an intermediate layer, the provider, to turn the data store into something like a file store. With the provider, you use the same commands to gain access to the registry and files and folders, etc.
To discover the providers on your system, you use the Get-PSProvider cmdlet like this:
PS C:\Users\suyi> Get-PSProvider
Name Capabilities Drives
---- ------------ ------
Registry ShouldProcess {HKLM, HKCU}
Alias ShouldProcess {Alias}
Environment ShouldProcess {Env}
FileSystem Filter, ShouldProcess, Credentials {C, Temp, H, M…}
Function ShouldProcess {Function}
Variable ShouldProcess {Variable}
Provider Drives
You can set up a drive with a provider that grants access to a portion of one of the provider-based data repositories. PowerShell gives you provider drives for the filestore provider that point to the Windows volumes on your computer, like C:, D:, etc. Additionally, you can use the New-PSDrive cmdlet to establish a provider drive named DB: that refers to D:\Local. If this is helpful, you can add the statement to your profile to persist the drive name.
HKLM: and HKCU: are the two built-in drives that PowerShell gives you when you use the registry provider. The local machine registry hive, which you (and Windows) use for system-wide settings, is exposed by the HKLM: drive. To access the current user's registry hive, use the HKCU: drive.
You can discover the provider based drives by using the Get-PSProvider cmdlet, like this:
PS C:\Users\suyi> Get-PSDrive
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
Alias Alias
C 101.56 374.45 FileSystem C:\ Users\suyi
Cert Certificate \
Env Environment
Function Function
HKCU Registry HKEY_CURRENT_USER
HKLM Registry HKEY_LOCAL_MACHINE
Temp 101.56 374.45 FileSystem C:\Users\suyi\AppData\Local\Tem…
Variable Variable
WSMan WSMan
Some Windows features come with additional providers, such as the the ActiveDirectory RSAT module. This feature includes an AD provider:
PS> Import-Module -Name ActiveDirectory
PS> Get-PSProvider -Name ActiveDirectory
Name Capabilities Drives
---- ------------ ------
ActiveDirectory Include, Exclude, Filter, ShouldProcess, Credentials {AD}
Registry Value Entries
As previously stated, value entries can be found in a registry key. Each value entry can be thought of as a registry key attribute. To manage specific registry values, use the *-ItemProperty cmdlets. The relevance of this with the query is examined here:
$RegistryPath = 'HKCU:\Software\DebugSchool\Scripts'
$Name = 'Version'
$Value = '42'
New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
New-ItemProperty: Cannot find path 'HKCU:\Software\DebugSchool\Scripts' because it does not exist.
The script created a Version value entry to a particular key using the New-ItemProperty. However, because the registry key indicated in the $RegistryPath variable is not present, this script fails.
It is preferable to test the registry key path first, create it if necessary, and then set the value entry as follows:
# Set variables to indicate value and key to set
$RegistryPath = 'HKCU:\Software\DebugSchool\Scripts'
$Name = 'Version'
$Value = '42'
# Create the key if it does not exist
If (-NOT (Test-Path $RegistryPath)) {
New-Item -Path $RegistryPath -Force | Out-Null
}
# Now set the value
New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
It can be risky to play about with the registration. This holds true when utilising PowerShell commands as well as the Registry Editor.
Adding registry keys and values is simple. Any key in any registry hive can be created with the New-Item cmdlet. Once the key has been created, a registry value entry can be set using New-ItemProperty.
Note: In Windows, the Registry is a database of configuration data used by Windows and its applications. The registry is critical to Windows functioning and using the registry editor can be dangerous, so use caution!
Top comments (0)