A hands-on lab deploying VNets, peering them securely, provisioning Windows Server VMs, and validating connectivity with Network Watcher.
A solid network foundation sits at the core of every reliable Azure environment. While the Azure Portal is useful for learning, real confidence comes from automation and validation.
In this hands-on lab, I built a complete Azure networking environment from scratch using PowerShell. The setup includes virtual networks, subnets, Windows Server virtual machines, Azure VNet Peering, and connectivity testing using Azure Network Watcher.
The walkthrough reflects how Azure networking is designed, deployed, and verified in real production environments.
🎥 Video Walkthrough
Lab Objectives
By the end of this lab, you will be able to:
-
Provision Azure networking resources using PowerShell
-
Deploy multiple VNets with non-overlapping IP ranges
-
Create and peer VNets securely
-
Provision Windows Server virtual machines
-
Validate VM-to-VM connectivity using Network Watcher
Lab Environment Overview
-
Azure subscription
-
One resource group
-
Two VNets (separate address spaces)
-
One subnet per VNet
-
Two Windows Server VMs
-
VNet peering (bi-directional)
-
Azure Network Watcher enabled
Create a Resource Group
A dedicated resource group keeps networking and compute resources organized and easy to manage.
PowerShell Command
# Sign in to Azure (run once per session)
Connect-AzAccount
# Create a resource group
New-AzResourceGroup `
-Name "rg-azure-networking-lab" `
-Location "East US"
Deploy Virtual Networks and Subnets
Two VNets were created with distinct CIDR ranges to avoid overlap and support peering.
Example Design
-
VNet-A:
10.10.0.0/16 -
VNet-B:
10.20.0.0/16
Each VNet contains a dedicated subnet for VM workloads.
Provision Windows Server Virtual Machines
A Windows Server VM was deployed into each VNet using PowerShell, with NICs correctly associated with their respective subnets.
This step mirrors how infrastructure teams automate compute deployment rather than relying on manual portal clicks.
Configure Azure VNet Peering
Azure VNets are isolated by default, even within the same subscription.
VNet peering was configured to:
-
Enable private communication between VNets
-
Use Azure’s backbone network
-
Avoid public internet exposure
Both directions of peering were created to allow full two-way communication.
Verify Connectivity with Azure Network Watcher
To validate the network configuration, Network Watcher connection troubleshooting was used to:
-
Simulate VM-to-VM communication
-
Test RDP connectivity on port 3389
-
Identify routing or NSG issues
This step confirms not just deployment but correct functionality.
Why Network Watcher Matters
Network Watcher provides visibility into:
-
Reachability issues
-
Routing problems
-
NSG misconfigurations
Using it early prevents silent failures that often appear later in production.
Key Takeaway
Strong Azure networking skills go beyond deployment.
Confidence comes from:
-
Automation with PowerShell
-
Clean network design
-
Secure peering
-
Proper verification and troubleshooting
This lab bridges the gap between beginner knowledge and production-ready Azure networking
