allow DSC nodes to download meta configuration
when wmf4 initially launched, you could place meta.mof files into the pull server along side the default mof and both would be downloaded by the node and applied. This was rather ideal, as it meant I could create standard LCM configurations, and easily update/enforce them.
For some reason, this seems to no longer work in WMF5.0. This should be returned. Anyone who's had to edit the settings of hundreds (thousands?) of agents should understand it's way easier to tweak one property.
Real world example: ask anyone who's ever had to reconfigure the the SCCM agent cache. It's a needlessly complex process because the setting doesn't exist in the client profile.
I should not have to write custom module just to update the LCM of an agent when everything else is inplace
Thanks for you feedback! I What types of things do you find yourself needing to manage in the meta-config after initial deployment? This is not to take away from the need for this, I want to better understand how you and other customers are / want to use it.
Ryan Strope commented
Going to add my concurrence that this should be a thing.
I'm REALLY surprised that DSC can keep EVERYTHING else TIGHT and prevent configuration drift on EVERYTHING BUT DSC itself.
Another example (to add to others) would be taking a collection of clients pulling from a HTTP Pull Web Service and re-pointing them to an HTTPS Pull Web Service.
This definitely needs to be a thing and more people need to add their support to this feature suggestion
Flynn Bundy commented
Agreed on Configuration names being able to take an array of strings to represent which configs to pull.. It should be as simple as that.
Also, massive agree with being able to pull meta.mof files along with .mof files. We have a pipeline setup in which all meta.mofs and mof's get created in Appveyor and passed to the pull server, this works amazingly well with mof's because they just get dumped into the right location bto be pulled by nodes; its all ready to roll. WIth the meta.mof's though now we need to have a manual step (or adhoc script) run set-dsclocalconfigurationmanager on each new meta mof that appears. Just doesn't feel right.
Arie Heinrich commented
You got my vote Justin, but need to remoind you that at the moment ConfigurationNames only works on the initial registration of the node. If you want to change the ConfigurationNames values for a node you need to reregister it, which means you have to go for each node anyway and push the ne LCM (which is also why youve seen in your tests multiple DSC certificates on the node)
(im obviously not even talkign about the fact muliple values in ConfigurationNames is bugged according to another UserVoice, but hoping it will be fixed)
Justin King commented
Sorry to double respond, but let me throw an ideal scenario your way (at least to me):
I would love to be able to declare a meta-config just like I do other configs with ConfigurationNames. As simple as:
ConfigurationNames = @('meta.LA','BaseOS','SQLServer')
With that meta-config I could control all of Los Angeles so that when my boss says "rather than splitting out a dedicated reporting server or setting up a cluster, lets just drop the update frequency to every 4 hours" all I have to do is update that one configuration and I know all 200 servers will adjust. Or that annual "hey you know that DSC certificate we use to encrypt data? It's expiring, can you update all the servers ASAP?" .... yeah that's still just one edit of one file.
Justin King commented
There are a couple ways I'd like to use it. Ill try to list the most relevant:
1. Updating Pull Server information. Let's say, for whatever reason, I want to split the reportserverweb or want to add an additional configurationrepositoryweb. This could be for any reason from new dev-ops projects being spun up that want to push their own configurations to me deciding that a site has gotten big enough that I want to introduce a localized pull server.
2. Standardizing configurations. Right now with the metaconfig being "push only", there's no real way to enforce 15 minute refresh times, continueonreboot, debug mode ... anything. Instead the best I can do is create a custom script to "push" a new metaconfig out which seems silly in the face of the existing pull architecture. While "set locally" may make sense for settings like configurationnames, the general delivery infrastructure seems like something we should retain control of.
3. Certificate management. This last one is a bit more selfish example, but relevant. Right now I've written a custom module that uploads public certificate chains that meet a pre-defined criteria to a central file share. in WMF 4 I could then run a function that would dynamically read the thumbprint/filename and use that when encrypting the mof. Basically, as certs refreshed on a node, they got published ot a share ... so the next time I build a mof the "latest" cert was used and meta-config made along with it. Both would pull form the pull server and things functioned .. auto-renewing certificates completely hands-free. With meta-config downloads "broken" I now have to either manually manage all these certificates, or write _another_ custom module that kicks off a set-dsclocalconfiguration when it sees a change .... both of which are a lot of excess work considering it all "just worked" before.