I think the design, to use a Function like construct, to create a PowerShell DSC is bad, because it has a different behavior like the other PowerShell use cases.
During the compilation process we have no control over the process!
If you Write a Configuration Function with the keyword Configuration, you have to run this Function (once) to compile it to a MOF File.
The MOF File is generated automatically in the same Path with the same Name like the source code File of the Configuration Function or somewhere in the %windir%\System32 Path.
It is not possible to dictate the destination path of the resulting MOF file, the name or other parameters of the process.
(The automatically generated Names are silly non speaking names)
I think it is better to use a New-DSCConfiguration Cmdlet instead of the Configuration Function.
The body of the Configuration Function can be provided to the New-DSCConfiguration Cmdlet as an scriptblock.
With a New-DSCConfiguration Cmdlet you can provide the destination path or other parameters to compile the MOF file.
(for possible Parameters See mofcomp.exe http://msdn.microsoft.com/en-us/library/aa392389(v=vs.85).aspx)
I think a New-DSCConfiguration Cmdlet goes the PowerShell way to take such actions like creating a File or compiling something. and it adds control to compile /creation the process
Example of a possible New-DSCConfiguration Cmdlet:
A Configuration block can have zero or more Node blocks
Node “Server001”
{
# Next, specify one or more resource blocks
# WindowsFeature is one of the built-in resources you can use in a Node block
# This example ensures the Web Server (IIS) role is installed
WindowsFeature MyRoleExample
{
Ensure = "Present" # To uninstall the role, set Ensure to "Absent"
Name = "Web-Server"
}
# File is a built-in resource you can use to manage files and directories
# This example ensures files from the source directory are present in the destination directory
File MyFileExample
{
Ensure = "Present" # You can also set Ensure to "Absent"
Type = "Directory“ # Default is “Fileâ€
Recurse = $true
SourcePath = $WebsiteFilePath # This is a path that has web files
DestinationPath = "C:\inetpub\wwwroot" # The path where we want to ensure the web files are present
Requires = "[WindowsFeature]MyRoleExample" # This ensures that MyRoleExample completes successfully before this block runs
}
I suspect it’s a little late to get major architectural changes on a released product - during beta would have been a good time for that. But, good luck!
I thought the “configuration” construct felt a little weird and inconsistent as well, but it’s not difficult to use, either. You could always write your own function to wrap that functionality and behave like a cmdlet. Take the ScriptBlock (or string, whatever), use it to build a string containing a valid “configuration” block, execute it with Invoke-Expression, and clean up when you’re done.
@Don Yes you are right I am lat but it is never too late ;-))
@Dave Thank you for this great idea! But even this workaround is not very satisfing… and how canm I control the compile process?
I think the PowerShell usabillity shoud stay consistent the PowerShell syntax is ugly enough. On this way PowerShell is goinge havier to use and looks like an old ugly patchwork with moth holes… ;-))
Just a point of order… you can change the destination of the output files with the outputpath parameter, but it uses your current working directory by default.
I’m not quite sure I agree with your concept. One of the reasons (this is my inferring based on use, not actual knowledge nor am I speaking on behalf of MS) for the configuration style we see is that configurations are compose-able. One configuration can leverage another configuration like a resource, so you can package common commands together, to more easily create dependency chains, etc… I’ll be covering some of this in my next post. Another reason is that you can parameterize your configurations, so you can use external data to drive the creation of the configurations. I’ll try to show some examples in my next post.
@Peter, What do you mean by “control the compile process”? A running the configuration “compiles” it and you have as much control as any PowerShell script… Maybe you could clarify what you are looking for?
The invocation of the Configure Function produces a MOF File. I have no control over the destination or the Name of the Product (result) of the invocation!
Even I have no control over the compile process!
please see : http://en.wikipedia.org/wiki/Compiler
Wikipedia excerpt: A compiler is a computer program that transforms source code written in a programming language (the source language) into another computer language (the target language).
The source is here the PowerShell language the Target is the MOF language.
Compiling is absolutely what is going on in the moment of the invocation of the Configure Function.
If you look at the compiler Programs in the world you see only a few without parameters.
I like to have control over the compile process to dictate how the result should look like!
The first things I have found as candidates for Parameters are destination and Name of the MOF file.
Do you have taken a look at the mofcomp.exe ?
If you take a look at the mofcomp.exe you see which parameters are perhaps possible : http://msdn.microsoft.com/en-us/library/aa392389%28v=vs.85%29.aspx
Without Parameters you did not have any influence over the compile process or how the Product should look!
@Peter - but you do have parameters… there are some default parameters for configurations and you can add your own to be used in the compilation process. As I stated for the output location, there is the outputpath parameter and the file naming is based on the node name. You have complete control of all you asked about.
In addition to being able to declare your own parameters, there is the configurationdata convention which you can use to pass in environmental data to the configuration. If you want to pass in a filename/node name, you could do something like
e.g.
configuration test
{
param ($Node)
Node $Node
{
…
}
}
Between that and -outputpath that should cover your being able to target where and how files are named/created. You can create/pass in whatever other parameters you would like… it really is a like powershell function with some additional semantics around node declarations and a convention around a configurationdata hashtable.
Even there is not showed where to place the parameter (or it is a hidden common parameter).
This is the bad design what I am complaining about Functions with easter egg equipment
Cmdlets have a better documentation (process) then functions.
So I understand now for the destination we can use the hidden outpath parameter.
Unfortunately the to MOF compile process is not documented.
So what is with the names of the MOF files. They are produced automatically by serial numbering.
This results in non speaking names. (I don want to use the term “ugly” again here )
If I understand the DSC documentation and my experience results correct, the compile Process produces for any Node Name a separate MOF file.
If you have more then one Node block in the configuration Function with the same Node Name, the Names of the MOF Files receive automatically generated serial numbers.
So I Think for the MOF file names we need a mechanism on the Nodes keyword to create speaking MOF file names!?
If you have such speaking Names you can Transfer and reuse the MOF files to other configurations without recompiling.
I do not have a Win 8.1 or a 2012R2 at hand now. I will investigate this deeper in a few hours at home. so stay tuned …
If you are using the push model, nodes should be labled with the server name. If you are using a pull configuration, nodes are labeled with a GUID that you define. Why does it matter what the label on the mof file looks like? It’s only for matching up what node a configuration should target. The problem with using server name alone is that server names do not need to be unique
OutputPath is not a hidden parameter, it’s a default parameter for any configuration. If run get-command or get-help against a configuration, you’ll see it there.
Regarding naming the node, yes we most definitely do. That’s how configurations get targeted. You don’t have to do a 1 to 1 thing, you can provide a node an array of names to replicate that node for multiple targets.
Yes that is what I mean with deeper investigation.
Sometimes my fault is to complain before think …
Ii i understand DSC correct. At the and only the MOF files are executed.
If you have speaking Names for MOF files, you can Transfer and reuse the MOF files to other configurations without recompiling. Even for more then one targets.
I understand your desire to reuse MOFs for multiple targets… depending on how you go about it, there are ways to do that.
If you use the pull server, you can give as many nodes as you want use the same guid to pull configurations.
In the push case, you can name it localhost.mof and push it locally to remote computers and run it that way.
I tend to prefer the pull configuration and there are way to force a pull on demand. As you get in to building more configurations, I think you’ll find it not as limiting as you might think. I’m currently using it to manage most of servers in one data center… I don’t really have to look at the generated MOFs after I created a build script, I let the client nodes deal with those after I run my build script (or my build server does).
and how canm I control the compile process?