{"id":414,"date":"2021-07-30T12:34:11","date_gmt":"2021-07-30T19:34:11","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/powershell-community\/?p=414"},"modified":"2021-07-30T12:38:09","modified_gmt":"2021-07-30T19:38:09","slug":"how-to-update-or-add-a-registry-key-value-with-powershell","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell-community\/how-to-update-or-add-a-registry-key-value-with-powershell\/","title":{"rendered":"How to Update or Add a Registry Key Value with PowerShell"},"content":{"rendered":"

Q:<\/strong> I am having a problem trying to update the registry. I am using the New-ItemProperty cmdlet, but it fails if the registry key does not exist. I added the \u2013Force parameter, but it still does not create the registry key. The error message says that it cannot find the path because it does not exist. Is there something I am not doing? I include my script so you can see what is going on. Help me, please?<\/p>\n

A:<\/strong> Let’s look at how you can use PowerShell to add or update any registry key value.<\/p>\n

The Registry<\/h2>\n

Before answering the query, let me cover some of the background basics. You probably already know this but I start with a look at the Registry and how PowerShell providers relate to the query. I hope this is not too<\/em> basic!<\/p>\n

In Windows the Registry is a database of configurations information used by Windows and Windows applications. The registry is critical to the operation of Windows – I learned that long ago (and got practice reinstalling Windows NT). Using the registry editor can be dangerous, so be careful!<\/p>\n

The registry is a set of hierarchical keys – a registry key can have zero, or more sub-keys, and so on. Each key or sub-key can have zero or more value entries. Each value entry has a data type and a data value. Any registry key can have values of any data type. The registry allows you to create any key and to put pretty much any kind of data into a value entry.<\/p>\n

The registry is implemented in Windows as a set of registry hives. A hive is a logical group of keys, sub-keys, and values in the registry. Each hive has a set of supporting files that Windows loads into memory when the operating system starts up or a user logs in. For more details about registry hives see the Registry Hives on-line help text<\/a>.<\/p>\n

Ever since Windows NT 3.1, it is easy to edit the registry using the built in registry editor – regedit.exe<\/code>. Windows NT also had the reg.exe<\/code> command that allowed you to manage the registry programatically and you can still usew it today. You can also use the WMI to access WMI, as shown in this excerpt from Richard Siddaway’s book PowerShell and WMI<\/strong><\/a>.<\/p>\n

For IT Pros using PowerShell, the Windows PowerShell team, created a very simple way through the use of the Registry provider which is the focus of this article.<\/p>\n

Providers and the Registry Provider<\/h2>\n

Windows contains a number of data stores that are critical to the operation of Windows and Windows applications. These data stores include the registry, as well as the file store, the certificate store, and more. The developers of PowerShell, when faced with the challenge of enabling IT Pros to access all this information had two main options.<\/p>\n

The first option was to create a huge number unique cmdlets for each data store This would be a lot of work and would be almost certain to introduce inconsistencies. The second option was to use an intermediate layer, the provider, which converted the data store into something resembling the file store. With the provider you use the same command(s) to get access the registry, access files and folders, etc.<\/p>\n

To discover the providers on your system, you use the Get-PSProvider<\/code> cmdlet like this:<\/p>\n

PS> Get-PSProvider\n\nName         Capabilities                         Drives\n----         ------------                         ------\nRegistry     ShouldProcess                        {HKLM, HKCU}\nAlias        ShouldProcess                        {Alias}\nEnvironment  ShouldProcess                        {Env}\nFileSystem   Filter, ShouldProcess, Credentials   {C, D, H, I, M, N, Temp, db\u2026\nFunction     ShouldProcess                        {Function}\nVariable     ShouldProcess                        {Variable}\nCertificate  ShouldProcess                        {Cert}<\/code><\/pre>\n
Provider Drives<\/h2>\n
With a provider, you can create a drive that allows access to part of one of the provider-based data stores. For the filestore provider, PowerShell provides you with provider drives pointing to the Windows volumes in your system, such as C:<\/strong>, D:<\/strong>, etc. You can also create a provider drive called DB:<\/code> that points to D:\\Dropbox<\/code> by using the New-PSDrive<\/code> cmdlet. You can persist the drive name by adding the statement to your profile should this be useful.<\/p>\n
With the registry provider, PowerShell provides you with two built-in drives: HKLM:<\/code> and HKCU:<\/code>. The HKLM:<\/strong> drive exposes the local machine registry hive – which you (and Windows) use for system wide settings. You use the HKCU:<\/strong> drive to access the current user’s registry hive.<\/p>\n
You can discover the provider based drives by using the Get-PSProvider<\/code> cmdlet, like this:<\/p>\n
PS> Get-PSDrive\n\nName     Used (GB)   Free (GB) Provider      Root\n----     ---------   --------- --------      ----\nAlias                          Alias\nC           262.51      714.58 FileSystem    C:\\\nCert                           Certificate   \\\nD          1312.83      596.76 FileSystem    D:\\\ndb         1312.83      596.76 FileSystem    D:\\DropBox\ndocs       1312.83      596.76 FileSystem    D:\\Dropbox\\PACKT\u2026\nEnv                            Environment\nF                              FileSystem    F:\\\nFunction                       Function\nG             2.68       56.79 FileSystem    G:\\\ngd         3169.18      556.84 FileSystem    M:\\gd\nH          2860.16      865.85 FileSystem    H:\\\nHKCU                           Registry      HKEY_CURRENT_USER\nHKLM                           Registry      HKEY_LOCAL_MACHINE..<\/code><\/pre>\n
Some Windows features come with additional providers, such as the the ActiveDirectory<\/strong> RSAT module. This feature includes an AD provider:<\/p>\n
PS> Import-Module -Name ActiveDirectory\nPS> Get-PSProvider -Name ActiveDirectory\n\nName             Capabilities                                          Drives\n----             ------------                                          ------\nActiveDirectory  Include, Exclude, Filter, ShouldProcess, Credentials  {AD}<\/code><\/pre>\n
Registry Value Entries<\/h2>\n
As I mentioned above, a registry key can contain value entries. You can think of each value entry as an attribute of a registry key. You use the *-ItemProperty<\/code> cmdlets to manage individual registry values. But how does this relate to the question? Let’s begin by looking at the script in question:<\/p>\n
$RegistryPath = 'HKCU:\\Software\\CommunityBlog\\Scripts'\n$Name         = 'Version'\n$Value        = '42'\nNew-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force \n\nNew-ItemProperty: Cannot find path 'HKCU:\\Software\\CommunityBlog\\Scripts' because it does not exist.<\/code><\/pre>\n
The script used the New-ItemProperty<\/code> to create a Version<\/strong> value entry to a specific key. This script, however, fails since the registry key, specified in $RegistryPath<\/code> variable does not exist.<\/p>\n
A better approach is to test the registry key path first, creating it if needed, then setting the value entry, like this:<\/p>\n
# Set variables to indicate value and key to set\n$RegistryPath = 'HKCU:\\Software\\CommunityBlog\\Scripts'\n$Name         = 'Version'\n$Value        = '42'\n# Create the key if it does not exist\nIf (-NOT (Test-Path $RegistryPath)) {\n  New-Item -Path $RegistryPath -Force | Out-Null\n}  \n# Now set the value\nNew-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force <\/code><\/pre>\n
A small word of warning<\/h2>\n
Playing with the registry can be dangerous. This is true when using both the Registry Editor and the PowerShell commands. Be careful!<\/p>\n
Summary<\/h2>\n
It is easy to change add registry keys and values. You can use the New-Item<\/code> cmdlet to create any key in any registry hive. Once you create the key, you can use New-ItemProperty<\/code> to set a registry value entry.<\/p>\n
Tip of the Hat<\/h2>\n
I based this article on one written for the earlier Scripting Guys blog Update or Add Registry Key Value with PowerShell<\/a>. It was written by Ed Wilson.<\/p>\n","protected":false},"excerpt":{"rendered":"
Q: I am having a problem trying to update the registry. I am using the New-ItemProperty cmdlet, but it fails if the registry key does not exist. I added the \u2013Force parameter, but it still does not create the registry key. The error message says that it cannot find the path because it does not […]<\/p>\n","protected":false},"author":4034,"featured_media":77,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[13],"tags":[3,41,40],"class_list":["post-414","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell","tag-powershell","tag-provider","tag-registry"],"acf":[],"blog_post_summary":"
Q: I am having a problem trying to update the registry. I am using the New-ItemProperty cmdlet, but it fails if the registry key does not exist. I added the \u2013Force parameter, but it still does not create the registry key. The error message says that it cannot find the path because it does not […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/posts\/414","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/users\/4034"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/comments?post=414"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/posts\/414\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/media\/77"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/media?parent=414"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/categories?post=414"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell-community\/wp-json\/wp\/v2\/tags?post=414"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}