Azure is Microsoft's cloud environment that it likes to sell to business. The cloud is a name designed to conjure up nebulous space that is just there and available for people who need business computing. It's a little like making a sausage - it's nice to eat but you really don't want to know how it is made.
Azure consists of a number of services you can rent and pay for by the minute, hour, month or year. You don't need to go buy a large room, electrical power, lots of servers from Dell or HP, software etc up front. Instead, your Azure subscription pays for what you need.
If you work for a company that has a Microsoft developer subscription (MSDN) then you get some free credit each month to learn about Azure and set up some of your own Azure services. Usually, this is for self-education and building custom solutions.
One thing you can do is create virtual machines. Azure is a number of large data centres in the US, Europe, Asia and elsewhere. Microsoft puts in lots of servers, routers, power and internet connectivity for you to rent. When you decide you need a Windows server you just choose one from a menu and it starts running a couple of minutes later and starts charging your account. In reality, you haven't rented a physical server for yourself you are just one of a number of users of the server. It is a virtual server running inside some hardware. Since it's virtual Microsoft can move it inside the datacentre as required invisibly to keep everyone working 24/7.
The problem with the MSDN subscription is that it's never enough to run all the things you want. In the non-Azure world, you can spread your resources by virtualising your own servers in HyperV. Running servers inside servers. They don't know they are running on another server and it gives you more flexibility. On Azure, it would also hit your budget less.
Azure is a virtual environment. If I was to do the same as a real data centre I would run a virtual computer in Azure. It would then run HyperV that would have virtual servers running in it. What we call nested VMs in Azure. With some configurations, Azure lets you do this.
The first step is to create a Windows 10 Pro machine on Azure with 32gb of memory, 8 cores and a second 1tb hard disk. You have to use slow HDDs rather than SSDs to keep within budget. Once done add HyperV to the machine.
The full guidelines appear here; https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization
Using the guidelines you need to create a virtual switch so you can create a network of static IP addresses that your HyperV VMs are going to live in.
Create a virtual machine and make sure it's off. I am assuming you are going to create a Windows 2012 or 2016 server.
If the name of the server is "server1" then run the following command in PowerShell as an admin.
Set-VMProcessor -VMName server1 -ExposeVirtualizationExtensions $true
This just allows the vms to be nested.
Get-VMNetworkAdapter -VMName server1 | Set-VMNetworkAdapter -MacAddressSpoofing On
This gets the network adaptor to fake mac addresses.
Next you need to create a virtual switch that does Network Address Translation (NAT)
New-VMSwitch -Name VmNAT -SwitchType Internal
New-NetNat –Name LocalNAT –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
I am going to use the 192.168.0.0 for my servers on my HyperV VMs running on my big Windows 10 Pro Azure machine. The virtual switch itself gets the address 192.168.0.1.
You can confirm the adaptors by running this command
You will get an output showing all the interfaces. Look for the "ifindex" column to get the ifindex for the switch you just created. You will need that for the next command.
New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 25
Replace "25" with the actual ifindex number you got from running the Get-NetAdapter command.
Each VM you create needs to have a static address and use the gateway at 192.168.0.1.
If you want your first server to be a Windows Domain Controller then after you get it running you need to do this on your first VM in Powershell.
This is very bad for proper non-test environments. The execution policy should be "RemoteSigned" or "Restricted" but it doesn't matter for testing. If you want better security use "RemoteSigned".
Add-WindowsFeature -name ad-domain-services -IncludeManagementTools
This command adds in Active Directory.
Install-ADDSForest -DomainName "example.local" -ForestMode 5 -DomainMode 5
Change "example.local" to the actual domain you want to create. You get to create some domain recovery passwords that usually dont matter a lot in test environments that you delete later. They do matter in real production. Note them down.
That's it. Nested VM complete. Domain controller ready for your virtual domain inside a Windows 10 PC running on Azure. I haven't covered everything but the main thing is to know that this is all possible.