1

Any ideas on the cause value for the template parameter 'modulesUrl' at line '11' and column '20' is not provided returned when validating a new VM in the Azure Portal with the DSC extension. It's no help knowing that some underlying template has errors.

DSC config stripped to a minimum test version is

configuration WebServer {
    Node localhost {

        WindowsFeature IIS {
            Ensure = 'Present'
            Name = 'Web-Server'
        }
        WindowsFeature DotNet {
            Ensure = 'Present'
            Name = 'Web-Asp-Net45'
            DependsOn = '[WindowsFeature]IIS'
        }

        File Namer {
            DependsOn = '[WindowsFeature]DotNet'
            DestinationPath = 'C:\InetPub\wwwroot\name.aspx'
            Type = 'File'
            Contents = '<h1>My Name is: <%=Environment.MachineName %></h1><hr />'
        }
    }

}

I thought that dumb aspx line might be troubling it but even if i replace that with just 'horses' it still throws this error. I'm using dsc.ps1\WebServer as the Module-Qualified name and have tried both the zip from Publish-AzureRMVMDscConfiguration -OutputArchivePath and the plain ps1 file. Tried version 2.15, 2.21 (as per an example in the documentation - its unclear that this refers to the Dsc version). This is in the West-Europe region, creating a DSv2 Windows Server 2016 Core image.

Update: That DSC script works on a local Hyper-V 2016 Core VM and correctly deploys name.aspx so I don't think the problem is there.

1 Answer 1

0

I have just run a similar script in Azure and it worked: enter image description here

I think the problem is with the version of the DSC extension that gets deployed when using the Publish-AzureRMVMDscConfiguration CMDLet.

I used the Automation account blade to import the configuration, compile the configuration and then register my VM against it. I can post additional details tomorrow if needed.

7
  • Looks like 2.26 is the latest (blogs.msdn.microsoft.com/powershell/2014/11/20/…) so I gave that a go but still same error, I haven't tried the automation blade - got the same result in 2012 r2 applying post-creation from the extentions blade. I'll give a powershell deployment a go and see where that goes.
    – tobyd
    Jul 18, 2017 at 22:08
  • Two things I should have said, I tried the above DSC script on both 2012 and a 2016 VM. I did have one problem, the file didn't get created for me. I had to create the file first and then the DSC script edited it. Try creating and managing through an Automation account. it seems much more reliable that the extensions blade or using PowerShell to enable the extension. Jul 19, 2017 at 8:47
  • I had some problems with the PowerShell deployment too, just some nonsense error after churning for a while. I'll try the automation stuff later on. I don't know if your script isn't missing the 'P' in the second feature for ASP.Net which will have prevented DSC installing .net?
    – tobyd
    Jul 19, 2017 at 9:03
  • Hi, The name is correct, I used get-windowsfeature on a server 2012 VM to get the feature name. It might not be exactly the same feature you are trying to deploy. Jul 19, 2017 at 9:13
  • Ah, my mistake AS = ApplicationServer, Had more luck with Automation Account, IIS and .net got pulled to the VM but encountered the same problem with that file though. I'll wade through the docs to see what that is about
    – tobyd
    Jul 19, 2017 at 10:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .