4

I am currently building a lab environment to get a feeling on what DSC can accomplish and where the limits are.

We have a requirement to push out one-shot configurations to group of nodes based on criterias like operating system, AD group membership and OUs containing the targets.

So I developed the following exemplary script: 

# Pulls computer objects from Active Directory
Function Get-Nodes
{
    Param($OperatingSystem)

    Get-AdComputer -Filter 'OperatingSystem -eq ${OperatingSystem}' -SearchBase "OU=SomeThing,DC=contoso,DC=com"
}

# Defines the configuration to apply
Configuration ConfigureHostsPush 
{
    Node $Allnodes.NodeName
    {
        # This resource is not able to delete a key, only values 
        Registry ConfigureRegistry
        {
            Ensure = "Present"
            Key = "HKEY_LOCAL_MACHINE\SOFTWARE\"
            ValueName = "MachineType"
            ValueData = "Hyper-V"
        }

        # This logs the defined message at the _destination_ host
        # within Microsoft->Windows->DesiredStateConfiguration->Analytic
        # requires showing and enabling the log first!
        Log LogSuccessfulRegistry
        {
            Message = "Successfully configued the defined registry value"
            DependsOn = "[Registry]ConfigureRegistry"
        }
    }
}

$nodes = Get-Nodes -OperatingSystem "Windows Server 2012 R2 Standard"
# $nodes = Get-Nodes -OperatingSystem "Windows Server 2008 R2 Standard"
# $nodes = Get-Nodes -OperatingSystem "Windows 7 Professional"

# Pulls a list of nodes into a hash table
$ConfigData = @{
    AllNodes = @(
        foreach ($node in $nodes)
        {
            @{NodeName = $node.Name}
        }
    )
}

# Generate the MOFs based on the configuration and hosts pulled from AD
ConfigureHostsPush -ConfigurationData $ConfigData

# Actually push out the configuration to the nodes
Start-DscConfiguration -wait -Path D:\DATA\DSC\ConfigureHostsPush

However some of the nodes are not always reachable and are offline in my case. How should I do the error handling and logging? So I can later on control which nodes got successfully configured or needs reconfiguration.

I know I can use the DSC log resource, but that seems to be pretty limited and only generates logs on the LCM/target node side.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Matthias Güntert
  • 2,438
  • 12
  • 39
  • 59
  • 1
    Is `Start-DscConfiguration` throwing exceptions? If so, you can catch those and log relevant information. If it's too difficult to tell which node is being worked on, you might change your directory structure so that there's a directory for each node which contains its configuration. Then in code you iterate and call `Start-DscConfiguration` for each node so that you can catch exceptions pertaining to an individual node. – briantist Nov 18 '14 at 14:42
  • 3
    One of the advantages of DSC is that the configurations are idempotent; I think the general idea is that you just re-run the configuration against all nodes at whatever frequency you deem appropriate, and they should eventually all get into compliance. – jbsmith Nov 18 '14 at 22:37
  • Thanks for replying. But then I would need some mechanismn that regularily pushes out the configurations to the nodes from a mgmt server (e.g. via task scheduler). That seems to be pretty impractical from an administrative point of view. Remeber, we are still talking about push-operations. Am I missing something? – Matthias Güntert Nov 19 '14 at 07:44
  • No, I don't think you're missing anything; but my understanding is that the pull model is the expected use case, where the nodes will be checking and re-applying their configurations regularly. – jbsmith Nov 19 '14 at 21:21

1 Answers1

0

One approach would be to just not keep track. Just place all your mof files in one folder and have a scheduled task run twice a day that pushes them to your nodes. That would be very easy to set up and manage. Set it and forget it.

The expected use case is to set up a pull server. You still have to configure each node to talk to the pull server. Because the nodes have to check in with the pull server, you do have a central location that tells you if a node checked in and is configured correctly. You can also change the configuration on a pull server and the node will get it when it checks in next. You don't have to babysit the push process.

You will face your biggest issues at the start trying to get all your existing servers configured. But going forward, deploying a new server will be in a state you can closely manage during the provisioning process.

kevmar
  • 141
  • 2