Demo - Build a Windows Virtual machine in the new portal
Start course
2h 17m

Azure Resource Manager Virtual Machines

Virtual Machines are a very foundational and fundamental resource in Cloud Computing. Deploying virtual machines gives you more flexibility and control over your cloud infrastructure and services, however, it also means you have more responsibility to maintain and configure these resources. This course gives you an overview of why use virtual machines as well as how to create, configure, and monitor VMs in Azure Resource Manager.

Azure Resource Manager Virtual Machines: What You'll Learn

Lesson What you'll learn
Overview Overview of the course and the Learning Objectives
What is a Virtual Machine? Understand what are Azure Virtual Machines and what workloads are ideal for VMs
Creating and Connecting to Azure VMs Learn to deploy Windows and Linux VMs as well as how to connect to these VMs
Scaling Azure Virtual Machines Understand VM scaling, load-balancing, and Availability Sets in Azure Resource Manager
Configuration Management Understand the basic concepts of Desired State Configuration and the options available to Azure VMs
Design and Implement VM Storage Gain an understanding of the underlying Storage options available to VMs as well as Encryption
Configure Monitoring & Alerts for Azure VMs Learn to monitor VMs in Azure Resource Manager as well as configure alerts.
Summary Course summary and conclusion


GitHub Code Repository


We are going to build a Windows Server 2016 Datacenter VM, so let’s type windows server in the search box. Let’s select Windows Server 2016. Here you are presented with a basic description of this VM image as well as Legal terms. For Microsoft Windows VMs, your license is built-in and included as part of the cost of the VM which is practically free. Just be careful as some 3rd party images require you to “Bring-Your-Own-License” (BYOL).

At the bottom of this blade you see the option to Select a deployment model. This course covers Azure Resource Manager, but as you can see there is also available the “Classic” or Azure Service Manager deployment model. Let’s leave this as “Resource Manager” and click “Create.”

Now that we have the operating system or VM image we’ll use, it’s time to configure the size, disk, and other settings of our virtual machine. First let’s give it a name. Let’s call it “VM1.” For the VM type, as you can see we may select SSD for the more performant solid state drives, or HDD for a regular magnetic drive. You’ll also often notice a small “information” marker next to a field which you may click or hover over to read more info about this particular attribute. Let’s proceed with the username and password. I’ll call it ‘cj’ and I’ll give it a default password. It asks you to confirm the password as well. The ‘Green’ checks indicate that the field has passed validation. For example if I changed my VM name to 1, you’ll see the error that says “Virtual machine name cannot contain only numbers.” Your default subscription will be selected, but you may select a different subscription if you have multiple. Next is the Resource Group. The Resource Group is a way to logically group together Azure Resources for easier administration. Let’s a create a new Resource Group called “rsGroup1.” For the location you will notice a ton of available regions. As of this recording Azure has 34 regions available around the world, more than any other cloud provider that I know, and they are constantly adding more regions. By the way if you have an Azure Government Subscription (which is a special Community Cloud for educational institutions as well as federal, state and local governments) then you will have available your own set of regions such as US Gov Virginia, Iowa, etc. Let’s select “East US” and click “OK.”

Now we configure our VM size, which consequently directly correlates to the price of the VM. By VM size we mean, how many disks can be attached, memory, Input/Output Operations or “IOPS,” as well as special features which are available in certain skus. The default views shows you a list of recommended sizes, however I like to click “View all” in order to choose the appropriate size that I’d like. You can now see all of the available VM size options. Since this is a demo, we’ll pick the cheapest and go with the F1S Standard size. However, remember that we are using SSDs and if we were to choose HDDs, then we would be presented with even cheaper options.

In fact, let’s do this. Let’s click back on Step 1. You’ll get a prompt that says your unsaved edits will be discarded. Select “OK.” We’ll change the VM disk type to HDD and leave everything else the same and click “OK.” Now you can see we are presented with several cheaper options. But if you also noticed, many of the A-series VMs do not give some of the features such as “Premium Storage.” But then we get new options like the Nv-Series that allows you to have NVIDIA graphic cards. But let’s be cheap and select an “A1 Basic” size and click “Select” to move on.

Here we configure storage options for our VM. Our virtual machine disks including diagnostic data disks are stored in what’s called a “storage account” which is a resource that’s external to the actual virtual machine resource. Don’t worry too much for now about how all this works, just get the basic idea that we are configuring a place for our VM data to live. For now, let’s leave everything as the default, which as you can see by default creates a new virtual network for our VM called “rsGroup1-vnet” and places it on a subnet called “default.” We also have a new “Public IP” so that we may access our VM over the internet and a default Network security group which has firewall rules to allow us to connect via RDP.

Let’s dive into the Network Security Group, or “NSG.” As you can see it’s creating a rule automatically to allow inbound TCP access over port 3389 RDP. Let’s close these blades to get back to the “Settings” blade. We’ll also leave monitoring and diagnostic settings as the default as we’ll discuss these options later. Select “OK.”

We’ve arrived at the “Summary” screen which details all the options that we’ve set. And as we’ve done before we may go back to any step and change any part of the configuration. Were all set, so let’s hit “OK” to build the VM. 
You’ll notice that Azure automatically pins the Deployment status of your new VM to your “Dashboard.” You may click it to get more details about the deployment status. Scroll to the bottom to see each resource get created. Potential errors if any will be visible here as well.

Also remember that the time it takes to build a VM can vary depending on the VM image you’re building, the resources that come with it as well as the VM Size, as SSDs are faster and different VM Sizes have higher IOPs, etc. 

Great, we’re done. Perhaps I should have chosen a beefier VM size as my cheap VM took a little longer than I expected to install, but your mileage may vary as they say. As you can see you are presented with the virtual machine “Overview” tab for the VM we just built. From here you can see the resource group name, status (which is “Running”), location, computer name, OS, VM size, as well as network settings. You can also already see basic metrics being generated for the virtual machine.


Now let’s see how to connect to our VM. Because we have a Public IP Address associated with our VMs network interface card (or NIC), we can connect to the VM from home over the internet. At the top of the VM Overview pane, you will see buttons that let you perform basic commands such as start, stop, and restart your VM or refresh the view. You’ll also notice a “Connect” button. After selecting “Connect” our browser downloads an RDP file. Let’s inspect the properties of this RDP file. I will right-click -> Edit. Here you can see the file references the Public IP along with RDP port 3389. I can add my username if I choose which was ‘cj’ and of course I can edit other options as I would any RDP file. Let’s click “Connect.” We are presented with a small warning about connecting to remote computers, but since we trust our VM I will click “Connect” once again. Since I’ve already specified my username, I will specify the password that I configured in the Azure Portal. We are presented with a Certificate for our VM which we can view. We’ll select “Yes” we would like to connect despite the certificate authority not being trusted.

And there we are. We are now connected and logged in to our Windows Server 2016 VM in Azure. In Server Manager you can see all of the normal information you’d expect to see from an on-premises machine. Opening up PowerShell and running Get-NetIPConfiguration you can see that we have an internal Private IP address of, which is the private IP address that was assigned to this VM as part of the Virtual Network and subnet that it’s attached to. Let’s exit out of this VM. We may reconnect at any time using the same RDP file, as long as the Public IP address stays the same.

About the Author
Learning Paths

Chris has over 15 years of experience working with top IT Enterprise businesses.  Having worked at Google helping to launch Gmail, YouTube, Maps and more and most recently at Microsoft working directly with Microsoft Azure for both Commercial and Public Sectors, Chris brings a wealth of knowledge and experience to the team in architecting complex solutions and advanced troubleshooting techniques.  He holds several Microsoft Certifications including Azure Certifications.

In his spare time, Chris enjoys movies, gaming, outdoor activities, and Brazilian Jiu-Jitsu.