Azure – DevTest Labs

DevTestLab

One of the things about becoming an MVP is that you get notified about all sorts of interesting things coming in the world of Azure.  One new feature that caught my eye this week was Azure DevTest Labs, which is currently in preview.  Claude Remillard gave a great overview of DevTest Labs at the recent AzureCon event.

https://azure.microsoft.com/en-us/documentation/videos/azurecon-2015-introducing-azure-devtest-lab/

My interest in DevTest Labs (and the reason that I have registered for the preview) is the work the team has done to make it easy to spin up labs for testing purposes, they can be set to shutdown automatically when idle! (yay no more wasted spend!).

There are a couple of other functions that really caught my eye:

  • Ability to set quota’s for labs on machine sizes and spend plus usage monitoring so its easy to see if spend in the Lab is on track
  • Lab User security role which locks the user out of the rest of the Azure subscription and ensures they can only access the lab and its associated resources
  • Scheduled Lab shutdown (Scheduled Lab startup is coming)   — there is not point in my mind for paying for the running cost of machines that are not required or being used
  • Integration in to Visual Studio release pipeline so that code can easily be deployed to a Lab for testing

As well as Development teams I can see this being useful for Infrastructure teams.  One question I get asked  alot is how can we give our staff the ability to create a couple of VM’s in Azure but control the spend……Do we have to create a subscription for each of them?  I see DevTest Lab as solving this and allowing a single subscription to be used.  A customer can setup a Lab for each staff member with a quota attached, with the scheduled shutdown or shutdown on idle enabled compute costs would be hugely minimised.

If you are interested you can sign up for the private preview on the DevTest Labs page

Azure AD Domain Services – A First Look

AADDS

Earlier this week Microsoft announced the preview of Azure AD Domain Services (AADDS). This new functionality allows applications that are designed to run against your On Premise Active Directory to easily run in Azure (with out having to put in place domain controllers in Azure and VPN connections back to your on premise AD).

In simple terms at the click of a button you can have a ‘managed’ domain controller fully synced up with your Azure AD appear in one of your VNet’s.  You can then domain join your Azure servers in the same way you would your On Premise servers.

There are a number of steps that have to be undertaken to enable Azure AD Domain Services but Microsoft have written a great blog that steps you through the process.  You must complete all steps before attempting to join an Azure VM to the new AADDS domain.

Couple of points to note from my testing so far.

  • Azure AD Domain Services are not yet available in all regions. If you have all your Azure infrastructure running in the Australia regions you will need to create a new VNet in either the US, Europe or Asia region to be able to enable Domain Services.
  • Azure AD Domain Services uses password write back to sync passwords with Azure AD.  As with AD Connect a password reset using http://myapps.microsoft.com is generally required to generate the hashes in AD before the account can be used to authenticate against the Azure AD Domain Service.
  • Any user account that you put in to the AAD DC Administrators group will be added to the administrators group on any machines you join to the AADDS domain.
  • As Azure AD Domain Services its a managed service you can not have Domain Administrator or Enterprise Admin privileges over the AADDS domain.
  • Currently a single user and computer group policy is supported and the domain can be managed with the same tools that are used to manage on-premise AD.

Further Blog articles to come as I rebuild my Azure test environment using Azure AD Domain Services!