Earlier last week Microsoft announced the public preview of the VM Instance Metadata service. This service allows you to query information about a VM, from inside the VM itself, it’s something that has been available on AWS for a long time and has some really interesting uses for users or code running inside your virtual machines. In this post we’ll dig a bit deeper into the service and how it can be used.

Back in November I published an article on Azure Active Directory Domain Services (AAD DS), detailing some of the limitations of the service and what it is and isn’t intended for. If you’ve not read that I recommend going back and reading through that first so this article makes sense. Since this article was published there have been some big updates to the service that mean some of these limitations have gone away, so I thought it was time to detail some of these changes and what they mean for Azures Domain Controller as a Service offering.

Microsoft’s Log Analytics platform, part of the OMS Suite, allows you to pull in and analyse data from a wide variety of source for your operational needs. One of these sources of data is from Azure Monitor, the monitoring solution built into the Azure platform. Azure Monitor is great on it’s own when you want to look at performance or log data for a specific resource, but when you want to look at this data across your whole estate and be able to dashboard and alert on this, you need to aggregate and analyse this in Log Analytics.

Since writing this article I’ve released a VS Code Extension that installs these snippets with a single click, see here.  In my previous post on using VS Code for authoring ARM templates I recommended using an ARM Snippets from the plugin gallery. However since then I have come to realise this plugin is fairly limited in the amount of plugins, and difficult to extend. Given this I would now recommend utilising the set of snippets provided by the Azure Cross Platform Tooling Samples

If your writing ARM templates for Azure you’ll have found that the amount of tooling available for authoring templates is fairly limited. The default solution seems to be Visual Studio but this can be very heavyweight and resource intensive without gaining any of the real benefits of VS such as debugging. I’ve recently switched over from using Visual Studio to use Visual Studio Code, for a much more light weight experience.

I’ve seen quite a few forum posts of late asking something along the lines of “Why can’t I create A series VM’s any more” so I thought it worth a quick post to detail what’s up and how to fix it. The problem here is that if you use the Azure portal to create a VM and use the defaults provided, when you come to selecting a VM your presented with a Window like this:

In the second part of this series we look at Virtual Machine and other associated IaaS components and how these translate from AWS to Azure. As with the previous article, the intent here is to provide a high level overview of the service and relate it to it’s AWS counterpart so those of you that are coming to Azure from AWS know where to start looking for the services you need and the documentation to help you get started.

Azure App Service Certificates provide a convenient way to purchase SSL certificates and assign them to Azure Apps right from within the portal, but one question I see a lot is whether it is possible to use this certificate elsewhere, outside of the app service, particularly if you have purchased a wild-card certificate. The certificate provided by App Service Certificates isn’t anything special, it’s a pretty standard SSL cert, the service just provides a nice easy way to provision it and assign it to your web service.

Following on from my post on joining Azure batch pools to a vNet, this leads on to a requirement to access resources on the vNet and this means credentials are needed. Rather than hard-coding these credentials in scripts, we want to obtain these from a secure storage location on demand and this is where Azure KeyVault comes in, providing a secure, encrypted storage location for our credentials. Obviously there is no point putting your admin credentials in KeyVault, then hard-coding credentials to access KeyVault in your script, so the solution is to use a certificate to give your batch VM’s access to KeyVault.

User profile disks for RDP session hosts are VHD files used to store the users profile information so that it can roam with the user between session hosts. By default the UPD’s are mounted on the session hosts at login, and appear as symlinks under the C:\users folder so that applications can access them using standard profile paths, this all works fine without any setup required. There may be some occasions where you need to change where these are mounted, for example in an Azure hosted RDS environment I needed to have these mounted under the temporary D drive so that access to the C drive could be completely locked down.