Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use Windows PowerShell to create new registry keys on local and remote computers.
Hey, Scripting Guy! I am often required to create new registry keys on our computers. One of the reasons for this is for occasional system configuration. You see, in our company the Group Policy team is the Group Policy team. They do Group Policy—but only for their own ends. They never make changes at the request of desktop support. In fact, they are reluctant to make any changes what-so-ever. Of course, when you are in charge of Group Policy for a multiforest, multidomain, international company with a presence on four continents, involving over a hundred-thousand machines, it is easy to understand their reluctance. Additionally, in the past, a few misguided Group Policy Objects (GPOs) were applied, and they brought the network to its knees. Anyway, long story short, I need an easy way to create new registry keys on our desktop machines.
Microsoft Scripting Guy, Ed Wilson, is here. This morning is a coffee morning for me. I was up late last night finishing a mystery novel, so when the alarm went off, it seemed like it was still “oh dark thirty,” so I thought I would make a pot of Kona coffee in my French press while the Scripting Wife was busying herself making a couple of omelets. I am in my office listening to a new jazz/blues fusion CD that the mail person brought to our house yesterday. I was on the treadmill at the time, and this is the first chance I have had to give it a spin.
I spent my time at the breakfast table (while waiting for the French Roast estate reserve beans to steep) reviewing my schedule. Here it is: the Scripting Wife and I are home for a few weeks, then we will be on the road for a couple of weeks. We are heading south, which when you already live in the deep south, generally means Florida. On June 1, 2012, we will be at the Atlanta TechStravaganza. I will be making a couple of presentations, and if it is anything like it was last year, the day should be a ton of fun with tremendous learning and networking opportunities. Check out the community page for more information about where I will be in the next month or so.
LL, your story is, unfortunately, not uncommon. I was talking to several IT Pros at the Mark Minasi conference in Virginia Beach last week, and they echoed your sentiments—Group Policy seems to be a rather large hammer with which to insert glazier points. Luckily, many of the tasks that are done via Group Policy are configurable through the registry. In fact, there are Group Policy spreadsheets that document these settings, and they are available on the Microsoft Download Center.
Note This is the third blog in a series of Hey, Scripting Guy! Blogs that discuss using the Registry provider. The first blog, Use the PowerShell Registry Provider to Simplify Registry Access, posted on Monday. Tuesday I discussed using the *restore* cmdlets to perform a system state backup of a computer prior to manipulating the registry. For additional information about working with the registry via Windows PowerShell, see this collection of blogs.
Creating new registry keys
Note The registry contains information that is vital to the operation and configuration of your computer. Serious problems could arise if you edit the registry incorrectly. Therefore, it is important to back up your system prior to attempting to make any changes. For information about backing up your registry, see article 322756 in the Microsoft Knowledge Base. For general information about working with the registry, see article 310516.
Creating a new registry key by using Windows PowerShell is the same as creating a new file or a new folder. All three processes use the New-Item cmdlet. In addition, you might use the Test-Path cmdlet to determine if the registry key already exists. You may also wish to change your working location to one of the registry drives. If you do this, you might use the Push-Location, Set-Location, and Pop-Location cmdlets. This, of course, is the long way of doing things...
Only the steps:
- Store the current working location by using the Push-Location cmdlet.
- Change the current working location to the appropriate registry drive by using the Set-Location cmdlet.
- Use the Test-Path cmdlet to determine if the registry key already exists.
- Use the New-Item cmdlet to create the new registry key.
- Use the Pop-Location cmdlet to return to the starting working location.
The following example creates a new registry key named hsg off the HKEY_CURRENT_USERS software registry hive. It illustrates each of the previous five steps.
New-Item -Path .\Software -Name hsg
The commands and the associated output from the commands are shown in the image that follows.
The newly created registry key is shown here in the Registry Editor tool.
The short way to create a new registry key
It is not always necessary to change the working location to a registry drive when you create a new registry key. In fact, it is not even necessary to use the Test-Path cmdlet to determine if the registry key exists. If the registry key already exists, an error generates. If you want to overwrite the registry key, use the Force parameter.
Note How you choose to deal with an already existing registry key is one of those design decisions that confront IT Pros who venture far into the world of scripting. Software developers are very familiar with these types of decisions, and they usually deal with them in the analyzing requirements portion of the development life cycle. IT Pros who open the Windows PowerShell ISE first, and think about the design requirements second, become easily stymied, or else write-in problems. For more information about this, see my Microsoft Press book, Windows PowerShell 2.0 Best Practices.
The following example creates a new registry key named hsg in the HKCU:\Software location. Because the command includes the full path, it does not need to execute from the HKCU drive. Because the command uses the Force switched parameter, the command overwrites the HKCU:\Software\HSG registry key if it already exists.
New-Item -Path HKCU:\Software -Name hsg –Force
Only the steps…
The shortcut way to create a new registry key:
- Include the full path to the registry key to create.
- Use the Force parameter to overwrite any existing registry key of the same name.
In the image that follows, the first attempt to create an hsg registry key fails because it already exists. The second command uses the Force parameter, which causes the command to overwrite the existing registry key. Therefore, it succeeds without creating an error.
Setting the default value for the key
The previous examples do not set the default value for the newly created registry key. If the registry key already exists (as it does in this specific case), use the Set-Item cmdlet to assign a default value to the registry key as follows.
Only the steps…
Assigning a default value to an existing registry key:
- Use the Set-Item cmdlet and supply the complete path to the existing registry key.
- Supply the default value in the Value parameter of the Set-Item cmdlet.
The following command assigns the value “hsg key” to the default property value of the hsg registry key that is contained in the HKCU:\Software location.
Set-Item -Path HKCU:\Software\hsg -Value "hsg key"
The command does not return any information to the Windows PowerShell console when it runs. The modified registry key is shown here in the Registry Editor tool.
Use New-Item to create and assign a value
It is not necessary to use the New-Item cmdlet to create a registry key and then to use the Set-Item cmdlet to assign a default value. These steps are combinable to a single command. The following command creates a new registry key with the name hsg1, and it assigns a default value of “default value” to the registry key.
New-Item -Path HKCU:\Software\hsg1 -Value "default value"
The newly created registry key with default value is shown in the image that follows.
LL, that is all there is to creating a new registry key. Registry Week will continue tomorrow when I will talk about modifying registry keys by using Windows PowerShell.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy