How can we improve Microsoft Azure Lab Services?

Deploy an Azure Resource Manager Template into a DevTest Lab

It would be useful if we can deploy an existing ARM Template in JSON template to the DevTest Lab. At present we can only deploy individual VMs?

68 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Marcus Robinson shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thank you all again for your comments! We’ve shipped this feature that allows you to deploy ARM template to provision environments in DevTest Labs. Please check out this announcement for more information: You are all welcome to open new suggestions here for this feature. Thanks!


Sign in
Password icon
Signed in as (Sign out)
  • Douglas James Boyd commented  ·   ·  Flag as inappropriate

    If you have 30 developers, you have to run the task 30 times, which is inefficient. We already have templates for these which can deploy 'N' VMs in one deployment, it would be great to be able to adapt them for use in Dev Test rather than having to reinvent the wheel. DT Labs seems to introduce its own, unrelated, template syntax, which is a shame. I was hoping to be able to deploy existing templates, with some modifications, to take advantage of the Dev Test Labs features, or even move existing resources in to it.

    I would actually suggest that rather than being a sub service of Azure, the principles and concepts behind Dev Test Labs (scheduling of resources, limiting source images, managing custom images (sorely lacking currently in IaaS as a whole), repos, controlled self service etc) should be applied to Azure as a whole.

    Overall, it just needs more flexibility, the same flexibility as IaaS generally. Just with the administrative controls DTL provides. It shouldn't be an either or question - I want both in combination!

  • Adam Toth commented  ·   ·  Flag as inappropriate

    We use service fabric clusters for automated testing deployed from vso release with azure resource manager templates. It would be helpful to be able to apply devtest labs policies to such test clusters like auto shutdown and cost cap.
    We fell back to using builds to shut down/delete unneeded test resources for the nights and weekends.

  • Brian “B” Laws commented  ·   ·  Flag as inappropriate

    I think a good, tangible example is that of a class based on a multi-server product. For example, take SharePoint. There currently is an ARM template that provides a 3-server environment, including AD, SQL, SP, storage, VNET, etc (although there should be an option to bring your own). Each student in the class will need their own independent environment. DevTest Labs could be used to create these at the beginning of the week (one per student) and power them on before the class starts and off afterwards. The alternative would be to deploy the ARM template, say, 15 times at the start of the week and have other scheduled scripts to start/stop them. However, this seems like a perfect use case for DevTest Labs.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I agree with Zeeshan below. ideally if you have a Resource Group with VM's, subnets, a virtual network, web apps, and storage accounts all working as a unit for a certain app - DevTest Lab should be able to take that Resource Group and apply the DevTest Lab policies on it (start stop, artifiacts, etc.) but always treat that resource group as a unit. Developer should be able to add Resources in that DevTest Lab controlled Resource Group as they add more features to their app that is supported by that Resource Group. VSO deployments could then originate from resources in that Resource Group to QA/Test Resource Groups or Production Resource Groups.

  • Zeeshan Abbasi commented  ·   ·  Flag as inappropriate

    We need to use the ARM templates so that we can easily define the network parameters. For our organisation we do not want any public IP addresses defined by default. Also need to assign network security groups. We need to do all that via scripting/templates. At the moment there is a public IP address with every Lab VM. I cannot see why Lab VMs should be any different to other VMs and probalby should have been built on top of the existing VM templates etc.

Feedback and Knowledge Base