Although Microsoft landed quite lately in the Cloud World with its IaaS and PaaS platform, Microsoft Azure is growing steadily and is definitely one of the top-tier solutions available for computing, storage, databases and everything you need to deploy on a cloud. Nevertheless, its adoption rate is still quite low compared to the other big players like Amazon Web Services, and many people have small to no knowledge of many of its interesting features. Let’s see together 5 things you don’t know about Microsoft Azure to get you started with it.

1: Your data is stored redundantly, but getting rid of it is easy and safe

Like many other cloud providers, Azure stores data in multiple places to add redundancy and increase safety. Data is triplicated across three physically separate domains, and if one part of the infrastructure goes down, it can provision another copy. Therefore, at any given time, there are always three copies of your data at the primary location.

Also, unless you disable it, Azure will geo-replicate to a secondary site far away from the primary one and keep it in triplicate there too. Definitely a strong and secure approach to saving your data. On the other end, deleting the data might be tricky. When you decide to delete an object or a table entity, Azure will immediately delete that entry from the index used to access data at the primary location, but geo-replicated copies will be deleted asynchronously at a later time. May this cause risks in case someone else tries to read data saved there? Actually, no.

Microsoft has a complex solution to avoid this issue, based on the fact that data needs to be overwritten before being provisioned. Therefore, once your data is deleted, people trying to access it will just get a bunch of 0’s. Microsoft don’t give a contractual guarantee that says they will overwrite deleted data, but at least they make it impossible for anyone to provision overwritten or deleted data.

2: Azure service healing restores VMs to a running state

One big advantage of running virtual machines on Azure is that your VMs will remain available even when there are problems. When Azure finds a problem in one of its nodes, it automatically moves the VMs to other nodes so that they are restored to a running and accessible state. This cause the virtual machine to shut down and restart, and the MAC address, processor, and DPU ID will be changed. But if the VM is running on an Azure Virtual Network, the IP address of the VM does not change when the healing process occurs.

Also, the storage on data disks is persistent, so files will not be affected by the restart and move. That’s why, with domain controllers running on Azure Virtual Networks, you need to store the Active Directory DIT, logs, and sysvol files on data disks. Data disks can be used to store any files other than the core operating system files. OS disks use caching, and data disks don’t; in the latter case, the data is immediately written to permanent storage.

3: Azure Virtual Networks mixes up well with your on-premises network

Speaking about Azure Virtual Network, it can allow you to get a nice mix of your cloud infrastructure and your on-premises network. Indeed, you can connect your internal network to an Azure Virtual Network via an IPsec site-to-site VPN through an approved VPN device and treat it like another subnet on your network, which is quite great if you have your own infrastructure already and don’t want to give it up. You can also have multiple Azure Virtual Networks your on-premises network is connected to from a single point of presence.

Unfortunately, it doesn’t work the other way around: you can’t connect the same Azure Virtual Network to multiple on-premises networks. Also, you can’t route connections between different Azure Virtual Networks through Azure. A workaround if you want to communicate between them, is to go back through the on-premises VPN to which they’re all connected.

4: Support for virtualizing domain controllers

Any network administrator knows that domain controllers on VMs were not considered an excellent practice, so to say. For example, restoring VM snapshots could easily result in inconsistencies in the Active Directory database, like inconsistent attribute values, password problems, duplicated security principles, and even schema mismatch: quite a nightmare. Windows Server 2012, though, introduced a new feature, VM Generation ID, that addresses this problem, and Windows Azure Virtual Networks run on the Windows Server 2012 stack, thus supporting this feature.

So, you can create domain controllers (or “move” them from an on-premises network) in the Azure Virtual Network. By the way: Sysprep won’t work in this scenario. You need to move the .vhd file for your VM into Azure storage and use it to create a new VM. You can also create a brand new DC on the Azure Virtual Network and enable inbound replication.

5: Azure uses both static and dynamic IO addresses

Short summary: Virtual Networks use virtual IP addresses, Virtual Machines use dynamic IP addresses. The virtual IP address of an Azure Virtual Network refers to the public IP address used by external computers to connect to the Azure Virtual Machines. Each of your virtual machines on the Azure Virtual Network has a dynamic IP address assigned to it,  “dynamic” because it’s assigned by Azure. Indeed, if you try to give your virtual machines static addresses, Azure won’t recognize them, and you won’t be able to connect to those VMs at all.

Unlike dynamic IP addresses assigned by ISPs, it can change frequently, and works just like a reserved address. So the same address stays with a particular virtual machine for as long as the VM exists.