PowerShell DSC – File Example – Lab Core

DSC, or Desired State Configuration, is a declarative platform in PowerShell that enables you to manage your IT and development infrastructure with configuration as code. What does that mean? Think…group policy, but using PowerShell. I’m not sure why Microsoft doesn’t describe it that way, but that’s exactly what it is. Scripts, configurations, and resources become solid-state or static, rather than dynamic.

Configurations are declarative PowerShell scripts which define and configure instances of resources. Upon running the configuration, DSC (and the resources being called by the configuration) will simply make it so, ensuring that the system exists in the state laid out by the configuration. DSC configurations are also idempotent (a fancy way of saying static): the Local Configuration Manager (LCM) will continue to ensure that machines are configured in whatever state the configuration declares. What does that mean? That means once the configuration has been started, you no longer have to keep checking on it; DSC takes over.

Resources are the make it so part of DSC. They contain the code that put and keep the target of a configuration in the specified state. Resources reside in PowerShell modules and can be written to model something as generic as a file or a Windows process, or as specific as an IIS server or a VM running in Azure.

The Local Configuration Manager (LCM) is the engine by which DSC facilitates the interaction between resources and configurations. The LCM regularly polls the system using the control flow implemented by resources to ensure that the state defined by a configuration is maintained. If the system is out of state, the LCM makes calls to the code in resources to make it so according to the configuration.

For example, you want to make sure a Windows feature is always enabled on your web server, that’s where DSC can help you. Let’s say, you want all client machines to have the same configs for a company application—and maintain those configs in a sort of permanent manner—it’s DSC to the rescue. On to our example…

Show more about DSC...

Using a DSC script, create a file in destination folder, start configuration, and view configuration.

The basic processing works like this:

make a declarative script > generate mof > apply mof > verify configuration is running

Code

Set-Location "C:\temp\"

# define configuration

configuration FileExample
{
Import-DscResource -ModuleName PSDesiredStateConfiguration

Node localhost
{

File FileExample
{
Ensure           = 'Present' # Present, Absent
Contents         = 'Config settings in file'
DestinationPath  = 'C:\temp\FileExample.txt'
Type             = 'File'

}
}
}

# create mof
FileExample

# load configuration from mof
Start-DscConfiguration -Path FileExample -ComputerName localhost -Wait -Verbose -Force

# check configuration
Get-DscConfiguration

Notes

Install-Module -Name PSDesiredStateConfiguration

winrm quickconfig

see PowerShell DSC – Registry Example

DSC mofs C:\Windows\System32\Configuration

Contents of the mof file

/*
@TargetNode='localhost'
@GeneratedBy=Homelab
@GenerationDate=04/15/2019 21:46:55
@GenerationHost=HOMELAB
*/

instance of MSFT_RegistryResource as $MSFT_RegistryResource1ref
{
ResourceID = "[Registry]RegistryExample";
ValueName = "ValueHere";
Key = "HKEY_LOCAL_MACHINE\\SOFTWARE\\ExampleKey";
Ensure = "Present";
SourceInfo = "C:\\temp\\reg_example.ps1::8::2::Registry";
ValueType = "String";
ModuleName = "PSDesiredStateConfiguration";
ValueData = {
"DataHere"
};

ModuleVersion = "1.0";

ConfigurationName = "RegistryExample";

};
instance of OMI_ConfigurationDocument

{
Version="2.0.0";

MinimumCompatibleVersion = "1.0.0";

CompatibleVersionAdditionalProperties= {"Omi_BaseResource:ConfigurationName"};

Author="Homelab";

GenerationDate="04/15/2019 21:46:55";

GenerationHost="HOMELAB";

Name="RegistryExample";

};