Launch a VM on Azure with Networking

Deploy a Windows Server VM, configure a VNet, and write NSG firewall rules.

Introduction

30 Second Summary

Every website, app, and online service runs on a server somewhere. Cloud platforms like Azure let you spin up those servers on demand without buying any hardware.

In this project, you will launch a Windows Server virtual machine on Azure, build a custom network around it, write firewall rules to control traffic, and prove it all works by serving a live web page from the cloud.

What You'll Build

Picture this: you paste an IP address into your browser, and a web page loads from a server you built, networked, and secured yourself in the cloud.

By the end of this project, you'll have:

  • A running Windows Server VM you can remote desktop into from your own computer.
  • A custom Virtual Network with a subnet you designed, giving your VM a secure home in the cloud.
  • A Network Security Group acting as a firewall with rules you wrote, controlling exactly which traffic gets through.
  • A live web page served from your VM that you can access from your browser via its public IP address.
  • Secret Mission: Lock down your VM by restricting RDP access to only your IP address and adding a Deny rule to block all other traffic.

Are there any prerequisites?

You need a free Azure account and a Windows PC (Remote Desktop Connection is built in). If you do not have an Azure account yet, you can sign up for one with $200 in free credit at azure.microsoft.com.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

You're going to deploy a real server in the cloud, build its network from scratch, write firewall rules to protect it, and prove it all works by serving a live web page.

Set Up Your Resource Group and Virtual Network

Before you can launch a virtual machine, you need a network for it to live in. Without a Virtual Network, your VM would have no way to communicate with the outside world or other Azure resources.

In this step, you will create a Resource Group to organize your resources, then build a Virtual Network with a custom Subnet inside it.

In this step, get ready to:
  • Create a Resource Group to hold all your project resources in one place.
  • Create a Virtual Network with a custom address space and subnet.
  • Verify your network is configured correctly in the Azure Portal.
Create a resource group

A Resource Group is a container that holds related Azure resources together. Everything you build in this project will live inside one Resource Group, making it easy to manage and delete later.

  • In the Azure Portal search bar at the top, type Resource groups and select it from the results.
  • Click + Create.
  • Select your subscription from the Subscription dropdown.
  • In the Resource group field, enter az900-vm-lab.
  • In the Region dropdown, select a region near you (e.g., East US).
  • Click Review + create.
  • Click Create.

You should see a "Deployment succeeded" notification. Your Resource Group is now ready.

What is a Resource Group?

Think of a Resource Group like a folder on your computer. It groups related Azure resources (VMs, networks, disks) so you can manage, monitor, and delete them as a unit.

At the end of this project, deleting the Resource Group removes everything inside it in one action.

Create a Virtual Network

A Virtual Network is your private network in Azure. Your VM will live inside this network, and you control which traffic can flow in and out.

  • In the search bar at the top of the portal, type Virtual networks and select Virtual networks from the results.
  • Click + Create.
  • On the Basics tab, select your subscription.
  • In the Resource group dropdown, select az900-vm-lab.
  • In the Name field, enter az900-vnet.
  • In the Region dropdown, select the same region you chose for your Resource Group.
  • Click Next to proceed past the Security tab (leave defaults).
  • Click Next again to reach the IP Addresses tab.

You are now on the IP Addresses tab, where you define your network's address space and subnets.

  • Confirm the address space shows 10.0.0.0/16 (this is the default).
  • Under Subnets, click on the default subnet to edit it.
  • In the Name field, change default to web-subnet.
  • Confirm Starting address is set to 10.0.0.0.
  • Confirm Subnet size is set to /24 (256 addresses).
  • Click Save.
  • Click Review + create.
  • Click Create.

Wait for the deployment to complete. You should see a "Your deployment is complete" message.

What do the address space numbers mean?

The address space 10.0.0.0/16 defines the total pool of IP addresses available in your Virtual Network. The /16 means you have 65,536 possible addresses.

Your subnet 10.0.0.0/24 carves out 256 of those addresses for your web resources. You could create additional subnets later for different purposes (databases, admin tools) without them interfering with each other.

Verify your Virtual Network

Before you move on, what do you expect to see listed under your VNet's subnets?

  • In the Azure Portal, navigate to Virtual networks using the search bar.
  • Click on az900-vnet.
  • In the left menu under Settings, click Subnets.

You should see web-subnet listed with an address range of 10.0.0.0/24. This confirms your Virtual Network and subnet are configured correctly.

Don't see web-subnet?

Make sure you clicked Save after editing the subnet name. If you skipped that step, the subnet keeps its original name of default.

Check that you selected the same region for both the Resource Group and the Virtual Network. If the regions differ, the VNet may not appear under your Resource Group.

Help me find my Virtual Network in the Azure Portal.

Your network foundation is ready. Next up, you will launch a Virtual Machine inside this network and connect to it.

Launch Your Virtual Machine

Your Virtual Network and subnet are in place. Now it's time to launch the compute resource that will live inside that network.

Without a running machine, your network is just empty infrastructure with nothing to protect or connect to. In this step, you'll create a Windows Server Virtual Machine and place it in the subnet you built, allowing only RDP access for now.

In this step, get ready to:
  • Create a Windows Server virtual machine in your existing VNet.
  • Configure the VM's network settings to use your custom subnet.
  • Verify the VM is running with a public IP address.
Create the virtual machine

The VM creation wizard in the Azure Portal walks you through several tabs of settings. You'll start on the Basics tab to define the machine's identity, operating system, and access credentials.

  • In the Azure Portal search bar, type Virtual machines.
  • Select Virtual machines from the results.
  • Click + Create.
  • Select Azure virtual machine.
  • In the Resource group dropdown, select az900-vm-lab.
  • In the Virtual machine name field, enter az900-web-vm.
  • In the Region dropdown, select the same region you used for your VNet.
  • In the Image dropdown, select Windows Server 2022 Datacenter: Azure Edition - x64 Gen 2.

Why this image?

Windows Server 2022 Datacenter: Azure Edition is the current recommended image for the Azure free tier. The free tier benefit is based on VM size, not the image itself, so any Windows Server image works. This edition is optimized for Azure with features like hotpatching.

  • Click See all sizes.
  • In the search box, type B2ats.
  • Select Standard_B2ats_v2 from the results.
  • Click Select to confirm your size choice.

Size not available in your region?

If Standard_B2ats_v2 doesn't appear, try searching for B2pts and selecting Standard_B2pts_v2 instead. As a last resort, search for B1s. All three sizes qualify for the Azure free tier (750 hours/month for 12 months).

  • In the Username field, enter azureuser.
  • In the Password field, create a strong password with at least 12 characters, mixing uppercase, lowercase, numbers, and special characters.
  • In the Confirm password field, re-enter your password.
  • Under Inbound port rules, select Allow selected ports.
  • In the Select inbound ports dropdown, select RDP (3389).

Write down your password

You will need this password to connect to your VM via Remote Desktop in the next step. Write it down or save it somewhere safe. Azure will not show it to you again.

Configure networking

Now you'll tell the VM which network and subnet to join. This connects your VM to the infrastructure you built in Step 1.

  • Click the Networking tab at the top of the wizard.
  • In the Virtual network dropdown, select az900-vnet.
  • In the Subnet dropdown, select web-subnet (10.0.0.0/24).
  • Leave Public IP set to (new) so Azure auto-creates one for you.
  • Under NIC network security group, select Basic.

What is a Network Security Group?

A Network Security Group (NSG) acts as a virtual firewall for your VM. It contains rules that allow or deny inbound and outbound network traffic.

By selecting Basic, Azure auto-creates an NSG named az900-web-vm-nsg and adds a rule allowing only the port you selected on the Basics tab (RDP on port 3389). Everything else is blocked by default.

Deploy and verify

You've configured all the settings. Time to launch your VM and confirm it's running.

  • Click Review + create at the bottom of the page.
  • Review the summary to verify your settings are correct.
  • Click Create.

Deployment takes 2-5 minutes. Azure is provisioning your VM, creating its network interface, assigning the Public IP, and attaching the NSG.

  • When deployment completes, click Go to resource.

Before you look at the Overview page, predict: what status do you expect your VM to show?

  • On the VM's Overview page, confirm the Status shows Running.
  • Note the Public IP address displayed on the page. You'll need this in the next step.

What just happened behind the scenes?

Azure created several resources for your VM automatically: a network interface card (NIC) connected to your web-subnet, a managed OS disk, a public IP address, and the NSG az900-web-vm-nsg. All of these live inside your az900-vm-lab resource group.

Deployment failed or VM not running?

If you see a validation error about your password, make sure it is at least 12 characters long and includes at least three of: lowercase letter, uppercase letter, number, and special character.

If the Standard_B2ats_v2 size failed, your region may not have capacity. Delete the failed deployment, go back to Create, and try Standard_B2pts_v2 or Standard_B1s instead.

If status shows Stopped or Deallocated, click Start at the top of the Overview page and wait a minute for it to boot.

Still stuck? Help me troubleshoot my VM deployment failure.

Your VM is running in the cloud, sitting inside the Virtual Network you built. Next, you'll connect to it via Remote Desktop and prove your network security rules work.

Connect to Your VM via RDP

Your VM is running and has a public IP address. Now it's time to prove you can actually reach it.

Remote Desktop Protocol (RDP) lets you control a remote Windows machine as if you were sitting in front of it. By connecting via RDP, you'll validate that your network and firewall rules are letting traffic through on port 3389.

In this step, get ready to:
  • Download the RDP connection file from Azure.
  • Authenticate with your VM credentials.
  • Verify you're inside the Windows Server desktop.
Download and open the RDP file

Azure generates an RDP file that contains the connection settings for your specific VM. Downloading and opening this file launches Remote Desktop Connection with the correct address pre-filled.

  • Return to your VM's Overview page in the Azure Portal.
  • Click Connect at the top of the page.
  • Select Connect from the dropdown options.
  • Under Native RDP, click Download RDP file.
  • Open the downloaded .rdp file from your Downloads folder.

What is an RDP file?

An .rdp file is a shortcut that stores connection details like the server's IP address and display settings. Opening it launches Remote Desktop Connection automatically with those details filled in.

Remote Desktop Connection should now open with your VM's public IP pre-filled.

Authenticate and connect

Your VM requires the admin credentials you created during setup. This is the moment your NSG rule for port 3389 gets tested for real.

  • When the Remote Desktop Connection window appears, click Connect.
  • If you see a certificate warning, click Yes to proceed.
  • Enter your credentials. Username: azureuser. Password: the password you created in Step 2.
  • Click OK to connect.

Why the certificate warning?

Your VM uses a self-signed certificate that your local machine doesn't recognize. This is normal for RDP connections to newly created VMs. Clicking Yes tells your machine to trust this connection.

Connection failing or timing out?

If the connection times out, check that your VM's status is still Running on its Overview page. A deallocated VM won't accept connections.

If your password is rejected, make sure you're entering the credentials exactly as you set them. The username is azureuser (all lowercase).

Help me troubleshoot my RDP connection to my Azure VM

Explore the server

Before you run the connection, what do you expect to see if your network and security rules are configured correctly?

You should now see the Windows Server desktop inside your Remote Desktop Connection window. Server Manager opens automatically. This is the management dashboard for Windows Server.

This machine is running inside your az900-vnet Virtual Network, in the web-subnet, protected by the Network Security Group you configured.

What did this just prove?

The fact that you're inside this VM proves three things are working together: your Virtual Network has connectivity, your public IP is routing traffic correctly, and your NSG's RDP rule (port 3389, priority 300) is allowing your connection through the firewall.

You're now logged into a Windows Server running in the cloud. Next up, you'll install a web server on this machine and discover what happens when you try to access it from outside.

Install a Web Server and Hit the NSG Wall

You proved your VM is reachable by connecting via Remote Desktop. Now it is time to put it to work.

In this step, you will install a web server inside your VM, confirm it is running, and then test whether the outside world can reach it.

In this step, get ready to:
  • Install IIS (a web server) on your VM using PowerShell.
  • Confirm the web server works from inside the VM.
  • Test whether your local browser can reach the web server from outside.
Install IIS on the VM

IIS (Internet Information Services) is Microsoft's built-in web server for Windows Server. You will install it using a single PowerShell command.

  • Switch back to your RDP session on az900-web-vm.
  • Right-click the Start button in the bottom-left corner of the Windows desktop.
  • Select Windows PowerShell from the menu.
  • Install IIS by running this command:
Install-WindowsFeature -name Web-Server -IncludeManagementTools

Wait for the installation to finish. This takes about 1-2 minutes.

What does this command do?

Install-WindowsFeature is a PowerShell cmdlet that adds Windows Server roles and features.

The -name Web-Server flag tells it to install IIS. The -IncludeManagementTools flag adds the admin console so you can configure IIS later if needed.

  • Confirm the output shows Success as True in the results table.

Seeing a red error instead of Success?

  • Make sure you opened PowerShell, not Command Prompt. The Install-WindowsFeature cmdlet only works in PowerShell.
  • Check that you right-clicked the Start button and selected Windows PowerShell specifically.

Why is my IIS install command failing in the VM?

Confirm IIS works locally

Before testing from the outside world, you need to confirm IIS is actually serving pages inside the VM itself.

  • Inside your RDP session, open Microsoft Edge (click the Edge icon in the taskbar at the bottom, or search for it in the Start menu).
  • In the address bar, type http://localhost and press Enter.

You should see the default IIS welcome page. This confirms IIS is running and serving pages successfully inside the VM.

Not seeing the IIS page?

  • Make sure you typed http://localhost (not https). IIS starts with HTTP only.
  • If the install command showed Success: True but the page does not load, try restarting the browser or waiting 30 seconds for IIS to fully start.

Help me get the IIS default page to load on localhost inside my VM.

Try accessing from your local machine

IIS works inside the VM. Now the real question: can the outside world reach it?

  • On your own computer (not inside the RDP session), open a web browser.
  • Paste your VM's public IP address into the address bar, like http://20.xx.xx.xx (use the actual IP from your VM's Overview page).

Before you press Enter, think about this: do you expect to see the IIS page, or do you think something will block it? Why?

  • Press Enter and watch what happens.

The page will time out or show a connection refused error. You will NOT see the IIS welcome page.

Why can't your browser reach the web server?

Your Network Security Group is doing its job. When you created the VM, you only allowed inbound traffic on port 3389 (RDP). Port 80 (HTTP) is blocked by the NSG's default DenyAllInBound rule at priority 65500.

The web server is running perfectly inside the VM. The network firewall is what is stopping outside traffic from reaching it. This is the NSG's default deny behavior in action.

You have felt the NSG's security firsthand. Your web server is running but invisible to the outside world. In the next step, you will write a custom firewall rule to punch through and let HTTP traffic in.

Open Port 80 in Your Network Security Group

In the last step, you proved your Network Security Group is doing its job. Your local browser timed out because the default DenyAllInBound rule at priority 65500 blocks all inbound traffic you haven't explicitly permitted.

Now you'll write a custom inbound rule with a higher priority to let HTTP traffic through on port 80. In Azure NSGs, lower priority numbers are processed first. Your new rule at priority 100 will be evaluated before the default deny at 65500, letting web traffic reach your server.

In this step, get ready to:
  • Navigate to your Network Security Group in the Azure Portal.
  • Add a custom inbound rule to allow HTTP traffic on port 80.
  • Test that the IIS welcome page loads from your local browser.
Navigate to your NSG
  • In the Azure Portal search bar, type Network security groups and select it from the results.
  • Click on az900-web-vm-nsg to open your VM's Network Security Group.

What is this NSG?

When you created your VM with the Basic NIC security group option, Azure automatically created this NSG and attached it to your VM's network interface. It acts as a firewall that evaluates every inbound and outbound packet against your rules.

Add an inbound rule for HTTP
  • In the left menu under Settings, click Inbound security rules.

You'll see the RDP allow rule you created at priority 300, plus three default rules at priorities 65000, 65001, and 65500. The DenyAllInBound rule at 65500 is what blocked your browser in the last step.

How does NSG rule priority work?

Azure evaluates inbound rules from the lowest priority number to the highest. The first rule that matches the traffic wins. Your RDP rule at priority 300 matches port 3389 traffic before the deny-all at 65500 ever gets a chance to block it.

You'll create your HTTP rule at priority 100. That means it will be evaluated before both the RDP rule (300) and the deny-all (65500), so port 80 traffic gets allowed immediately.

  • Click + Add to create a new inbound rule.
  • Set Source to Any.
  • Set Source port ranges to *.
  • Set Destination to Any.
  • Set Destination port ranges to 80.
  • Set Protocol to TCP.
  • Set Action to Allow.
  • Set Priority to 100.

Finally, give your rule a name so you can identify it in the rules list.

  • Set Name to Allow-HTTP.
  • Click Add.

What does this rule do?

Your new rule tells the NSG: allow any TCP traffic destined for port 80 to pass through. Because its priority (100) is lower than the deny-all rule (65500), Azure evaluates it first. Matching traffic gets allowed before the deny rule can block it.

Don't see the + Add button?

Make sure you clicked Inbound security rules under Settings in the left menu, not Outbound security rules. The + Add button appears at the top of the inbound rules list.

Help me find the inbound rules page in my NSG.

Test web access from your local browser

Wait about 30-60 seconds for the new rule to propagate across Azure's network.

Before you refresh, think about what you expect to happen. Will your browser still time out, or will the IIS page load now?

  • On your local machine (not inside the RDP session), switch back to the browser tab where you tried the VM's public IP earlier.
  • Refresh the page.

The IIS default welcome page now loads successfully. You just punched a hole through your firewall for web traffic.

Why does it work now?

Your Allow-HTTP rule at priority 100 matches the inbound TCP traffic on port 80 before the DenyAllInBound rule at priority 65500 gets evaluated. The first matching rule wins, and your allow rule says let it through.

Still seeing a timeout?

Give it another 30 seconds and try a hard refresh (Cmd+Shift+R on macOS or Ctrl+Shift+R on Windows). NSG rule changes can take up to a minute to take effect.

If it still doesn't load, go back to Inbound security rules in your NSG and confirm the Allow-HTTP rule shows Destination port ranges as 80, Protocol as TCP, and Action as Allow.

Help me troubleshoot why my IIS page won't load after adding the NSG rule.

Secret mission

Lock Down Your VM Like a Pro

Right now, anyone on the internet can attempt to RDP into your VM. That is a real security risk. In this mission, you will restrict RDP access to only your IP address and add a blanket Deny rule to block everything else. You will prove you understand how NSG rule priority determines which traffic gets through.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses the Azure free tier, so the VM consumes your 750 free hours per month. Deleting after completion ensures no surprise charges.

Cost warning

Your VM runs on the free tier (750 hours/month of B2ats v2 for 12 months). If your 12-month free period expires or you exhaust your monthly hours, Azure will begin charging for compute time.

If you are done with the lab, delete your resources now to stay safely within free tier limits.

Resources you used:

  • Resource Group: az900-vm-lab (contains all resources below).
  • Virtual Machine: az900-web-vm (Windows Server 2022, Standard_B2ats_v2).
  • Virtual Network: az900-vnet (address space 10.0.0.0/16).
  • Network Security Group: az900-web-vm-nsg (custom inbound rules).
  • Public IP Address (auto-created, assigned to the VM).
  • Managed Disk (OS disk for the VM).
  • Network Interface (connects the VM to web-subnet).

Keep everything running

No action needed. Choose this if you are still actively building or plan to continue experimenting with your VM right away.

  • Your VM will continue consuming free tier hours (750 hours/month for 12 months from account creation).
  • Monitor your remaining free hours in the Azure Portal under Cost Management + Billing.
  • Your RDP session will remain active until you disconnect or the VM restarts.

Pause - I'll come back to this later

Shut down your VM to stop consuming compute hours while keeping all resources intact for later.

  • Close your Remote Desktop Connection window to disconnect from the VM.
  • In the Azure Portal, search for "Virtual machines" and select az900-web-vm.
  • On the VM Overview page, click Stop in the top toolbar.
  • Confirm by clicking Yes when prompted.
  • Wait for the Status to change to "Stopped (deallocated)". Compute billing stops once deallocated.
  • To resume later, return to the VM Overview and click Start.

Delete - I don't want to use this again

Remove all project resources permanently. Deleting the resource group removes the VM, VNet, NSG, Public IP, Disk, and Network Interface in one action.

  • Close your Remote Desktop Connection window.
  • In the Azure Portal search bar, type "Resource groups" and select it.
  • Click on az900-vm-lab.
  • Click Delete resource group in the top toolbar.
  • Type az900-vm-lab in the confirmation field to confirm deletion.
  • Click Delete.
  • Wait for the notification confirming deletion is complete. All resources are now removed.

Nice Work!

Nice Work!

You just built, secured, and verified a live cloud server from scratch. You have a Windows Server VM running in a network you designed, protected by firewall rules you wrote, serving a web page to the public internet.

You've learned how to:

  • Build a Virtual Network with a custom subnet and launch a Windows Server VM in the Azure free tier.
  • Connect to your cloud server via Remote Desktop and install IIS to serve a live web page from the cloud.
  • Write custom Network Security Group firewall rules after experiencing the default deny behavior firsthand.
  • Secret Mission: Locked down RDP access to your IP only and learned how rule priority determines which traffic gets through.

Ready to quiz yourself?