Do you think it would be a good or bad idea to use the AgentId of the LCM as the ConfigurationID, rather than generating a new GUID for the ConfigID? Furthermore, from a design point of view, why are both needed? Seems somewhat redundant.
AgentID is what’s reported to a Reporting Server. That’s part of the v5 world. ConfigurationID is part of the v4 world (although still supported). If you’re in a fully-v5 world, you would likely use configuration names to identify the MOFs the node should pull, and AgentID to track the node in the Reporting Server.
If I remember correctly the take-away from this years precon was to use GUID’s (ConfigurationID’s). I am kind of intrigued by the idea of using Configuration Names with partial configs. I remember Jason saying during that configuration names presently only supports an array of one. I have seen information on the technet blog suggesting the same thing as well. Yet the technet blog does have examples where the array has multiple configuration names being assigned like so:
[DscLocalConfigurationManager()]
Configuration PartialConfigDemoConfigNames
{
Settings
{
RefreshFrequencyMins = 30;
RefreshMode = "PULL";
ConfigurationMode ="ApplyAndAutocorrect";
AllowModuleOverwrite = $true;
RebootNodeIfNeeded = $true;
ConfigurationModeFrequencyMins = 60;
}
ConfigurationRepositoryWeb CONTOSO-PullSrv
{
ServerURL = 'https://CONTOSO-PullSrv:8080/PSDSCPullServer.svc'
RegistrationKey = 5b41f4e6-5e6d-45f5-8102-f2227468ef38
ConfigurationNames = @("OSInstall", "SharePointConfig")
}
PartialConfiguration Part1
{
Description = "OSInstall"
ConfigurationSource = @("[ConfigurationRepositoryWeb]CONTOSO-PullSrv")
}
PartialConfiguration SharePointConfig
{
Description = "SharePointConfig"
ConfigurationSource = @("[ConfigurationRepositoryWeb]CONTOSO-PullSrv")
DependsOn = '[PartialConfiguration]OSInstall'
}
}
Source: https://msdn.microsoft.com/en-us/powershell/dsc/partialconfigs
I haven’t tested it either way, but it would be pretty cool if that worked.
There are some downsides to partial configurations - like the fact that any problems don’t get unwound until they hit the node, which is the hardest place to troubleshoot and diagnose. Several of us - Steve, me, Jason - are recommending against partial configurations for now. What we’d rather see is a smarter Pull server, where the node can ask for ___ configurations, the Pull server assembles them and unwinds conflicting keys, and delivers a single MOF to the node. That would let you centralize any failures, and let you implement (potentially) more dynamically targeted MOFs (a la GPO) as well.
Switching from GUIDs to names also requires you to implement node registration keys (passwords) on the Pull server, so it’s an additional step.
Now that you mention it, I do recall Steve and Jason talking about that. Really wish I had audio or something from the event to refresh my memory. I do hope they come up with a solution that works. I think breaking down your configs into smaller more modular bits (i.e. baseline, Active Directory, Exchange, Sharepoint, etc.) makes a lot of sense.
I’m fairly certain we recorded that session. It’ll be on Youtube.
And composite configurations - versus partials - still offer a modular approach, as does simply using includes. All of which produce a single, conflict-free MOF at authoring time.
You can now use multiple values in the ConfigurationNames so the limit of one value has changed.
If you search this forum, you’ll see some of my and others earlier posts with more information that was discussed.
It works.
Although I agree with Don and others about the main issue with multiple configurations being pulled by a node
that you cant really tell what will happen until it reaches the final node, assembled and applied, I do think
its a method I would use in a pipeline in places where there’s more then one team writing configurations and adding
a good amount of tests on top of them to make sure that the entire Build and CI will do the checking before it reaches
the nodes.
You can use pester on the configurations prior to making them into mof files (that’s the Build step job), then deploy it to a test server and then use OVF to make sure that the server is at the state you wanted it to be.
Don is spot on about the desires to have a “Pull Server Mock” type where we can test the assembly of multiple configs
prior to them reaching the final node just to make sure it all works out. Not using multiple configurations just because
the fear of collisions between two configuration writers that dont communicate and use the same resource , say RegistryKey, one to turn it off and one to turn it on, is not a reason not to use them. It just means we need better communication, better design and better tools and understanding of the configuration writers.
This is exactly what happens in Dev world, when you have two teams writing their own implementations of say ActiveDirectory integration into their code. If both choose same namespaces, or same dll names, obviously something will not work.
You fix that with well documented procedures between teams and by using a central AD dll that say DevOPs team is responsible for and the rest just inherit that dependency.
As DSC has very limited Orcehstration abilities (DependsOn and WaitFor for cross-node), youll have to do all that outside of DSC and using multiple configurations is even harder then but if you maintain strict rules and force them as part of your pipeline and Build and CI, I think it will be a valuable ability.
Hello,
you wrote that multiple values in the ConfigurationNames are now working. Does it require some kind of update to enable this? I I use the release Version of WMF 5, but multiple configurations names are not accepted.
Thanks,
Frank
@Don - I thought the precon events would not be recorded. I didn’t attend the other DSC sessions, I am sure some of this was discussed in those sessions as well though.
@Arie - Thanks for the thorough reply.
We recorded two of the three - the videos are on YouTube. They weren’t “precon” sessions, just “full day.”
Ok, thanks.