A couple of months ago, I wrote a blog post about starting and stopping virtual machines in Azure using Windows Task Scheduler inside a dedicated VM. With the advent of Azure Automation this can actually be done way easier and also free-of-charge. In this post I will describe how to use Azure Automation to start and stop virtual machines on a schedule.
At TechEd 2014 in Houston, Microsoft announced preview availability of a much-anticipated feature, Azure Files. It is a platform capability to easily expose SMB file shares that can be used from multiple instances to read & write files, without having to build an infrastructure yourself (like I described in my blog post about building file shares using DFS. It is a native Azure service built on top of the same architecture as the other storage services (blobs, tables, queues), so it offers the same characteristics in terms of (geo-)redundancy, HA and scalability. Apart from providing a SMB 2.1 interface (that is only accessible for Azure VMs being hosted in the same geographic region or from on-premises environments via a VPN connection), shares in Azure Files can also be accessed remotely via REST from anywhere in the world, provided that a client knows the storage account credentials.
This post gives an introduction to getting started with Azure Files and shows how to automatically mount a share when provisioning a new Windows VM, using the new Custom Script configuration extension (also announced at TechEd).
One of the great new Azure features announced at TechEd 2014 in Houston is the capability of assigning public IP addresses directly to VMs on an instance-level. As these IP addresses are public (that’s why they’re also called PIP) they allow you to access your VMs directly from outside the datacenter, without having to define any endpoints on the virtual IP address (VIP) of the corresponding cloud service.
This can be handy for example if you need to access your Azure VMs via RDP from your corporate environment and your firewall admin has blocked ports other than the ‘mainstream’ ones (80, 443, 3389, …). If you have deployed multiple VMs in a single cloud service, the Azure load balancer provides port forwarding to those VMs from random high ports to port 3389 internally. If your firewall blocks those high ports you’re stuck. PIPs to the rescue! This post will describe what it takes to create a PIP for a VM and how to avoid common pitfalls.