Use PowerShell DSC to Configure the Registry


Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell and Desired State Configuration to configure the registry.

Microsoft Scripting Guy, Ed Wilson, is here. I thought I would piggy-back a bit on the excellent posts that Windows PowerShell MVP, Richard Siddaway, wrote this week about working with the registry with Windows PowerShell.

If I want to make sure that a registry entry exists (or does not exist), I can use Windows PowerShell Desired State Configuration (DSC). Another advantage to using DSC is that it automatically updates, so I do not need to worry if the entry will still be there at a later point in time.

Using DSC to configure the use of biometrics

I decided that I wanted to disable the use of biometric devices for sign in to my system. To do this, there are several registry keys available that work in conjunction with Group Policy. The thing is that I do not want to fool around with using Group Policy. In fact, I have heard from many IT pros that the Group Policy teams in their organizations are reluctant to make changes they request.

Note  DSC runs in a system context, and therefore, it does not have access to the current user registry hive (HKCU).

On to my configuration script...

The first thing I do is use the Configuration keyword and specify a name for my configuration. I then specify my node—I am using LocalHost, so I do not need to worry about a computer name. I then specify the registry resource, and a name. I specify that I want the registry key to exist, so I specify that I will ensure it is present. I provide the registry key, the key name, the value, and the type of value. This portion of the script is shown here:

Configuration SetBiometrics {

    Node localhost {

    Registry DisableBiometrics {

        Ensure = "Present"

        Key = "HKLM:\SOFTWARE\Policies\Microsoft\Biometrics"

        ValueName = "Enabled"

        ValueData = "0"

        ValueType = "Dword" }

The other two registry sections are pretty much the same. In fact, I pasted the script from my previous section and made minor changes. Here are the other two parts of the configuration script:

Registry DisableCredentials {

        Ensure = "Present"

        Key = "HKLM:\SOFTWARE\Policies\Microsoft\Biometrics\Credential Provider"

        ValueName = "Enabled"

        ValueData = "0"

        ValueType = "Dword" }

    Registry DisableDomainCredentials {

        Ensure = "Present"

        Key = "HKLM:\SOFTWARE\Policies\Microsoft\Biometrics\Credential Provider"

        ValueName = "Domain Accounts"

        ValueData = "0"

        ValueType = "Dword" } }}

The last thing I need to do is to call my configuration like I would a function. I pass a directory for my output. I then use Start-DSCConfiguration and specify the path to the MOF file. This command is shown here:

SetBiometrics -output C:\clientConfig

Start-DscConfiguration -Path C:\clientConfig -Wait -Force -Verbose

Here is the complete script as it appears in my Windows PowerShell ISE:

Image of command output

Because I called Start-DSCConfiguration with the –Verbose parameter, I can see everything that is going on, in addition to how long it takes to run the configuration. In the output in the following image, I see that the registry key did not exist, and therefore, it was created.

Image of command output

That is all there is to it. Now Windows PowerShell DSC will make sure the registry keys exist and that they are set the way I want them set. To be sure, I open Regedit to see if the keys were created. As you see here, they were:

Image of menu

That is all there is to using Windows PowerShell DSC to set registry keys and values. This also concludes Registry Week. Join me tomorrow when Microsoft PFE and Honorary Scripting Guy, Ian Farr, continues his RODC series.

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 

Comments (0)

Skip to main content