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.
A recent update to Azure Batch added the ability to join a batch pool to a virtual network. By doing so it is possible for batch compute nodes to access resources inside a vNet (file servers, SQL servers etc.).
vNet Requirements There are some limitations on the vNet configuration if you wish to do this:
Only Cloud Services Configuration pools can be assigned a VNet. This is no longer the case The VNet must be: - In the same Azure region as the Azure Batch account.
I’ve seen a few forum questions lately from AWS users who want to (or have to) use Azure and whilst there are a lot of similar services in either platform, the new user experience and terminology can be very confusing if your used to AWS. This article is the first in a series of posts that I’m hoping will help users coming from AWS get to grips with Azure.
To be very clear, I’m not looking to argue about which platform is best or why you should use one or ther other, I’m simply providing the information an AWS user needs to quickly get a grasp of Azure and relate it to what they already know.
The AAD DS team has released new features that mean some of the limitations in this article are no longer present. Be sure to read my update on this service to get the latest information.
Azure AD has always been a little bit confusing to new users of Azure, the name implies it’s a cloud version of AD, but it quickly becomes clear to most that it very much is not.
Earlier last week I had a need to delete an Azure AD tenant, and this turned out to be a much more difficult task than I had originally anticipated so I thought I would document the steps I went through in case others encounter the same problems.
1. Disable AD Sync If your syncing your on-prem AD up to Azure AD you need to disable this from inside the Azure Portal so that it disconnects your users from the sync, otherwise you cannot delete your synced users.
