Change the way ConfigurationNames works to accomodate easy management and software provisioning
TL&DR - Make ConfigurationNames accept multiple values and Accept changes to the values of ConfigurationNames in a Live manner and not just for the initital regisration of the node.
Today ConfiguratioNames is used on the initial regsitration of the node. Althugh it can accept an array, it wont work with more then one value and issue errors. That value is basically the name of the mof file on the pull server. This allows for friendly names of mof files while still maintaining uniqness of the nodes for reporting purposes that wasnt available in ps v4 using the same GUID.
Everytime i want to make a change to some nodes that share the same ConfigurationName, i just make sure to name the new mof to use has the same value of the ConfigurationNames.
Rarely would you see servers that are twins. Mostly they will share basic infrastructure but then will differ when it comes to software installed.
Both the old way and the new way of registrations, are not helping in software provisioning. I still need almost a mof per node to describe the software installed on the node. I would suggest a different method of using ConfigurationNames that in essence is similar to PartialConfigurations.
Make ConfigurationNames accept multiple Values
Building several mof files, each for a specific unit of configration.
One will be for example - Getting IP address, Setting Computer Name, installing antivirus client package. Create a mof and call it BaseOS.mof.
Create one that will describe an IIS with only Basic Authentication and NET 4.5 and one with Windows authentication only and NET 4.6, calling them IIS1.mof and IIS2.mof
Create one that will describe a SQL Server with a certain Collation and one with a different Collation, calling them SQL1.mof and SQL2.mof.
Naturally the method to create the mofs is dependant on everyones favourite way but its now easier to go to one node and set its LCM ConfiguratioNames to "BaseOS, IIS1", a second Node to "BaseOS, SQL2" and the likes.
I can still have several nodes set to the same combination of ConfigurationNames if required.
IF the node hosting IIS1 requires aditional settings, i can either create a new mof file with the new settings, understanding that ALL the nodes that are based on IIS1 will get it as well OR create a new mof called IIS_3 and just change the LCM on that specifc node to point to the new mof, which leads to the next point.
This doesnt stop with IIS or SQL as i can do that same with applications, say for example 2 websites, i can create 2 mof files, one for each application, calling them APP1 and APP2 and simply assing them to the node i want them to be installed on.
- Accept Changes to ConfigrationNames not just for the initial registration
By allowing a change to the ConfigurationNames to be handled in a "live" manner, i can at any time assign nodes to different ConfigurationNames combinations. I dont have to do anything on the pull server, unless of course i need a new variation of exiting mofs like the example in previous point.
Overall it will give more agility in the assignment and less mof files on the pull server. It more alligns with the idea of reusing existing components.
Yes, you can do all this outside the LCM, create a big configuration script automatically from an extrenal managment system that combines all the content of BaseOS and IIS1 and App1 into one file and then create one mof Calling it MyServer.mof and setting All the LCMs on all the nodes to point to MyServer in the ConfigurationNames. How easy is it now to say i dont want APP1 to be on one or all of those nodes, i want APP2. This will require a new process of assembling a big configuration script and creating a mof and pushing it to the approrpate nodes. Doable - yes. Easy - compared to changing the LCM to a new ConfiguratioNames combo - no.
The same caveat that exists in PartialConfigurations still exists here, the mofs are combined on the node and processed so unit testing is harder as it doesnt test the integration of all the parts, something that is doable on a big configuration script, that i have to say.