GUID Query

When setting up a pull server & pull node, I have to name my generated MOFs a valid GUID (Generated by [guid]::NewGuid()) and then point the associated node to this GUID. But does this mean that whenever I update my configuration, and therefore generated MOF, I have to keep at GUID the same to ensure that the clients receive the updated version? Otherwise, if I generate a new GUID each time and pass the settings to the nodes, I might as well just use the push method instead of pull.

I’ve thrown together the following script that homes 2 functions - one to rename a MOF file, move it to the DSC store and to create a checksum; the other to pass settings to a server’s DSCLocalConfigurationManager (Basically set a server up as a pull node). Gist.

Thanks in advance for any answers!

Short answer is you’re absolutely right: you must continue to use the same GUID you configured your node with, it looks for that GUID.mof on the pull server.

If it helps in my lab I have a simple module with functions that track GUID and thumbprints in a small csv file so it can transform the configuration data on the fly (converts nodename from “friendly” to “GUID” and adds thumbprint and cert path information).

Blog describing it (with github link to modules)

(Yeah I need to do a better job in the functions so get-help works better, but this resource is early)

as you already have a pull server you can just grab my “DSCManager” resource and sample build-and-deploy scripts and see if any of it helps you out. Basically R&D it: Rip off and Deploy :slight_smile:

Yes you need to (and should) keep the same GUID. What I do is query AD to get the AD GUID for the server/node the be configured and use that. This does two things for me:

  1. I get a unique idenifier
  2. It makes it much easier to identify which GUID.mof is for which node.

I found this code online and tailored it to my use, feel free to do the same:
Query’s AD

#Pull computer objects for AD
function GetComputers {
    import-module ActiveDirectory
    Get-ADComputer -SearchBase "OU=DSC Managed Nodes,OU=SERVERS,OU=NYC,OU=Americas,DC=testlab1,DC=test,DC=com" -Filter *
$computers = GetComputers

#Pull list of computers and GUIDs into hash table
$ConfigData = @{
    AllNodes = @(
        foreach ($node in $computers) {
            @{NodeName = $node.Name; NodeGUID = $node.objectGUID;}

Takes the Generated MOF and changes to the GUID.mof

TestConfig -ConfigurationData $ConfigData -OutputPath "$Env:Temp\TestConfig"
write-host "Creating checksums..."
New-DSCCheckSum -ConfigurationPath "$Env:Temp\TestConfig" -OutPath "$Env:Temp\TestConfig" -Verbose -Force

write-host "Copying configurations to pull service configuration store..."
$SourceFiles = "$Env:Temp\TestConfig\*.mof*"
$TargetFiles = "$env:SystemDrive\Program Files\WindowsPowershell\DscService\Configuration"
Move-Item $SourceFiles $TargetFiles -Force
Remove-Item "$Env:Temp\TestConfig\"

configures the node LCM

Configuration ConfigurationForPull
    Node $allnodes.NodeName
            ConfigurationID = "$($Node.NodeGUID)"
            RefreshMode = "PULL";
            DownloadManagerName = "WebDownloadManager";
            RebootNodeIfNeeded = $true;
            RefreshFrequencyMins = 30;
            ConfigurationModeFrequencyMins = 15; 
            ConfigurationMode = "ApplyAndAutoCorrect";
            DownloadManagerCustomData = @{ServerUrl = "http://lab-dsc-01:8080/PSDSCPullServer.svc"; AllowUnsecureConnection = “TRUE”}

ConfigurationForPull -ConfigurationData $ConfigData -OutputPath "$Env:Temp\PullDSCCfg"
Set-DscLocalConfigurationManager -Path "$Env:Temp\PullDSCCfg" -verbose

Thanks for the feedback!

After a bit more tinkering and reading, I came to the conclusion that I’d have to retain the same GUID, so as I began creating some helper functions, I did exactly as Justin later suggested in his reply, and I now track them in a CSV file. Once I get my DSC pull server working, I’ll switch to a certificate and I’ll also track the thumbprint too (and I’ll probably track a few more bits of info once I get it all up and running).

Regarding Ed’s comment, that’s a brilliant idea, to getting the GUIDs from AD, and I’ll probably go ahead and start using this a bit later.

I did have a bit of a headache as I had no idea why my config wasn’t getting pulled / applied… Then I read the logs, and realised I needed to reboot. Duh.

My only word of warning about using the GUID from AD: that’s going to fall flat if a box is in work-group mode (like in a DMZ) or if you want to be able change domain membership. So think ahead a bit now on how likely/unlikely those scenarios are.

Little more work upfront to track GUID info independent of AD may be worth it, or it may be wasted effort. That’s your call.