February 13, 2018 at 2:58 pm #93549
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.
February 13, 2018 at 3:38 pm #93552
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:
February 13, 2018 at 3:39 pm #93555
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.
February 13, 2018 at 3:45 pm #93556
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.
February 13, 2018 at 4:57 pm #93571
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?
February 13, 2018 at 5:13 pm #93576
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.
February 19, 2018 at 8:44 pm #94062
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.
February 13, 2018 at 5:23 pm #93577
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.
You must be logged in to reply to this topic.