Need help with Azure DSC extension

Anybody here using Azure DSC extension and can shed a light how to properly onboard VM which requires configuration parameters passed to DSC and use Azure Automation at the same time.
Current issue is that it seems to be a choice either to use Azure Automation pull server or custom configuration file with parameters but not both. I’d like to use custom configuration file but still use Azure Automation servers for both dependencies pull and report server. Did not find a way to accomplish both at the same time, seems to be either or situation.

There is a “default configuration script” embedded in version 2.72 and later. Here’s an example of how to use it (I just recently published this):

And the overview page has been updated as well. Let me know if there is info you need that is not here:

Yes, but the problem with default configuration script is that it does not accept any parameters beyond default LCM parameters, so it’s impossible to pass any custom data to script.
I want to pass some custom data to my DSC script and register it with Azure Automation for reporting/resources pull which seems to be impossible in current implementation.

Ah. So the extension just does the onboarding. The configdata actually flows in the the compilation job or would be handled by your build server if you are publishing MOFs. The compilationJob section in this file has a configuration data property:

That’s a doc issue. I will work on it, though it may be a couple weeks. In the mean time I am happy to help out here.

Well I would like to not push MOFs to Azure Automation and use it only for reporting and dependencies download.
So I wanted to use manual configuration script to onboard only for reporting and dependencies. Problem is that since Configuration Script allows only one configuration to be specified I can not configure both LCM and actual localhost in one template. What would be the solution?

Now I understand. What would be the advantage of delivering the configuration using the extension rather than the service? We have seen complexities in the pattern that lead to errors, such as expiring SAS tokens.

For me advantages are (I’m not planning to template any part of Azure Automation account):

  1. I can easily pass parameters via ARM template without additional precompilation manual or automated steps in Azure Automation Account including secured credentials
  2. I can easily debug custom script by just executing it in my test Machine before deploying to production since they are self contained
  3. I can put entire solution (both scripts and ARM templates) into source control including actual DSC

So far I only come as workaround to have custom script to be run first which sets LCM to point to Azure Automation and then invoke DSC extension which is pretty ugly to say at least.

There is does not seem possible to pass `-Verbose` parameter to DSC extension to log extended information into log file or ETW for that matter. Where do I add this feature request.

I worked on automating configuration testing some while I was on vacation. I’m creating the account outside of the template so it is somewhat similar to your scenario. Can you take a look and offer feedback?

I’m not sure how automated testing helps original requirement to pass data to DSC extension in addition to onboard to Azure automation.
I’m compiling MOF now directly in Azure Automation and don’t have this anymore as requirement.