Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.
 

Using the Script Desired State Configuration (DSC) Resource

By - Source: Toms IT Pro

What do you do when there's no pre-packaged DSC resource for your needs? You create your own. Here's how.

Microsoft and the community have done a great job at providing DSC resources to do some things. In the box, we've got dozens of resources and taking a look at all of the resources provided by Microsoft on their Github repo can make you think why on earth would I need my own resource?

The truth is, even though Microsft themselves and the community, through the PowerShell Gallery, has published hundreds of resources, there are still going to be times when a pre-packaged DSC resource does not exist. When faced with no existing resources to do what you need to do, you've got two options; create your own resource or create a script resource.

MORE: Windows 10 Fall Creators Update: What You Need to Know

If the resource needed is planned to be a part of a script that's going to be around for awhile, it's recommended just to create your own DSC resource. Multiple advantages come with that, but it does have a learning curve. Also, if you simply need to run some code as part of a DSC configuration and don't see the need to spend the time to create an entire resource, the script resource is always there.

The DSC script resource can be thought of as a "generic" resource. The script resource is essentially a way to inject arbitrary code into a resource without worrying about how to create a "real" resource. The script resource comes installed by default with PowerShell and comes with three properties; GetScript, SetScript and TestScript. You may notice that these coincide with the typical Get, Set and Test properties that must be defined when creating a DSC resource from scratch.

PS> Get-DscResource -Name Script -Syntax



Script [String] #ResourceName

{

    GetScript = [string]

    SetScript = [string]

    TestScript = [string]

    [Credential = [PSCredential]]

    [DependsOn = [string[]]]

    [PsDscRunAsCredential = [PSCredential]]

}

To use the script resource, we need to create some PowerShell code to be used for each of the properties. It doesn't matter what the code is but each property's code has to return a particular type. To demonstrate, let's go over a script resource to enable the Windows firewall.

```PowerShell Configuration EnableWindowsFirewall { Import-DscResource -ModuleName PSDesiredStateConfiguration Node localhost { Script EnableFirewall { # Must return a hashtable with at least one key # named 'Result' of type String GetScript = { Return @{ Result = [string]$(netsh advfirewall show allprofiles) } }

        # Must return a boolean: $true or $false

       TestScript = {

            If ((netsh advfirewall show allprofiles) -like "State*off*") {

                Write-Verbose "One or more firewall profiles are off"

                Return $false

           } Else {

                Write-Verbose "All firewall profiles are on"

                Return $true

            }

        }



        # Returns nothing

        SetScript = {

            Write-Verbose "Setting all firewall profiles to on"

            netsh advfirewall set allprofiles state on

        }

    }

}
} ```

Notice that the GetScript property contains whatever code is necessary to find the current state of whatever you're trying to do. The GetScript property's scriptblock must return a hashtable with at least a single key called Result. This, however, is not used when invoking the DSC configuration.

Next is the TestScript property. Again, this is a scriptblock that contains the code to test if the state is in compliance. This code should return $true if the machine is in compliance or $false if it is not.

Finally, we have SetScript which makes the actual change. This property should return nothing and will contain the scriptblock to force TestScript to return $true.

The concept of a script resource is similar to a "real" DSC resource. The big difference is that you can define arbitrary code to a property. It may not be obvious at first, but as you continue to create more script resources, you'll find that if you begin to rely on script resources for more advanced scenarios, the complexity involved in maintaining these resources will be much greater than creating a "real" resource to begin with.

Comments