DSC - Configuration delivery modes

In the configuration management life cycle in DSC, configuration delivery plays a major role. Once a configuration is authored, a delivery mode helps to enact the configuration on the target systems. These modes dictate how the configuration is enforced and corrected, as required. DSC supports two types of delivery modes: Push and Pull.

PUSH mode

In the PUSH configuration delivery mode, the configuration to be enacted gets pushed to the node, whether it is local or remote. This is unidirectional and immediate. In a unidirectional mode the configuration is pushed from a management system to a target node. In push mode, the user initiates configuration processing via the Start-DscConfiguration cmdlet. This command immediately applies the configuration to the target, which can be specified by the -ComputerName parameter of the Start-DscConfiguration DSC cmdlet. By default, this cmdlet uses the files in the -Path folder to find the target node details and the configuration pushed to the node is enacted immediately.

The PUSH mode can be viewed as:

Note: Whether the target node is local or remote, it’s important to have the WinRM service up and running with the appropriate WinRM listeners.

Limitations of PUSH mode

The PUSH mode is easy to configure and use as it does not require any infrastructure services, such as a central shared location to host the configurations. However, the Push mode is not scalable. Pushing configuration to hundreds or thousands of systems would take quite long and can be limited, based on the resources available on the system on which the Start-DscConfiguration cmdlet is being run.

To enact configuration, we need all resource modules to be present on the target system. This represents another limitation of the Push mode. For example, if you have custom DSC resources used in a configuration script, the modules for these resources must be copied to target systems prior to pushing the configuration

PULL mode

Unlike the Push mode for configuration delivery, the Pull mode is bidirectional. This means that the pull server and the client both communicate with each other to manage the client configuration. In PULL mode the DSC Local Configuration Manager (LCM) can periodically poll a server for new configurations and keep the servers in compliance with the configuration and avoid drift. The Local Configuration Manager (LCM) of target node periodically performs a compliance check on the configuration of the node using a checksum on the MOF file. If the checksum is the same then nothing happens. Otherwise the LCM requests the new configuration and once it is transmitted to the client, the LCM executes it and also ensures that any missing resources that are part of the configuration is downloaded as well.

The PULL mode can be viewed as with the pull server configured to use SMB (Server Message Block)

To configure an SMB based pull server, you can use the New-SmbShare cmdlet to create a file share that can store the configuration and custom modules.

New-SmbShare -Name MySMBPullServer -Path E:\DSCShare -ReadAccess Everyone -Description "PULL server SMB"

Configuring the PULL client based on SMB

The download manager for SMB based pull clients is DSCFileDownloadManager. You can configure the LCM for SMB based pull clients by creating a configuration like and executing on the local machine

Configuration LCMSMBConfig {

                Node MyServer1 {

                                LocalConfigurationManager {

                                                ConfigurationID = '9C3DE0FC-FCB2-491F-B5EF-22DE7A368DE6'

                                                RefreshMode = "Pull"

                                                DownloadManagerName = "DscFileDownloadManager"

                                                DownloadManagerCustomData = @{SourcePath = "\\MyServer1\DSCResources"}

                                                ConfigurationModeFrequencyMins = 60

                                                RefreshFrequencyMins = 30

                                }

                }

}

LCMSMBConfig

Set-DscLocalConfigurationManager -Path .\LCMSMBConfig

Later when creating PULL configurations for the clients to react, you can use the GUID mentioned in the ConfiguationID property for the target machine as the Node value.

Desired State Configuration - Elements of the configuration

DSC is a feature built into the Windows Operating System. It’s based on the standards like CIMS and WS-Management remote management offered by the operating system. With DSC you can move to a way of configuration management where you can create a script that defines how the state of the server should be instead of defining how to make the server in the desired state. That means, DSC is more of a declarative syntax than an imperative one. This makes DSC scripts/ configurations easy to understand and maintain by the operations.

A sample DSC configuration for configuring the web applications in a SharePoint farm looks like:

Configuration SPSiteCollectionConfig {

    param($nodes)

    Import-DscResource -ModuleName xDSC_SPSiteCollection

    Import-DscResource -ModuleName xDSC_SPWebApplication

    Node ($nodes) {

        xSPWebApplication WebApplication{

            WebApplication = "WebApplication MYWebApp"

            Ensure = "On"

        }

       

        SPSiteCollection SiteCollection {           

            SiteUrl = 'http://MYWEBAPP.com/newSite'

            SiteName = 'New Site'

            SiteTemplate = 'BLANKINTERNET#2'

            ContentDatabaseName = 'CONTENT_NEWSite'

            Language = '1033'

            Ensure = 'Present'

            DependsOn = "[xSPWebApplication]WebApplication" 

        }

    }

}

SPSiteCollectionConfig

The  Configuration script start with a Configuration block which is used to give the configuration a meaningful name. The configuration keyword is the core component of DSC that defines the desired configuration of a target system. Following the Configuration keyword, the Node keyword is used to specify the target system/ systems on which the configuration should be applied by the LCM. You can also parameterize the values that are passed to the Node keyword if you want to decide the target systems at a later point of time. Later you can pass the target systems values to the configuration when you want to create a MOF file out of the configuration created.

Within the node is a state of a DSC Resource. The DSC resource module is what takes care of the how part of the configuration management. The DSC resource modules are implemented or written in imperative style, which means the resource module implements all the necessary details to manage the configuration settings of an entity. However, the DSC configuration makes it possible to abstract those imperative details from the end user, using a declarative configuration script.

We now have to translate that into a format that the DSC Local Configuration Manager or the DSC Engine can understand. This is the Managed Object Format (MOF) representation of the configuration script. We can generate the MOF representation of the configuration script by simply loading the configuration into memory and then calling the configuration. 

In our example we added the name of the configuration at the end of the script. This will ensure that the script when executed will generate the MOF files for each node and store it in the folder that has the same name as the configuration.

Once you have the MOF files generated you can execute them using the PUSH mode by calling the Start-DSCConfiguration cmdlet

Desired State Configuration - Introduction to CIM

PowerShell 4.0 introduces desired state configuration (DSC), a powerful new feature that makes it easier than ever to manage your Windows infrastructure, whether on premise or in the cloud. DSC is built on the Common Information Model (CIM) standard developed by the Desktop Management Task Force (DMTF) and uses Windows Remote Management (WinRM) technology as a communication mechanism. In this post we will look at what Windows Remote Management is and how it is used in the Windows OS world to enable standards-based management. In the upcoming posts I'll explain how CIM cmdlets in PowerShell use WinRM to work with management data from remote systems and the role of DSC in managing remote machines.

Windows Remote Management is the Microsoft implementation of the WS-Management Protocol. It uses SOAP (Simple Object Access Protocol) for exchanging control information and data between capable devices over HTTP and HTTPS. The main goal of WS-Management-based implementation is to provide a common way for these systems or components to access and exchange information.

The WinRM sevice enables remote management of windows systems. You can use the cmdlet given below to check the status of the service on the computer.

Get-Service -ComputerName 'MyComputerXXX' -Name WinRM

If the service is not enabled on the computer, you can create a listener based on HTTP or HTTPS protocol on the desired port. To setup a WinRM listener you can use the Set-WSManQuickConfig cmdlet. Once WinRM listener is set and working, you can use the infrastructure to access management information from remote servers.

The CIM cmdlets introduced as part of PowerShell 3.0 makes it easier to work with Windows Management Instrumentation.  CIM - Common Information Model is the DMTF standard for describing the structure and behavior of managed resources such as storage, network, or software components. The CIM standard defines two parts:

• Schema: Provides the actual model descriptions
• Infrastructure: Defines the standards for integrating multiple management models using OOPS constructs and design.

The CIM cmdlets support multiple ways of exploring WMI. They work well when you are working in an interactive fashion. For example, Tab expansion expands the namespace when you use the CIM cmdlets; thereby permitting exploring namespaces that might not otherwise be very discoverable. You can even use this technique to drill down into namespaces. For e.g if you want to find all the classes in the root/Microsoft namespace. use the cmdlet. You can try out tab completion after typing in the –Namespace option for the cmdlet.

Get-CimClass -Namespace root/Microsoft

To create an instance of a class, you can use the Get-CimInstance cmdlet. For example, the below given command, exposes all properties for the class MSFT_WmiError

Get-CimClass -ClassName MSFT_WmiError | ForEach-Object {$_.CimClassProperties}

You can also use the –ComputerName or –CimSession parameters to manage remote machines. Its recommended to use the CimSession and reuse the session if you are trying to perform a large set of operations on the remote server.

For e.g. you can use the commands given below to get the details of the processes running on the remote server:

$session = New-CimSession –ComputerName XXX

Get-CimInstance –ClassName Win32_Process –CimSession $session

Once we have the CIM sessions set up and the command execution is complete, we can remove the existing CIM sessions, by using the Remove-CimSession cmdlet.