Creating configuration name configs


I had a DSC server configured to use ConfigID’s no problem. I’m transitioning to using configuration names since you can apparently apply multiple config names to a node. When I created my node config I had something like this:

configuration GenerateConfig {
[Parameter(Mandatory = $True)]

Import-DscResource -ModuleName xTimeZone

node $NodeGUID {

xTimeZone TimeZoneBrisbane
  TimeZone = "E. Australia Standard Time"
  IsSingleInstance = "Yes"


I then generated the node config by running

`Generateconfig -NodeGUID $GUID`

and copied the end result to the DSC configuration store and applied the ConfigID to the node.

Now with configuration names I can’t find any documentation on how to make the actual config?

Logically I would need to use the same method as ConfigID’s give or take but I am unclear what to do with this part of the configuration

configuration GenerateConfig {
[Parameter(Mandatory = $True)]

Import-DscResource -ModuleName xTimeZone

node $NodeGUID

Since I used to pass through the node/nodeGUID in to the config to ensure the config was going to the right now. What do I put there now that I am creating a config ID then just telling the LCM to look for a set of config names?

If anyone can shed some light on this or point me in the direction of some documentation on how to format a config for config names?

Any help would be appreciated.


Ok I probably should have guessed it works similar. Generate the config as localhost, copy to DSC config store, rename to the config name and generate a checksum. Would be nice if it just created the initial file with the name of the config name you specify instead of having to rename etc.

Another few questions it would seem. I read in the doco that the ConfigurationNames block can accept multiple config names but is that actually the case? Can you actually deploy multiple config names to a machine? Or is that only when using partial configs?

Also how do I retrieve information from the new report server? From the compliance server it was easy but for the new report server the documentation is… well I’ll say from my point of view not complete. It says there should be a PSDSCReportServer endpoint that can be queried but there wasn’t one created and the documentation which shows V2 WMF 5.0 pull servers doesn’t have any specific configuration like a compliance server did… However the database that it uses now appears to be quite different to the compliance server (there are alot more files in the directory that look much like a jet DB).

Is there actually any point in using config names? Should I just stick to configID’s and using a compliance server?

Hi Anthony,

  1. Docs say its an array (which made me very happy) but there’s a bug with it that as far as iknow has been reported to MS either in the github repo or on uservoice for powershell. Suggest you look it up there to see status. It’s also been discussed partially in this forum, try searching it up.

  2. If you look at the pull server online documentation, you’ll see an example of a pull server that has the ReportServerWeb block. If your script doesn’t include it, the reporting is turned off, so you have to actively add it. Note that there’s a different considerations if you’re using the same node as both the configuration and report or when you split the two to different nodes. You can find some reading on the “Where did the ComplianceServer go” post I did a few days ago, there are also links there to the online docs on how to extract the data.

  3. Yes there is a point. ConfigIDs and ComplianceServer are v4. If you currently have a working procedure dont change, yes the changes on the side, naturally.

As the new v5 becomes more mature, going for ConfigNames is the way forward. Going back to the “which made me happy” part in the first point. I’ve already set my environment to have about 10 mof files, created from several “templates” a.k.a. Configuration scripts, some for server OS (3 variations), some for SQL( 2 variations), some for IIS (2 variations) and some for specific server roles plus some for applications. Then all do is assign different configuration names combinations in the lcm script.
One node might be {“Base_Win2k12”,“IIS_1”,“MainApp”}
And another node will be

The number of variations you can have is endless but I dont think its good practice to have 1000 config mofs. You will probably find more posts about config names that I have taken part in, with some more food for thought.

Now just need them to fix things so I can go on with my plan to conquer the world with DSC :wink:

Hi Arie,

Thanks for that. That’s what I want to get out of multiple config names but when I tried to apply more than one it didn’t work. Good to know it’s a bug.

As for the report server I posted something on the github repo asking about it and it cleared up the confusion with the report server doco saying there should be a report server endpoint similar to the pull server.

So for now I’ll stick with the V2 configuration and just hold out until they fix the multiple config names issue and just have everything in the one MOF until I can split them up.