Using AgentId

This topic contains 10 replies, has 4 voices, and was last updated by Profile photo of Stefan Werner Stefan Werner 5 months, 2 weeks ago.

  • Author
    Posts
  • #43132
    Profile photo of Stefan Werner
    Stefan Werner
    Participant

    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.

  • #43299
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #43587
    Profile photo of Stefan Werner
    Stefan Werner
    Participant

    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.

    • This reply was modified 5 months, 2 weeks ago by Profile photo of Stefan Werner Stefan Werner.
  • #43590
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #43605
    Profile photo of Stefan Werner
    Stefan Werner
    Participant

    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.

  • #43609
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

    • #43952
      Profile photo of Stefan Werner
      Stefan Werner
      Participant

      @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.

      • This reply was modified 5 months, 2 weeks ago by Profile photo of Stefan Werner Stefan Werner.
  • #43736
    Profile photo of Arie H
    Arie H
    Participant

    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.

    • #43944
      Profile photo of Frank Wagner
      Frank Wagner
      Participant

      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

  • #43955
    Profile photo of Don Jones
    Don Jones
    Keymaster

    We recorded two of the three – the videos are on YouTube. They weren't "precon" sessions, just "full day."

  • #43995
    Profile photo of Stefan Werner
    Stefan Werner
    Participant

    Ok, thanks.

You must be logged in to reply to this topic.