Summary: Learn how to use Windows PowerShell to create new registry keys on remote systems by using remoting.

 Hey, Scripting Guy! I need to create registry keys on a number of remote servers. I do not want to use the Registry Editor to do this because the servers all have the firewall enabled, and I do not want to enable the remote registry service on these machines. Is there a way I can use Windows PowerShell to create these registry keys? I really do not want to use remote desktop to do this.

—YH

 Hello YH,

Microsoft Scripting Guy, Ed Wilson, is here. I just finished a team meeting where we were talking about documentation for the Windows Server “8” Beta release—really exciting stuff. I can tell you that Microsoft is the most exciting company for which I have ever worked. It is everything I hoped for when I joined nearly 11 years ago—and even more. I am dying to start writing about Windows PowerShell 3.0 and Windows Server “8” Beta, but I imagine that most IT Pros have not yet deployed it to their systems, so I will forgo that until the product actually ships.

I am sipping a cup of Darjeeling tea with some lemon grass and a cinnamon stick, accompanied by a slice of 90 percent cacao chocolate. It is the perfect afternoon snack. This week is turning out to be a lot of fun. Tonight, the Scripting Wife and I are having dinner with one of the members of the Charlotte Windows PowerShell Users Group. We will be talking about upcoming user group presentations. It is always a lot of fun to get together with fellow Windows PowerShell geeks because the conversations are usually $cool.

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 Registry Provider to Simply 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. On Wednesday I talked about creating new registry keys and assigning default values. For additional information about working with the registry via Windows PowerShell, see this collection of blogs.

YH, there are several ways to create registry keys on remote systems. One way is to use the .NET Framework classes and another way is to use WMI. By far, the easiest way is to combine using the Windows PowerShell Registry provider with Windows PowerShell remoting. This is because Windows PowerShell remoting uses the firewall friendly WSMan protocol. In fact, inside a single forest, single domain with Windows Server “8” Beta, remoting just works. There are no configuration changes required to enable Windows PowerShell remoting in Windows Server “8” Beta.

Entering a remote session to create a new registry key

If you only have a single computer upon which you need to create one or more new registry keys, it is probably easiest to enter a remote Windows PowerShell session. Doing this provides you with the equivalent experience of opening the Windows PowerShell console and working in an interactive fashion. There are several steps involved, but they are not too difficult.

Only the steps…

Entering a remote Windows PowerShell session to create a new registry key:

1. Use the Get-Credential cmdlet to obtain a credential object with rights on the remote computer. Store the returned credential object in a variable.
2. Use the Enter-PSSession cmdlet to enter a remote Windows PowerShell session on the target computer.
3. Use the New-Item cmdlet to create the new registry key.
4. Use the Exit command to leave the remote Windows PowerShell session.

The commands to obtain credentials, enter a Windows PowerShell session, create a new registry key, and leave the Windows PowerShell session are shown here.

$credential = Get-Credential -Credential iammred\administrator

Enter-PSSession -ComputerName sql1 -Credential $credential

New-Item -Path HKCU:\Software -Name HSG -Value “my default value”

Exit

The use of these commands and the associated output are shown in the image that follows.

I use Remote Desktop Protocol (RDP) to connect to the SQL1 server to verify creation of the registry key. Keep in mind that when you make a remote connection and create keys on the HKCU drive, the user account that makes the remote connection is the current user who will hold the newly created registry key. The newly created registry key is shown in the image that follows.

Creating remote registry keys on multiple computers

Entering a remote Windows PowerShell session to create a registry key on multiple computers is a tedious and time-consuming process. To perform a command on multiple machines, it is better to use the Invoke-Command cmdlet.

Only the steps…

Using the Invoke-Command cmdlet to create remote registry keys:

1. Store the server names in a variable.
2. Store the connection credentials in a variable (use the Get-Credential cmdlet to obtain the credentials).
3. Use the Invoke-Command cmdlet to run the command against the remote machines. Place the command to be run in the ScriptBlock parameter.

The following commands create a new registry key on the HKCU drive on three different servers.

$servers = “hyperv1″,”hyperv2″,”hyperv3”

$credential = Get-Credential -Credential iammred\administrator

Invoke-Command -ComputerName $servers -Credential $credential -ScriptBlock {New-Item -Path HKCU:\Software -Name hsg -Value “scripted default value”}

The commands and the output associated with running the commands are shown in the image that follows.

The returning output from the Invoke-Command cmdlet displays the computer name and illustrates the newly created registry key. However, if you wish further confirmation that the registry keys created properly, it is easy to change the New-Item command to Test-Path. Because the server names reside in a variable, in addition to the credentials, using Test-Path inside the script block of the Invoke-Command cmdlet is trivial. Here is the revised command.

Invoke-Command -ComputerName $servers -Credential $credential -ScriptBlock {Test-Path -Path HKCU:\Software\hsg}

The command and its associated output are shown in the image that follows.

Creating property values

It is unusual to have a registry key that has only a default property value. In fact, most registry keys contain multiple property values. To create a new property value, use the New-ItemProperty cmdlet. The following command creates a new property value named NewProperty under the previously created HSG registry key.

New-ItemProperty -Path HKCU:\Software\hsg -Name NewProperty -Value “New PropertyValue”

The newly created registry key property is shown in the image that follows.

Getting registry property values

When run, the command returns information about the registry key property. In fact, this is the same information that is obtained by using the Get-ItemProperty cmdlet. The use of the Get-ItemProperty cmdlet and the associated output from the command are shown here.

PS C:\> Get-ItemProperty -path HKCU:\Software\hsg -Name newproperty

PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software\hsg

PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software

PSChildName  : hsg

PSDrive      : HKCU

PSProvider   : Microsoft.PowerShell.Core\Registry

NewProperty  : New PropertyValue

The newly created registry property appears in the output under the name of the property. This means that to display only the value of the registry property requires essentially naming the property twice. The first time the registry property appears, it is the name of the registry property to obtain; the second time, it is the property to retrieve. This command and the associated output are shown here.

 PS C:\> (Get-ItemProperty -path HKCU:\Software\hsg -Name newproperty).newProperty

New PropertyValue

YH, that is all there is to using Windows PowerShell to create registry keys on remote systems. Registry Week will continue tomorrow when I will talk about enumerating registry key properties.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy