New here and this site seems to be the best resource on Powershell DSC.
We are currently in the process of creating cloud tooling for our software packages. We are busy testing Azure DSC and written quite a bit of Composite resources.
The problem is that Composite resources are not really reported on at all. The only thing you can really see is the physical resources that the Composite used.
For example I would have a composite resource that calls the file and xSmbShare resources and all that would be reported on is those specific resources.
If you then click on the resource it give you this: PackageFolder::[cPackageTestResc and the details page would give you version details of the xSmbShare module.
Is there a way to have the Composite Resource report more details into Azure, or if this is not possible can you write a normal DSC resource that makes use of other DSC resources?
Hi there Gert,
I’m trying to visualize how you’d like to see this reporting. Are you saying that you’d like the top level report to separate the resources by composite? Something like:
Also, there’s the Export-AzureRmAutomationDscNodeReportContent command that allows you to get the raw content of reporting. It’s not the best, as it downloads a txt file to your present working directory or specified path. And you also have to do your own manipulation to make it readable, but you can get the granular reporting from there.
Export-AzureRmAutomationDscNodeReportContent -NodeId $NodeReport.NodeId -ReportId $NodeReport.Id -ResourceGroupName $NodeReport.ResourceGroupName -AutomationAccountName $NodeReport.AutomationAccountName
Thanks you for the quick response.
I think your First post is a good start but also if I can list maybe the Composite version number etc.
Thanks I will look at your command but it needs to be GUI driven from our Azure Portal at least so our consultants and customer can see what version of the composite module is running for example.
TL;DR - this isn’t actually AADSC’s fault.
I’m going to reach out for verification on this, because this is based on my observations.
First off, the raw reporting you get from AADSC is based on the reporting output from the DSC LCM on the local machine. If you were to look through how the LCM processes this, it doesn’t output the version of the composite resource either. This is because even though you are uploading the configuration as a module, it’s not really.
When DSC (regardless if it’s the AADSC node or a push server) compiles the configuration, the composites are compiled into the same singular MOF. Really all it is when you composite a configuration is just saying (I want to add these other configs here) and it does so like one big configuration.
Now, you do get reference points in the logging for composites, if you look in the logging, you’ll see a reference to the source composite config, but as you pointed out, no module versioning.
With that being said, I don’t think the current LCM would be able to support what you’re looking for without major design changes. But, you can validate your composite versioning simply by looking at the stored composite in your modules directory. Since Azure Automation doesn’t yet (if it ever will) support side-by-side versioning, you only have that one version that you’re config is going off of.
If you really feel strongly about this being a requirement, you might be able to put in a User Voice to Microsoft regarding the issue.
This is great feedback. Our engineering team will review it today. I don’t have any estimation for what it will take to deliver but if we can make it happen, we should.
Thank you very much for calling this out,
Principal Program Manager
Azure State Configuration and DSC
Thanks guys for the prompt feedback. Will especially for the detailed feedback on the LCM, also I wasn’t aware that AZDSC doesn’t support side by side versioning of Modules.
I might create another discussion with detailed info on what we are trying to do as I think quite a few people can benefit from it trying to do Configuration Management with DSC.
Anytime! I’d be interested to hear it. I’m doing some pretty wild stuff with it as well. Sharing use cases is always fun.