In the last time I have played heavily with Desired State Configuration.
So there comes up some questions.
The first Question is: How about scalability?
Is Desired State Configuration designed for the masses? Or only to use with a human manageable small amount of Servers?
In the following write up I use the term Configuration-function for the new PowerShell Keyword to make it different from the term configuration which is the current state of a system (node).
I don’t see any scalability in DSC. At the end of the road you always have a 1 to 1 relationship.
I know DSC is designed to use even outside of Active Directory in the cloud and with systems without Operating Systems like the BIOS but I speak here only for Systems with Operating Systems like Windows or Unix.
1.) Node to Pull-Server relationship
Every system (node) can only have 1 Pull-Server 1:1 .There is no concept like in Active Directory to use a group of Servers to serve the configurations.
What if you have 100000 Nodes do you like to maintain which Node should call which Pull-Server?
We probably could use the Netlogon share for a DSC-SMB-Pull-Server but we could not set the LCM to use the Netlogon of the next Domaincontroller.
2.) Configuration-function to .mof file to Node relationship
The Windows PowerShell Configuration-function is good at scale you can design one Configuration for one System (Node) and you have a 1:1 relationship , or you can design one Configuration-function to produce .mof files for many Systems (Nodes) and you have a 1:n relationship.
That is quite fine. But I don’t suggest to use the 1:n Configuration-function. Because one day you like to have one system out of all these systems to have a different config then another one and so on. So you have to change the 1:n Configuration-function every time. The 1:n Configuration-function grows and is cluttered up! This is very hard to maintain for a human being.
Here I suggest even to have always a 1:1 relationship and have one Configuration-function for one System (Node). Because at the end of the day the Node can only have one GUID.mof file on the PullServer and also a node can have only one Current configuration in the $env:systemRoot\system32\configuration folder.
So it is easy to maintain one Configuration-function for one GUID.mof file for one node 1:1:1.
3.) Current configuration to history relationship
Even if a node is in the Pull-mode you can create Push Configuration-functions to push Hotfix configurations to the Nodes with the –force parameter.
Or you have Administration colleges which do funny things and push configurations arround ;-).
So you have to watch yourself that the current configuration of the System (Node) is not drifted away from the desired configuration on the Pull Server. Because with that the current configuration of the Node has a different state then the desired configuration because bypass configurations were made.
Here we need a history mechanism to reproduce every step a node has made. With that history you can setup other systems equal to the current.
I hope my English was comprehensible to you! And my ideas too!
So where do you see scalability in Desired State Configuration ?