How can you change AgentId?

DSC
1

The following announcement for WMF 5 indicates that it is possible to assign a “human readable AgentId” to a node

https://powershell.org/2015/06/02/major-changes-to-dsc-pull-server-configuration-ids/

How can that be done? I have tried the following configuration

    Node $NodeName
    {
		Settings
		{
			AgentId = $NodeName
			RefreshMode = 'Pull'
			RefreshFrequencyMins = 30
			RebootNodeIfNeeded = $true
			ActionAfterReboot = 'ContinueConfiguration'
		}
		ConfigurationRepositoryWeb PullSrv
		{
			ServerURL = 'http://mypullserver:8080/PSDSCPullServer.svc'
			RegistrationKey = 'xxxx-xxx-xxx-xxxx-xxxx'
			ConfigurationNames = @('MyConfig')
			AllowUnsecureConnection = $true
		}
    }

and the mof fails to compile with the following:

The member 'AgentId' is not valid. Valid members are
'ActionAfterReboot', 'AllowModuleOverwrite', 'CertificateID', 'ConfigurationDownloadManagers', 'ConfigurationID', 'ConfigurationMode', 'ConfigurationModeFrequencyMins', 'Credential', 'DebugMode',
'DownloadManagerCustomData', 'DownloadManagerName', 'PartialConfigurations', 'RebootNodeIfNeeded', 'RefreshFrequencyMins', 'RefreshMode', 'ReportManagers', 'ResourceModuleManagers', 'StatusRetentionTimeInDays'.

The mof does compile if I remove AgentId. So how can I assign one?

2

So, reading the source at How to register a node with a DSC pull server - PowerShell Team, I don’t see where they said you can set an AgentId. They talk about human-readable ConfigurationIDs.

3

I guess I’m questioning the first point that you made in the article I linked to in the OP

Nodes can now be assigned a human-meaningful AgentID. This is unique per node, and allows the node to uniquely identify itself to the pull server for reporting purposes, regardless of what configuration the node is pulling.

I could not find a way to do that even tho you say it’s possible in that post?

4

Why would I need to do this? Well, in the spirit of Cattle Not Pets, I have a Xen VM template that I preconfigured to connect to a Pull Server and use a well known named DSC configuration. The template is also sysprep’d to automatically join the AD domain on “Firstboot” and AD will assign them a random name on firstboot.

After they complete the firstboot the VMs connect to the DSC server and configure themselves as Jenkins agents. Initially, I don’t want (or need) to know their names or IP addresses: they all automatically join the Jenkins cluster and I’m happy. This is truely hands off provisioning.

However, I would like to introduce a DSC reporting server and be able to query the DSC state of individual agents. To do this each VM will need an individual DSC AgentId. I can tell there is a chicken and egg scenario here, so I was going to write a script that would remotely reconfigure an agent once I do know it’s name (I can get the VM names via a Xen API call).

But if I can’t change the AgentId after, then I can’t see how to achive this…

5

At How to register a node with a DSC pull server - PowerShell Team, I literally searched the page for the word “meaningful” and am not seeing it. Nor the word “human.” So I’m not seeing “Nodes can now be assigned a human-meaningful AgentID. This is unique per node, and allows the node to uniquely identify itself to the pull server for reporting purposes, regardless of what configuration the node is pulling.”

I appreciate what you’re wanting to do; I think a better approach would be to write a resource so that each node can register its AgentId in some central database. You can then use that to maintain “mappings.” Periodically scavenge stale records and it becomes self-maintaining.

6

What’s letting me down is that I have configured the LCM before I sysprep’d the image and converted it to a template. Thus every node has the same AgentId, so registering in a central DB as you suggest would not work either.

What I could do is to have a RunOnce script that would configure the LCM of the newly spawned node on first boot. (the report server then acts as the central database as you suggest). I just wanted to exhaust the other options first.

Don’t get me wrong, I’m not holding you to account for this - I’m just trying to reconcile statements that I find on the web that may indicate I am doing something wrong. (Perhaps you could update your original “Major Changes…” article to remove the human readble AgentId statement?)

Overall, I am coming to the conclusion that despite DSC having gone through a number of major releases, it is still somewhat clunky and still needs to mature to get to a point where we don’t need to write all the extra stuff to get it to fit our desired DevOps practices.