The pull mode is desirable for many enterprises. While in pull mode, the Local Configuration Manager autonomously queries one or more pull servers for updated configurations, downloads them, and combines them with its Pending.mof.

At the time of writing, the pull mode has several, sometimes severe, drawbacks:

• The node status database can grow too large, bringing the pull server down.
• SQL Server cannot be used as a database without unsupported workarounds. These will be added in upcoming major versions of Windows Server.
• Reporting on the pull server is not possible without unsupported workarounds. These will be added in upcoming major versions of Windows Server.
• The pull server needs to be an IIS server.

To enable pull mode, you first of all need to set up a pull server. Fortunately, this can be done entirely with Desired State Configuration as well. You should keep the following prerequisites in mind when designing your pull server:

• One IIS host for ~1,000 nodes
• Enough free disk space—the local configuration database grows quickly
• The DSC-Service Windows feature needs to be enabled
• A new IIS site needs to be created to host the binaries

<#
Sample taken from https://github.com/AutomatedLab/AutomatedLab where
it is used to create DSC pull servers in a lab environment
#>

$ComputerName = 'PullServer01'
$CertificateThumbPrint = (Get-ChildItem Cert:LocalMachinemy -SSLServerAuthentication)[-1].Thumbprint
$RegistrationKey = (New-Guid).Guid

Configuration SetupDscPullServer
{
    param 
    ( 
        [string[]]$NodeName = 'localhost', 

        [ValidateNotNullOrEmpty()] 
        [string]$CertificateThumbPrint,

        [Parameter(Mandatory)]
        [ValidateNotNullOrEmpty()]
        [string] $RegistrationKey
    )

The first part of our code is just the initialization for our configuration. We are using parameters to make this configuration more generically usable. In the next code sample, you can see different portions of the configuration.

    Import-DSCResource -ModuleName xPSDesiredStateConfiguration, PSDesiredStateConfiguration

    Node $NodeName 
    { 
        WindowsFeature DSCServiceFeature
        { 

            Ensure = 'Present'
            Name = 'DSC-Service'
        }

Each node needs the Windows feature DSC-Service enabled in order to have all the necessary binaries to run the DSC pull server. This is used as a dependency to the community resource xDscWebService in the next code sample, with which we create the web site binding and the application pool in IIS.

# The module xPSDesiredStateConfiguration is used to create the
# pull server with the correct settings
xDscWebService PSDSCPullServer 
{ 
    Ensure = 'Present'
    EndpointName = 'PSDSCPullServer'
    Port = 8080
    PhysicalPath = "$env:SystemDriveinetpubPSDSCPullServer"
    CertificateThumbPrint = $certificateThumbPrint
    #CertificateThumbPrint = 'AllowUnencryptedTraffic'
    ModulePath = "$env:PROGRAMFILESWindowsPowerShellDscServiceModules"
    ConfigurationPath = "$env:PROGRAMFILESWindowsPowerShellDscServiceConfiguration"
     State = 'Started'
     UseSecurityBestPractices = $false
     DependsOn = '[WindowsFeature]DSCServiceFeature'
 }

Lastly, we want to allow nodes to perform a self-registration with the pull server by adding a registration key. By using a registration key, nodes can download configurations using a configuration name instead of a GUID. The registration key is used only once during the initial onboarding of a node. The following code sample completes our pull server configuration and used Start-DscConfiguration to apply the configuration via push.

File RegistrationKeyFile
{
   Ensure = 'Present'
   Type = 'File'
   DestinationPath =  "$env:ProgramFilesWindowsPowerShellDscServiceRegistrationKeys.txt"
            Contents = $RegistrationKey
        }
    }
}

SetupDscPullServer -CertificateThumbPrint $CertificateThumbPrint -RegistrationKey $RegistrationKey -NodeName $ComputerName -OutputPath C:Dsc | Out-Null

Start-DscConfiguration -Path C:Dsc -Wait

There are countless examples on the internet of how to create a pull server. The main thing to keep in mind is scaling. How many nodes will access your pull server? Do they need to be load-balanced? If so, you need to replicate the local database or configure a SQL Always On cluster—but wait, SQL is not supported yet.

There are also some open source developments taking place that implement the DSC pull server and provide all of the necessary APIs. Most notably, there are Tug and TRÆK. Both have different approaches. Tug is supposed to be more or less a replacement for the built-in pull server, but rarely gets updated. TRÆK is based on Node.js and employs multiple microservices:

# Prepare configurations for the pull clients
configuration HostedConfig1
{
    node localhost
    {
        File Pulled
        {
            DestinationPath = 'C:File'
            Contents = 'Pulled from elsewhere'
        }
    }
}
HostedConfig1

Rename-Item .HostedConfig1localhost.mof -NewName HostedConfig1.mof

# Place the configurations in the correct folder and generate checksums automatically
Publish-DscModuleAndMof -Source .HostedConfig1

To enable your nodes to pull from a pull server, the server needs to know both the modules used and the configurations for each node:

# After the pull server is configured, new clients can receive the pull configuration
[DscLocalConfigurationManager()]
configuration MetaConfig
{
    param
    (
        [string[]]$ComputerName,

        $PullServerFqdn,

        $RegistrationKey
    )

    node $ComputerName
    {
        Settings
        {
            RefreshMode = 'Pull'
        }

        ConfigurationRepositoryWeb IIS
        {
            ServerURL = "https://$($PullServerFqdn):8080/PSDSCPullServer.svc"
            RegistrationKey = $RegistrationKey
            ConfigurationNames = 'HostedConfig1'
        }
    }
}
MetaConfig -ComputerName DscNode01 -PullServerFqdn $ComputerName -RegistrationKey $RegistrationKey

Set-DscLocalConfigurationManager -Path .MetaConfig -Verbose
Update-DscConfiguration -CimSession DscNode01 -Wait -Verbose

The Update-DscConfiguration cmdlet can be triggered at any time to request updated configuration data from the pull server. Apart from that, the refresh mode interval configured for the LCM is the governing setting. The LCM can pull at most every thirty minutes, which is also the default value.