This script lists all session hosts with their host pool, VM name, and VM size across all host pools(loop through multiple resource groups):

Connect-AzAccount

# Get all host pools
$hostPools = Get-AzWvdHostPool

# Get all VMs in the subscription once
$allVMs = Get-AzVM

# Prepare output array
$allVMInfo = @()

foreach ($pool in $hostPools) {
    $sessionHosts = Get-AzWvdSessionHost -ResourceGroupName $pool.ResourceGroupName -HostPoolName $pool.Name

    foreach ($sessionHost in $sessionHosts) {
        $vmName = $sessionHost.Name.Split("/")[-1]

        # Search for the matching VM in all VMs
        $vm = $allVMs | Where-Object { $_.Name -eq $vmName }

        $vmSize = if ($vm) { $vm.HardwareProfile.VmSize } else { "Not Found" }
        $vmRG = if ($vm) { $vm.ResourceGroupName } else { "Unknown" }

        $allVMInfo += [PSCustomObject]@{
            HostPool     = $pool.Name
            SessionHost  = $sessionHost.Name
            VMName       = $vmName
            VMSize       = $vmSize
            ResourceGroup = $vmRG
            Status       = $sessionHost.Status
        }
    }
}

# Display the result
$allVMInfo | Format-Table

# Optional: export to CSV
$allVMInfo | Export-Csv -Path "AVD_VM_Sizes.csv" -NoTypeInformation

Exercise Scenario

To connect your Azure virtual network to your on-premises network using ExpressRoute, you must first create a virtual network gateway. A virtual network gateway serves two key purposes:

• To exchange IP routes between the networks

• To route network traffic between them

Note: The interactive lab simulations previously available for this exercise have been retired.

Estimated Time: 60 minutes (includes approximately 45 minutes of deployment wait time)

Gateway Types

When creating a virtual network gateway, several settings must be configured. One essential setting is -GatewayType, which determines whether the gateway is used for ExpressRoute or VPN traffic. The two gateway types are:

• VPN – Use this gateway type to send encrypted traffic over the public internet. Commonly referred to as a VPN Gateway, it supports Site-to-Site, Point-to-Site, and VNet-to-VNet connections.

• ExpressRoute – Use this gateway type for private, dedicated connections. This is referred to as an ExpressRoute Gateway and is specifically used when configuring ExpressRoute.

Note: Each virtual network can have only one virtual network gateway per gateway type. For example, you can have one gateway with -GatewayType VPN and another with -GatewayType ExpressRoute in the same virtual network.

Job Skills

In this lab, you will:

• Create a virtual network and gateway subnet

• Create a virtual network gateway

Task 1: Create the VNet and Gateway Subnet

1. In the Azure portal, in the Search resources, services, and docs box, enter virtual network, then select Virtual networks from the results.

2. On the Virtual networks page, select + Create.

3. In the Create virtual network pane, on the Basics tab, enter the following values:

4. Select Next: IP Addresses.

5. In the IP Addresses tab, under IPv4 address space, enter:
   10.20.0.0/16,
   then select + Add subnet.

6. In the Add subnet pane, enter:

Note: The subnet name will be auto-filled as GatewaySubnet.

7. Select Add.

8. On the Create virtual network page, select Review + Create.

9. After validation passes, select Create.

Note: If you're using a dual-stack virtual network and plan to use IPv6 private peering over ExpressRoute, select Add IPv6 address space and enter the required range.

Task 2: Create the Virtual Network Gateway

1. In the Azure portal, in Search resources, services and docs, enter virtual network gateway, then select Virtual network gateways from the results.

2. On the Virtual network gateways page, select + Create.

3. In the Create virtual network gateway page, use the following configuration:

4. Select Review + Create.

5. After validation, select Create.

6. Once deployment completes (this may take up to 45 minutes), select Go to resource.

Extend Your Learning with Copilot

Use Microsoft Copilot to explore more about Azure networking tools and options. Try these prompts in the Edge browser or visit copilot.microsoft.com:

• How is Azure ExpressRoute different from Virtual WAN? Can they be used together? Provide examples.

• What are the key considerations when choosing between ExpressRoute Provider Model and ExpressRoute Direct?

• Create a comparison table of ExpressRoute SKUs and their features.

Learn More with Self-Paced Training

• Introduction to Azure ExpressRoute
  Learn what Azure ExpressRoute is and the functionality it provides.

• Design and Implement ExpressRoute
  Understand how to design and implement ExpressRoute, ExpressRoute Global Reach, and ExpressRoute FastPath.

Key Takeaways

• Azure ExpressRoute enables private, dedicated connections between your on-premises network and Azure/Microsoft 365 services.

• Microsoft guarantees 99.95% availability for ExpressRoute connections.

• Traffic travels over a private, dedicated circuit—third parties cannot intercept the traffic.

• ExpressRoute connections can be established through four models:

  • CloudExchange Co-location

  • Point-to-Point Ethernet

  • Any-to-Any (IPVPN)

  • ExpressRoute Direct

• ExpressRoute features are determined by the SKU: Local, Standard, and Premium.

Scenario

You will configure a VPN gateway to securely connect CoreServicesVnet (East US) and ManufacturingVnet (North Europe) using VNet-to-VNet VPN.

• Task 1: Create CoreServicesVnet and ManufacturingVnet

• Task 2: Create CoreServicesVM

• Task 3: Create ManufacturingVM

• Task 4: Connect to the VMs using RDP

• Task 5: Test the connection between the VMs

• Task 6: Create CoreServicesVnet Gateway

• Task 7: Create ManufacturingVnet Gateway

• Task 8: Connect CoreServicesVnet to ManufacturingVnet

• Task 9: Connect ManufacturingVnet to CoreServicesVnet

• Task 10: Verify that the connections connect

• Task 11: Test the connection between the VMs

For more info click on the image below:

Task 1: Create CoreServicesVnet and ManufacturingVnet

1. Open Cloud Shell in the Azure portal and select PowerShell.

2. Upload: azuredeploy.json and azuredeploy.parameters.json

3. Run:

$RGName = "ContosoResourceGroup"
New-AzResourceGroup -Name $RGName -Location "eastus"
New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile azuredeploy.json -TemplateParameterFile azuredeploy.parameters.json

Task 2 & 3: Create CoreServicesVM and ManufacturingVM

1. Upload:CoreServicesVMazuredeploy.json and ManufacturingVMazuredeploy.json

2. Run (for each):

New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile <template>.json -TemplateParameterFile <parameters>.json

e.g. for manufacturingvm:

$RGName = "ContosoResourceGroup" 
New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile ManufacturingVMazuredeploy.json -TemplateParameterFile ManufacturingVMazuredeploy.parameters.json

Task 4: Connect to VMs Using RDP

1. In Azure Portal, go to Virtual Machines.

2. Select each VM, click Connect > RDP, download and open the file.

3. Log in with:

   • Username: TestUser

   • Password: (used during deployment)

4. Accept privacy settings and select Yes on network prompt.

5. On CoreServicesVM, run:

    ipconfig
   

   • Note the IPv4 address.

Task 5: Test Initial Connection (Should Fail)

1. On ManufacturingVM, run:

    Test-NetConnection <CoreServicesVM_IP> -Port 3389
   

   • Connection should fail.

Task 6: Create CoreServicesVnet Gateway

1. Go to Virtual Network Gateways > + Create.

2. Use the following settings:

   • Name: CoreServicesVnetGateway

   • Region: East US

   • Gateway type: VPN

   • SKU: VpnGw1

   • Generation: 1

   • Virtual Network: CoreServicesVnet

   • Subnet: GatewaySubnet (10.20.0.0/27)

   • Public IP: Create new → Name: CoreServicesVnetGateway-ip (disable active-active mode)

Task 7: Create ManufacturingVnet Gateway

1. In ManufacturingVnet, go to Subnets > + Subnet.

   • Purpose: GatewaySubnet

   • Size: /27

2. Then create the gateway:

   • Name: ManufacturingVnetGateway

   • Region: North Europe (to be able to select manufacturing vnet)

   • Same settings as above

   • Public IP name: ManufacturingVnetGateway-ip (disable active-active)

Task 8: Connect CoreServicesVnet to ManufacturingVnet

1. Go to CoreServicesVnetGateway > Connections > + Add.

2. Use these settings:

   • Name: CoreServicesGW-to-ManufacturingGW

   • Connection type: VNet-to-VNet

   • First vnet Gateway: CoreServicesVnetGateway

   • Second Vnet Gateway: ManufacturingVnetGateway

   • Shared key: abc123

   • Protocol: IKEv2

   • Region: East US

Task 9: Connect ManufacturingVnet to CoreServicesVnet

1. Go to ManufacturingVnetGateway > Connections > + Add.

2. Use:

   • Name: ManufacturingGW-to-CoreServicesGW

   • Connection type: VNet-to-VNet

   • First Vnet Gateway: ManufacturingVnetGateway

   • Second Gateway: CoreServicesVnetGateway

   • Shared key: abc123

   • Region: North Europe

Task 10: Verify VPN Connection

1. Go to Connections in Azure portal.

2. Refresh until both connections show Connected.

Task 11: Test Final Connection

1. On ManufacturingVM, run:

    Test-NetConnection <CoreServicesVM_IP> -Port 3389
   

   • Connection should succeed.

Clean Up Resources

To delete the resources, run:

Remove-AzResourceGroup -Name 'ContosoResourceGroup' -Force -AsJob

Extend Your Learning

Try these prompts in Microsoft Copilot:

1. What are the types of Azure VPN gateways? Azure supports three main types of VPN gateway configurations:

You can mix S2S, P2S, and VNet-to-VNet on the same gateway (with compatible SKUs).

2. How do VPN gateway SKUs differ? Azure VPN Gateway SKUs differ by performance, features, and pricing. Key differences include:

Tip: Choose based on bandwidth needs, tunnel count, and features like BGP or zone redundancy.

3. What are the costs for Azure VPN gateways?Azure VPN Gateway pricing depends on:

   • SKU selected (Basic, VpnGw1, etc.)

   • Data transfer (ingress is free; egress has cost)

   • Time-based billing (hourly rate)

   • Optional features (e.g., zone redundancy)

Example (as of 2024 – subject to change):

Key Takeaways

• Azure VPN Gateway provides secure cross-region or hybrid connectivity using IPsec/IKE.

• VNet-to-VNet connections require gateways in each VNet and shared keys for IPsec tunnels.

• Bidirectional configuration is necessary.

• Different SKUs provide different performance levels and costs.

M02 - Unit 7: Create a Virtual WAN Using Azure Portal

Scenario

In this exercise, you’ll create a Virtual WAN for Contoso, including a hub and a VNet connection. click on the image below for more inforamtion:

Tasks

• Task 1: Create a Virtual WAN

• Task 2: Create a hub by using Azure Portal

• Task 3: Connect a VNet to the Virtual Hub

Task 1: Create a Virtual WAN

1. Go to the Azure Portal.

2. Search for Virtual WANs and select + Create.

3. On the Basics tab, fill in:

   • Subscription: (Use existing)

   • Resource Group: ContosoResourceGroup

   • Location: Any region (WAN is global, but region needed for resource placement)

   • Name: ContosoVirtualWAN

   • Type: Standard

4. Select Review + Create, then Create.

Task 2: Create a Virtual Hub

1. Open the ContosoVirtualWAN you created.

2. Under Connectivity, select Hubs > + New Hub.

3. On the Basics tab:

   • Region: West US

   • Name: ContosoVirtualWANHub-WestUS

   • Hub private address space: 10.60.0.0/24

   • Capacity: 2 Routing infrastructure units

   • Leave routing preference as default.

4. Go to the Site-to-site tab:

   • Create Site-to-site VPN Gateway: Yes

   • Gateway scale units: 2

   • Leave AS number and routing preference as default.

5. Click Review + Create, then Create.

Note: VPN gateway creation can take up to 30 minutes.

Task 3: Connect a VNet to the Virtual Hub

1. Go to the ContosoVirtualWAN > Virtual network connections > + Add connection.

2. Fill in:

   • Connection name: ContosoVirtualWAN-to-ResearchVNet

   • Hub: ContosoVirtualWANHub-WestUS

   • Subscription: (No change)

   • Resource Group: ContosoResourceGroup

   • Virtual network: ResearchVNet

   • Propagate to none: Yes

   • Associate Route Table: Default

3. Select Create.

Clean Up Resources

In Cloud Shell, run:

Remove-AzResourceGroup -Name 'ContosoResourceGroup' -Force -AsJob

Extend Your Learning with Copilot

Try these questions at copilot.microsoft.com:

1. What type of network architecture does Azure VWAN use?Azure Virtual WAN uses a hub-and-spoke architecture.

   • The hub is a Microsoft-managed virtual network that acts as a central point for connectivity.

   • Spokes include VNets, branch offices (via site-to-site VPN), remote users (via point-to-site VPN), and ExpressRoute circuits.

   • Traffic between spokes flows through the hub using Microsoft’s global backbone, enabling optimized, scalable, and secure routing.

2. What are the differences between Azure VWAN Basic and Standard?

• Use Basic for simple S2S VPN-only deployments.

• Use Standard for full enterprise, hybrid, or global network integration.

3. Can I create an Azure VWAN using scripting tools?Yes. Azure VWAN supports deployment via:

• Azure CLI

az network vwan create --name ContosoVirtualWAN --resource-group ContosoResourceGroup --location eastus --type Standard

• Azure PowerShell

New-AzVirtualWan -ResourceGroupName "ContosoResourceGroup" -Name "ContosoVirtualWAN" -Location "East US" ` -Type "Standard"

Key Takeaways

• Azure Virtual WAN simplifies global connectivity using a hub-and-spoke architecture.

• Use cases include: Site-to-Site, Point-to-Site, and ExpressRoute.

• Basic VWAN supports only Site-to-Site VPN.

• Standard VWAN supports all scenarios, including enhanced routing, hubs, and multiple VPN types.

Azure ExpressRoute is a private, enterprise-grade connection that enables secure and reliable network connectivity between your on-premises infrastructure and Microsoft’s global network. It bypasses the public internet and provides high throughput, low latency, and consistent performance for mission-critical workloads.

Architecture Overview

Azure ExpressRoute uses a hub-and-spoke model involving:

• A physical on-premises site(on the left)

• Private fiber connectivity to Microsoft’s edge

• Microsoft Secure Edge routers

• Azure VNets (private address space)

• Microsoft public services (e.g., Microsoft 365, Azure SQL, Storage)

A Meet-Me Room (MMR) is a secure physical location within a colocation data center where multiple telecommunications carriers, cloud providers (like Microsoft), and enterprises interconnect their networks.

Connection Models

1. ExpressRoute via Service Provider Model (Layer 3)

• Connectivity is managed through a partner or a colocation facility.

• The partner establishes the cross-connect to Microsoft’s edge via a Meet Me Room (MMR).

• Suitable for standard enterprise workloads with high availability (two connections) and moderate control.

2. ExpressRoute Direct (Layer 2)

• Provides a dedicated port pair (10 Gbps or 100 Gbps) directly to Microsoft.

• Enables direct monitoring (e.g., signal light levels, propagation).

• Offers granular control and is ideal for enterprises needing extreme performance and flexibility.

• Requires customer setup and responsibility for all routing and cabling.

ExpressRoute Circuit

A circuit is the logical container for the ExpressRoute connection. Once provisioned:

• You can attach it to virtual networks.

• Use it for both public and private Azure services.

• Choose bandwidth, location, SKU, and routing preferences.

A Meet-Me Room (MMR) is a secure physical location within a colocation data center where multiple telecommunications carriers, cloud providers (like Microsoft), and enterprises interconnect their networks.

in the image below (express direct) we have a 100Gbps fiber connection between on-prem and microsoft secure edge, with two differnt circut one 40 Gbps to m365 services and one 5 Gbps to azure services.

• ExpressRoute is the overall Azure service that enables private connectivity between your on-premises network and Microsoft cloud services.

• SKU Options refer to the tiers and configurations you choose when provisioning an ExpressRoute circuit — essentially, SKUs are part of the circuit configuration.

SKU Options

• Standard: Access to Azure services within a geopolitical region(e.g. US east, US West).

• Local: Restricts access to one (sometimes two) Azure region. Lower cost.

• Premium: Enables global access across regions and increases route limits.

Each SKU allows varying capabilities depending on network size, access needs, and resiliency requirements.

Edge and Region Mapping

• ExpressRoute peering is done at Microsoft Edge locations.

• These are globally distributed and not limited to Azure regions.

• For example, a customer in Perth can peer through a local Edge site to reach multiple paired Azure regions.

Billing Models

Two billing options are available:

1. Unlimited data: Fixed monthly fee with unrestricted traffic.

2. Metered data: Pay-per-GB model; more cost-effective for lighter usage.

The Azure pricing calculator helps determine the best model based on expected throughput.

Deployment Process in Azure Portal

The complete setup may take several weeks, but we can start by reviewing how the provisioning process works in the Azure portal, assuming the cabling is correctly positioned.

1. Create an ExpressRoute circuit.

2. Choose deployment region and provider.

3. Select SKU, bandwidth and billing method

if we choose provider model depends on the region that we select we have different provider:

Next, configure the gateway to land traffic—this process will be familiar if you’ve set up a VPN gateway before(we just select express route instead of VPN).

1. Provision a virtual network gateway in Azure.

2. Attach the gateway to the ExpressRoute circuit.

3. Complete provider-side setup or configure Direct ports.

Express Route Peering Types:

What actually goes across our express route circuit?

1. Private peering

2. Microsoft peering

Here one connection across an Expressroute can carry both Microsoft peering traffic and private peering traffic, you can use one or the other or both:

So one connection through express route can carry both microsoft and private peering traffic.

Private Peering in Azure ExpressRoute

Private peering is used to access Azure Virtual Networks (VNets) through private IP address space. It enables connectivity between your on-premises network and Azure resources via ExpressRoute.

Configuration requirements:

• IP subnets: Two subnets not part of any VNet address space—one for the primary link, one for the secondary.

• VLAN ID: A valid on-premises VLAN ID to establish the peering.

• ASN: An Autonomous System Number for BGP peering.

• BGP session: Configure your on-prem Edge router to advertise routes to Azure via BGP.

• MD5 hash (optional): Use for BGP session authentication if required.

VLAN ID is used in ExpressRoute private peering to separate traffic types at the data link layer between your router and Microsoft’s edge (MSEE). VNets don’t use VLANs because they operate at Layer 3, using subnets, route tables, and security rules for isolation.

Now, once you have this private pairing established, we just need to go through and actually do the connection itself.

If you have a provisioned ExpressRoute circuit, go to the Connections tab and select Add. Then, choose the virtual network you want to connect. You’ll need a gateway subnet in the VNet, along with an ExpressRoute gateway—either already provisioned or created during this step. Once the gateway is in place, you can configure additional settings such as routing weight for traffic distribution.

Microsoft Peering in Azure ExpressRoute

Microsoft peering enables private connectivity to Microsoft public services such as Microsoft 365, Azure Storage, and Azure SQL via ExpressRoute.

Configuration requirements:

• Public IP prefixes: Must be owned by your organization and registered with a recognized Routing Internet Registry (RIR/IRR).

• Subnets: A pair of registered subnets—one for the primary link, one for the secondary.

• ASN: Autonomous System Number used for BGP peering.

• VLAN ID: Valid on-premises VLAN ID for establishing the peering session.

• Advertised prefixes: A list of all public IPs your organization plans to advertise over the BGP session.

• Routing Registry Name: The registry (e.g., ARIN, RIPE) that confirms ownership of the advertised prefixes.

• BGP configuration: To establish routing between your network and Microsoft.

• Route filters: Define which Microsoft services and regions are accessible over the peering session.

Route Filters and BGP Communities

• Route filters control which services we want to carry over Microsoft Peering.

• BGP communities identify specific Azure services and regions.

• You can selectively include services like Storage or SQL while excluding services like Exchange or SharePoint, which are optimized for internet routing.

Consider this scenario: you’re a customer consuming Azure services hosted in Australia East, and you’re specifically interested in accessing storage services. Instead of routing all Microsoft traffic through your ExpressRoute circuit, you can apply a route filter to select a BGP community that corresponds only to Azure Storage in Australia East. This allows you to target exactly the services you need.

You’re not required to select all traffic types. In fact, services like Microsoft 365 (e.g., Exchange Online, SharePoint) are designed and optimized for internet routing, so using ExpressRoute for them is typically unnecessary unless you have a specialized scenario. Using route filters gives you precise control over what traffic flows through your ExpressRoute circuit.

Resiliency and High Availability

In the context of “Resiliency and High Availability” for Azure ExpressRoute, resiliency refers to the system’s ability to recover quickly from failures and continue operating with minimal disruption. Here’s how it breaks down:

Resiliency ensures your network connection can withstand failures (e.g. link failure, hardware fault) without going down completely.

High Availability complements this by ensuring constant uptime—you always have at least one active path for traffic.

• ExpressRoute circuits are active-active by default.

• Each circuit has dual connections and subnets.

• Use Bidirectional Forwarding Detection (BFD) for rapid failure detection.(BFD is able to detect if an express route goes down very quickly)

• BFD is enabled by default and helps reduce failover time from minutes to seconds.

Multi-Region Redundancy

• Enterprises can provision ExpressRoute circuits in multiple Azure regions.

• Weighted BGP routing enables active-passive or load-balanced setups.

• Multiple circuits can serve as failover paths.

Hybrid Redundancy with VPN (as a secondry failover for express route)

• A VPN can serve as a backup for ExpressRoute in case of circuit failure.

• This creates two diverse paths:

  • Private fiber (ExpressRoute)

  • Public internet (VPN)

• The same Azure VPN gateway can serve dual purposes (primary for VPN, failover for ExpressRoute).

Encryption over ExpressRoute

By default, ExpressRoute traffic is private but not encrypted. Two encryption options exist:

1. Overlay VPN (IPsec): Create a VPN tunnel over the ExpressRoute connection.

2. MACsec: Layer 2 encryption available with ExpressRoute Direct.

Encryption should be planned during initial deployment to meet compliance requirements.

ExpressRoute Global Reach

• Enables connectivity between two on-premises sites through Microsoft’s global network.

• Bypasses Azure VNets entirely.

• Use case: connecting San Francisco and London data centers via existing ExpressRoute circuits.

This is configured by linking the two circuits and enabling route propagation between them.

FastPath

• Improves performance for high-throughput scenarios.

• Bypasses the ExpressRoute gateway after initial setup (control plane) and sends traffic directly on the data plane.

• Requires Ultra Performance Gateway SKU (Gateway v3).

• Ideal for scenarios like remote desktop sessions, where low latency is critical.

Configure ExpressRoute FastPath:

Updating an existing connection to enable FastPath:

$connection = Get-AzVirtualNetworkGatewayConnection -Name "MyConnection" -ResourceGroupName "MyRG"
$connection.ExpressRouteGatewayBypass = $True
Set-AzVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection

Monitoring and Troubleshooting ExpressRoute Connection

Verify circuit provisioning and state through the Azure portal

Get-AzExpressRouteCircuit

• Shows all the backend data for current express route that is provisioned including: provisioning state, bandwidth, provider, location, etc.

Provider Status: Provisioned → The service provider has completed their setup.

Circuit Status: Enabled → You (the customer) have finished your side of the configuration.

These two indicators help you quickly understand where the setup stands and who is responsible for the next step.

Reset a failed circuit:

Connect-AzAccount 
Get-AzSubscription 
Select-AzSubscription -SubscriptionName "Replace_with_your_subscription_name" 
$ckt = Get-AzExpressRouteCircuit -Name "ExpressRouteARMCircuit" -ResourceGroupName "ExpressRouteResourceGroup" 
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

Set-AzExpressRouteCircuit

• Refreshes a circuit even without changes. Useful for resetting failed states.

Validate Peering Configuration

ExpressRoute circuit is up and running, but peering isn’t functioning properly (we’re not seeing private or Microsoft traffic flow across the connection)

• Check connection and provisioning status under the circuit’s Peering tab.

• Ensure subnets and peerings are configured and advertised correctly.

Validate ARP: Layer 2 Diagnostics

• Use ARP tables to validate device connections and MAC-level communication.

Network Performance Testing

• Use the Azure Connectivity Toolkit (Azure Cwrt) to simulate and test:

  • Throughput

  • Latency

  • Packet behavior

• Also supports synthetic traffic testing with different packet sizes and patterns.

• 

Summary: Service Provider Model vs. Direct

Final Considerations

• Choose the right SKU and model (Direct vs Provider) based on:

  • Bandwidth needs

  • Regional access

  • Security/compliance requirements

• Configure peering, encryption, and redundancy early to avoid operational complexity later.

• Monitor proactively using built-in tools and routing visibility.

1. CoreServicesVnet

• Region: East US

• Purpose: Main network (web services, databases, shared services like DC/DNS).

• Connectivity: Needs VPN connection to on-premises.

• Address Space: Large (because of expected growth).

• Address Space: 10.20.0.0/16

• Subnets:

  • GatewaySubnet → 10.20.0.0/27

  • SharedServicesSubnet → 10.20.10.0/24

  • DatabaseSubnet → 10.20.20.0/24

  • PublicWebServiceSubnet → 10.20.30.0/24

2. ManufacturingVnet

• Region: West Europe

• Purpose: Manufacturing operations, lots of connected devices (IoT).

• Connectivity: No mention of VPN, but must support many devices.

• Address Space: Medium to Large, scalable.

• Address Space: 10.30.0.0/16

• Subnets:

  • ManufacturingSystemSubnet → 10.30.10.0/24

  • SensorSubnet1 → 10.30.20.0/24

  • SensorSubnet2 → 10.30.21.0/24

  • SensorSubnet3 → 10.30.22.0/24

3. ResearchVnet

• Region: Southeast Asia

• Purpose: Research & Development (small, stable).

• Connectivity: No VPN mentioned.

• Address Space: Small

• Address Space: 10.40.0.0/16

• Subnet:

  • ResearchSystemSubnet → 10.40.0.0/24

Click on the image above for more info

You will create the following resources:

These virtual networks and subnets are designed to support current resources and future growth.

In this exercise, you will:

• Task 1: Create the Contoso resource group.

• Task 2: Create CoreServicesVnet and its subnets.

• Task 3: Create ManufacturingVnet and its subnets.

• Task 4: Create ResearchVnet and its subnet.

• Task 5: Verify the VNets and Subnets are created.

Lab Instructions: Create Resource Group, Virtual Networks, and Subnets

Task 1: Create the Contoso Resource Group

1. Go to the Azure portal.

2. On the home page, under Azure services, select Resource groups.

3. Select + Create.

4. Configure as follows:

   • Resource group: ContosoResourceGroup

   • Region: (US) East US

   • Tags: No changes needed

5. Click Review + create, then Create.

6. Verify that ContosoResourceGroup appears in the Resource Groups list.

Task 2: Create the CoreServicesVnet Virtual Network and Subnets

1. From the Azure portal, search for Virtual Networks in the Global Search bar and select it.

2. Select + Create.

3. Configure as follows:

   • Resource Group: ContosoResourceGroup

   • Name: CoreServicesVnet

   • Region: (US) East US

   • IPv4 address space: 10.20.0.0/16

     (Remove or overwrite the default address space)

4. Add subnets:

   • GatewaySubnet

     • Subnet purpose: Virtual Network Gateway

     • Subnet address range: 10.20.0.0/27

   • SharedServicesSubnet

     • Subnet address range: 10.20.10.0/24

   • DatabaseSubnet

     • Subnet address range: 10.20.20.0/24

   • PublicWebServiceSubnet

     • Subnet address range: 10.20.30.0/24

5. After adding subnets, select Review + create.

6. Verify validation passes, then select Create.

Task 3: Create the “ManufacturingVnet” Virtual Network and Subnets

1. Repeat steps 1–6.

2. Configure as follows:

   • Resource Group: ContosoResourceGroup

   • Name: ManufacturingVnet

   • Region: (Europe) West Europe

   • IPv4 address space: 10.30.0.0/16

3. Add subnets:

   • ManufacturingSystemSubnet: 10.30.10.0/24

   • SensorSubnet1: 10.30.20.0/24

   • SensorSubnet2: 10.30.21.0/24

   • SensorSubnet3: 10.30.22.0/24

4. Review, validate, and create.

Task 4: Create the “ResearchVnet” Virtual Network and Subnet

1. Repeat steps 1–6.

2. Configure as follows:

   • Resource Group: ContosoResourceGroup

   • Name: ResearchVnet

   • Region: Southeast Asia

   • IPv4 address space: 10.40.0.0/16

3. Add subnet:

   • ResearchSystemSubnet: 10.40.0.0/24

4. Review, validate, and create.

Task 5: Verify the Creation of VNets and Subnets

1. In the Azure portal home page, select All resources.

2. Verify the following VNets exist:

   • CoreServicesVnet

   • ManufacturingVnet

   • ResearchVnet

3. For each VNet:

   • Select the VNet.

   • Under Settings, select Subnets.

   • Confirm all subnets and IP address ranges are correct.

Key Takeaways

• Azure Virtual Network is the building block for your private network in Azure.

• Ensure non-overlapping address spaces between networks.

• Subnets allow resource segmentation and future expansion planning.

• Always reserve extra IP space for future subnet growth.

M01 - Unit 6 Configure DNS settings in Azure

Exercise Scenario

In this unit, you will configure DNS name resolution for Contoso Ltd. You will create a private DNS zone named contoso.com, link VNets for registration and resolution, create two VMs, and test the configuration.

Tasks:

• Task 1: Create a private DNS Zone

• Task 2: Link VNets for auto registration

• Task 3: Create Virtual Machines to test the configuration

• Task 4: Verify records in the DNS zone

Click on the picture below for more info:

Task 1: Create a Private DNS Zone

1. Go to the Azure Portal.

2. In the search bar, enter DNS and select Private DNS zones.

3. Select + Create and fill in:

   • Resource Group: ContosoResourceGroup

   • Name: contoso.com

   • 

4. Select Review + create, then Create.

Task 2: Link VNets for Auto Registration

1. In contoso.com, under DNS Management, select Virtual network links → + Add.

2. Add the following links:

   • CoreServicesVnetLink

     • Virtual Network: CoreServicesVnet

     • Auto registration: Enabled

   • ManufacturingVnetLink

     • Virtual Network: ManufacturingVnet

     • Auto registration: Enabled

   • ResearchVnetLink

     • Virtual Network: ResearchVnet

     • Auto registration: Enabled

3. After each, select Refresh and verify the links and auto-registration are enabled.

Task 3: Create Virtual Machines to Test

1. In the Azure portal, open the Cloud Shell (top-right icon). Select PowerShell.

2. Upload files azuredeploy.json and azuredeploy.parameters.json from F:\Allfiles\Exercises\M01.

3. Run the following command:

    powershellCopyEdit$RGName = "ContosoResourceGroup"
    New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile azuredeploy.json -TemplateParameterFile azuredeploy.parameters.json
   

4. After deployment, verify two VMs are created in Virtual Machines.

Task 4: Verify Records in DNS Zone

1. In Private DNS zones, open contoso.com.

2. Verify host (A) records for both VMs are listed.

3. Note their names and IP addresses.

Connect to Test VMs via RDP

1. In Virtual Machines, select TestVM1 → Connect > RDP → Download the RDP file.

2. Repeat for TestVM2.

3. Connect to the VMs and on both VMs:

   • Accept Privacy settings if prompted.

   • Select Yes if asked about Network discoverability (may not appear on Windows Server).

Test Name Resolution

On TestVM1:

1. Open Command Prompt.

2. Run: ipconfig /all (Verify IP matches what you noted earlier.)

3. Run: ping TestVM2.contoso.com (Ping may timeout because of Windows Firewall.)

4. Alternatively, run: nslookup TestVM2.contoso.com (Verify successful name resolution.)

Extend Your Learning with Copilot

Use copilot.microsoft.com to explore:

• Differences between Azure DNS and Azure Private DNS.

• Purpose of auto-registration in Azure Private DNS.

  • No need for manual DNS record management.

  • Ensures DNS is always up to date — even if VMs restart or their IPs change.

  • Great for dynamic environments where VMs are created and deleted often.

Key Takeaways

• Azure DNS hosts DNS domains for public and private use.

• Public zones resolve domains over the internet.

• Private DNS zones manage DNS inside Azure VNETs.

• DNS zones are collections of DNS records mapping domain names to information.

2- link subnet

M01 - Unit 8: Connect Two Azure Virtual Networks Using Global Virtual Network Peering

Exercise Scenario

In this lab, you will configure connectivity between CoreServicesVnet and ManufacturingVnet by setting up global VNet peering.

Tasks:

• Task 1: Create a Virtual Machine to test the configuration

• Task 2: Connect to Test VMs using RDP

• Task 3: Test the connection between the VMs

• Task 4: Create VNet peerings between CoreServicesVnet and ManufacturingVnet

• Task 5: Test the connection again

Task 1: Create a Virtual Machine (ManufacturingVM)

1. Open Azure Portal → Click Cloud Shell → Choose PowerShell.

2. Select No Storage Account required if prompted, then Apply.

3. Upload these files to Cloud Shell:

   • ManufacturingVMazuredeploy.json

   • ManufacturingVMazuredeploy.parameters.json

4. Deploy the VM:

    $RGName = "ContosoResourceGroup"
    New-AzResourceGroupDeployment -ResourceGroupName $RGName -TemplateFile ManufacturingVMazuredeploy.json -TemplateParameterFile ManufacturingVMazuredeploy.parameters.json
   

5. After deployment, verify that ManufacturingVM is created.

Task 2: Connect to the Test VMs Using RDP

1. Go to Virtual Machines → Select ManufacturingVM → Connect > RDP → Download RDP File.

2. Save and connect (Repeat for TestVM1.)

3. On both VMs:

   • Accept privacy settings.

   • Select Yes for network discoverability (if prompted).

4. On TestVM1, open PowerShell, run: ipconfig, note the IPv4 address.

Task 3: Test Initial Connection Between VMs

1. On ManufacturingVM, open PowerShell.

2. Test connectivity to TestVM1's IP (example 10.20.20.4):

    Test-NetConnection 10.20.20.4 -Port 3389
   

   • Connection should fail (no peering yet). ( VMs are in two different VNets: TestVM1 is in CoreServicesVnet & ManufacturingVM is in ManufacturingVnet)

Task 4: Create VNet Peerings

1. In Azure Portal, go to Virtual Networks → Select CoreServicesVnet → Peerings → + Add.

2. Configure:

   • Peering link name: CoreServicesVnet-to-ManufacturingVnet

   • Virtual Network: ManufacturingVnet

   • Enable:

     • Allow CoreServicesVnet to access ManufacturingVnet

     • Allow forwarded traffic

3. In ManufacturingVnet, create reverse peering:

   • Peering link name: ManufacturingVnet-to-CoreServicesVnet

   • Enable:

     • Allow ManufacturingVnet to access CoreServicesVnet

     • Allow forwarded traffic

4. Verify both peerings show Connected.

• 

  

  Now the connection should succeed (TCP test succeeded: true).

Task 5: Test Connection Again

1. On ManufacturingVM, run:

    Test-NetConnection 10.20.20.4 -Port 3389
   

Clean Up Resources

1. In Cloud Shell (PowerShell), run:

    Remove-AzResourceGroup -Name 'ContosoResourceGroup' -Force -AsJob
   

   • Resources will delete asynchronously.

Extend Your Learning with Copilot

Try these prompts:

• What are the most common errors when configuring Azure virtual network peering?

  • Overlapping IP Ranges: VNets have overlapping address spaces — peering fails.

  • One-Way Peering Only: Peering is not set up in both directions.

  • “Allow Traffic” Not Enabled: Required traffic settings are missing during peering setup.

  • NSGs Blocking Traffic: Network Security Groups block communication even after peering.

  • Gateway Transit Misconfigured: Incorrect gateway settings when sharing VPN or ExpressRoute.

  • Missing Permissions Across Subscriptions: Insufficient rights to peer VNets in different subscriptions.

  • Global Peering Blocked by Policy: Policies prevent cross-region VNet peering.

• If I peer VNet1 with VNet2 and VNet2 with VNet3, is VNet1 automatically peered with VNet3?

  • No, VNet1 is not automatically peered with VNet3. Azure VNet peering is not transitive.

• Can firewalls and gateways affect Azure VNet peering?

  • Yes — firewalls and gateways can affect Azure VNet peering communication.

How firewalls affect peering:

• NSGs (Network Security Groups) or Azure Firewall can block traffic between peered VNets.

• Even if peering is correctly set up, if:

  • NSGs block inbound or outbound traffic, or

  • Azure Firewall doesn’t allow the route,

    ➤ VMs won’t be able to communicate.

How gateways affect peering:

• Peering doesn’t automatically share VPN or ExpressRoute gateways.

• To share a gateway:

  • In Hub VNet, enable “Allow gateway transit”.

  • In Spoke VNet, enable “Use remote gateway”.

• Missing either setting = gateway traffic fails.

Key Takeaways

• Azure VNet peering allows seamless communication between VNets.

• Global peering connects VNets across different Azure regions.

• Traffic between peered VNets uses Microsoft’s private backbone (not public internet).

• You can resize VNet address spaces without downtime when VNets are peered.

To build a secure and scalable hybrid network, start with VPNs. Site-to-Site VPNs, Point-to-Site VPNs, Azure Virtual WAN to connect and manage multiple sites or regions or Network Virtual Appliances (NVAs) for added security and routing control.

Azure VPN Gateway enables secure connections between your Azure environment and other locations. Before deploying a connection, you need a defined endpoint for the data—this is where the VPN Gateway setup begins.

We’ll briefly cover:

• Types of connections you can establish using the VPN Gateway

• Configuration options available for setup and deployment

• Gateway generations and SKUs to help you choose the best fit for your needs

Azure VPN Gateway: Connection Types & Setup Essentials

Site-to-Site (S2S) VPN

Connects an on-premises location to Azure. It can also link two Azure environments, though virtual network peering is more common now.

Point-to-Site (P2S) VPN

Allows individual devices—like laptops or phones—to securely connect to your Azure network using a VPN client or native Windows support.Perfect for remote work and on-the-go access.

Setup Requirements

Regardless of the connection type, you’ll need:

• A VPN Gateway in your Azure virtual network

• A public IP address for access

• Proper routing to allow traffic into your virtual network

Azure VPN Gateway: Planning, Provisioning & Connection Setup

Before deploying a VPN Gateway in Azure, planning is critical. Start by creating a dedicated gateway subnet in your virtual network. You’ll need a /27 or /28 CIDR block, depending on your scaling needs. Only Azure-managed gateways (VPN and ExpressRoute) should use this subnet.

When you create your gateway subnet, gateway VMs are deployed to the gateway subnet and configured with the required VPN gateway settings.

Important:

• One gateway per virtual network

• Never deploy non-gateway resources to the gateway subnet (e.g. no additional VMs)

Azure handles backend scaling automatically, ensuring your selected SKU meets bandwidth demands.

Gateway Deployment Essentials

To deploy a VPN gateway:

• Specify name, region, VPN type (Route-based or Policy-based), SKU, and generation

• Route-based (preferred) supports IKEv2 (آیک) and dynamic routing

• Policy-based supports only IKEv1 and is considered legacy

• Your choice of gateway SKU affects the number of connections and the aggregate throughput benchmark.

• Associate a virtual network that includes the gateway subnet.

• The gateway needs a public IP address.

Provisioning takes about 45 minutes, so plan accordingly.

Gateway SKU and Generation Comparison:

• Gen1: 650 Mbps–1.25 Gbps

• Gen2: Starts at 1.25 Gbps and scales higher

• You can resize within the same generation

The Basic SKU (not shown) is legacy and should not be used.

Site-to-Site VPN Setup

A Site-to-Site (S2S) VPN allows you to establish a secure connection over the public internet between Azure and another location—whether that’s an on-premises data center, a private network, or even another cloud provider. This setup ensures that data remains protected while traversing public infrastructure.

To set this up, there are several steps involved, each addressing a piece of the connection:

Typical Setup:

• On the Azure side, you’ll have a Virtual Network (VNet) with subnets and a VPN Gateway already provisioned.

• On the on-premises side, your network (with resources like VMs) includes a VPN-capable edge device.

The connection is made by creating and linking resources like the local network gateway, VPN gateway, and VPN connection object in Azure.

Steps:

1. Create a local network gateway on azure – A pointer resource in Azure that defines your on-prem location using a public IP or FQDN. Also specify the address space (e.g., 192.168.3.x) to configure proper routing.

2. Configure the VPN device on-prem – Use Microsoft’s prebuilt scripts for popular devices (Cisco, Ubiquiti, etc.). Generate and apply a shared key – Used for secure authentication.

3. Create a VPN connection – Link the Azure VPN Gateway with the local network gateway using the shared key.

   • Create the connection object after your VPN gateway is deployed and the on-prem device is configured.

   • Name the connection and set the type to Site-to-site (IPSec).

   • Select both the Azure VPN Gateway and the Local Network Gateway.

   • Enter the pre-shared key used by the on-premises VPN device.

4. always validate using Network Watcher, logs, and health probes to confirm connectivity and performance.

   • Validate VPN throughput to the VNet

   • Utilize Network Watcher for diagnostics

   • Use diagnostic logs to troubleshoot the Azure VPN Gateway

   • Check UDR and NSGs on the gateway subnet

   • Verify the on-premises VPN device is validated

   • Verify shared key and VPN peer IPs

   • Use Azure gateway health probe for status

   • Check if the on-prem VPN device supports perfect forward secrecy

So in summary:

• Create a virtual network with a GatewaySubnet.

• Provision a Virtual Network Gateway in that VNet.

• Create a Local Network Gateway with on-prem IP and address space.

• Configure the on-prem VPN device with matching settings.

• Create the Site-to-Site VPN connection using a shared key.

Point-to-Site VPN Setup

Point-to-site (P2S) VPNs allow user devices (laptops, phones) to connect to Azure securely.

Requirements:

• Azure VPN Gateway already provisioned

• Proper IP address pool for connected users

• Compatible VPN clients (OpenVPN, SSTP, IKEv2)

Authentication Options:

• Azure Entra ID (formerly Azure AD)

• On-prem Active Directory via RADIUS server

• Choose based on identity store and protocol type

Configure in the Azure portal under Point-to-site configuration. Plan IP pool size based on expected simultaneous users.

Point-to-Site Configuration in Azure:

To keep things smooth, no matter the authentication method or connection type, you need to go through the initial setup to ensure Point-to-Site works.

Head to your Virtual Network Gateway, scroll down, and click Point-to-site configuration. Here, configure key settings—especially the address pool for Point-to-Site connections. You’ll need a subnet with enough private IPs for each user connecting. Think about how many simultaneous users you’ll support—10, 100, 1,000, or more. Make sure there’s enough IP space to allow everyone to connect.

If you’re deploying resilient options like an active-active gateway, you’ll need additional IPs to support failover. Plan carefully—your address range and number of IPs per user will affect your setup. Once that’s done and authentication is configured, users can securely connect from anywhere.

In Address pool, enter the private IP range you want to assign to VPN clients. VPN clients will get IPs dynamically from this range. Use a /29 subnet for active/passive, /28 for active/active setups.

VPN Gateway Resiliency Options

To ensure high availability:

1. Deploy virtual gateway in Availability Zones format(if region supports it):

e.g. We have two gateway instances, deployed in separate availability zones. These zones are physically isolated—with different power, cooling, and data centers—to ensure high uptime. All traffic can go to one location, but in case of a failure or config issue, it will automatically fail over to the other instance.

This setup ensures high availability and is one of the simplest ways to boost uptime.

By default, gateways are in active-standby mode—only one connection is needed, and in case of failure, traffic shifts to the standby gateway. It’s easy to set up and works well for most cases.

2. Active-Active Configuration:

Improves uptime by allowing multiple active paths. Requires extra on-prem setup and dual connections.

However, if cutover downtime isn’t acceptable, or you need higher uptime, choose the active-active deployment. This setup requires:

• Multiple connections on your side

• Following Azure’s high availability architecture guidance

• Planning for different network topologies

With active-active, your VPN connection remains up even if one side or gateway goes down. You’ll have four possible paths, so if one fails, others stay available.

Azure Virtual WAN Overview

Azure Virtual WAN (vWAN) simplifies enterprise connectivity across regions, sites, and connection types.

Benefits:

• Centralized routing and policy management

• Supports Site-to-Site, Point-to-Site, and ExpressRoute

• Inter-region connectivity via linked hubs

Azure Virtual WAN Types & Capabilities

• Basic Virtual WAN / Hub

  • Supports: Site-to-site VPN only

• Standard Virtual WAN / Hub

  • Supports:

    • ExpressRoute

    • User VPN (Point-to-site)

    • VPN (Site-to-site)

    • Inter-hub and VNet-to-VNet transiting through the virtual hub

Hub Private Address Space – Key Points

• Minimum address space required to create a hub is /24.

• You don’t need to manually plan subnets for services in the virtual hub.(more flexible than vnet)

• Azure Virtual WAN is a managed service—it automatically creates the necessary subnets for each gateway or service.

• This includes services like:

  • VPN gateways

  • ExpressRoute gateways

  • User VPN (Point-to-site) gateways

  • Firewall, routing, etc.

Deployment Steps:

• Choose region, SKU (Basic or Standard), and private address space

• Standard SKU supports multi-region and all connection types

• Configure route tables for traffic flow between regions and branches

Cross-tenant routing: Azure Virtual WAN allows you to connect virtual networks from other Azure tenants into a shared Virtual WAN hub, enabling secure and centralized cross-tenant networking.

Whether you’re in a single-tenant or multi-tenant setup, it all comes down to one thing: routing—just like everything else in virtual networking.

Just like in virtual networks, Azure Virtual WAN uses route tables to control traffic flow and define the next hop. In vWAN, you propagate a route table at the hub, which then gets automatically associated and pushed out to connected resources—so everything around the hub knows what’s inside it.

The central hub can handle up to 50 Gbps of aggregate throughput, making it ideal for connecting multiple sites with high traffic demands.

By setting up route connections and defining paths in your routing tables, you control where traffic flows. Configuration is straightforward through the default route table, and for more advanced setups, click on the image below:

Deploying Network Virtual Appliances (NVAs) into a virtual hub:

NVAs are third-party appliances like firewalls or SD-WAN tools deployed in Virtual WAN hubs. (Click on the image below for more info)

Steps:

1. Choose from Azure Marketplace – Vendors like Fortinet and VMware offer pre-configured solutions.

2. Provision into Virtual WAN hub

3. Scale correctly – Select the appropriate scale unit for required bandwidth

4. Use vendor-provided tokens for secure setup (Sometimes, the vendor requires you to provide an authentication token to verify that you’re a registered user. This must be obtained directly from the vendor.)

These are fully managed deployments, not manual VMs, and scale with your network needs.

For complete instruction please visit microsoft learn github here we will do the following:

• Creating a web application on Azure by using the PaaS model.

• Uploading existing web app files by using the Apache Kudu zip deployment option.

• Viewing and testing the newly deployed web application.

Lab Scenario

1. Create a storage account of imgstor50403225 and go to the resource > Access keys > copy a Connection string to Notepad then

2. Go to the Storage Account > Containers > + Container > name it imagesupload blob

3. Create a web App (API) of imgapi50403225 with runtime of .net 8 LTS

4. Configure the web app to storage account using the connection string from notepad

5. Deploy the API with openning vs code and the folder downloaded from this location: https://github.com/MicrosoftLearning/AZ-204-DevelopingSolutionsforMicrosoftAzure/tree/master/Allfiles/Labs/01/Starter/API

6. Enter the following CLI command:

az login
az webapp list --resource-group ManagedPlatform-lod50403225 --query "[?starts_with(name, 'imgapi')].{Name:name}" --output tsv
cd C:\Allfiles\Labs\01\Starter\API
az webapp deployment source config-zip --resource-group ManagedPlatform-lod50403225 --src api.zip --name <your-api-name>

7. To create Front-End Web App Repeat Web App creation:

• Name: imgweb50403225

• Use existing plan: ManagedPlan

• Same stack/region/OS

• Disable Insights, then Review + create > Create.

8. To configure Front-End Go to app > Configuration > + New application setting:

• • Name: ApiUrl

    • Value: Your previously copied API URL (with https://)

    • Click Save.

9. To deploy Front-End, In VS Code > Open Folder: C:\Allfiles\Labs\01\Starter\Web.

10. In terminal:

az login
az webapp list --resource-group ManagedPlatform-lod50403225 --query "[?starts_with(name, 'imgweb')].{Name:name}" --output tsv
cd C:\Allfiles\Labs\01\Starter\Web
az webapp deployment source config-zip --resource-group ManagedPlatform-lod50403225 --src web.zip --name <your-web-name>

11. To test the App, Browse to your front-end app, You should see grilledcheese.jpg in the gallery. Upload banhmi.jpg using the UI. Refresh if needed.

    ---

Lab 26: Configure Privileged Identity Management for Microsoft Entra roles

Login type = Microsoft 365 admin

A Privileged role administrator can customize Privileged Identity Management (PIM) in their Microsoft Entra organization, including changing the experience for a user who is activating an eligible role assignment. You must become familiar with configuring PIM.

Lab 17 - Defender for Cloud Apps application discovery and enforcing restrictions

Microsoft Defender for Cloud Apps uses network traffic logs to identify which applications users are accessing. Logs from on-premises firewalls provide a snapshot of the most commonly used applications and the users interacting with them. Traffic from managed devices is also sent to the Defender for Cloud Apps Discovery Overview Dashboard, offering centralized visibility into app usage.

1. For defender for cloud apps discovery sign in to security.microsoft.com using global administrator account > Cloud Apps > Cloud App Catalog >and in brows by category select Cloud Storage> and in the list of apps note the Risk score next to the app name.

2. Open dropbox on another browser and you can open it

3. Return to the Defender for Cloud Apps screen, and select the three-dot to the right of Dropbox and choose Unsanctioned and then the Next button .

4. After 5 mins try to open dropbox and you can see you cannot open dropbox anymore

it only applys on any client device that is onboarded to Microsoft Defender for Endpoint (MDE) and integrated with Microsoft Defender for Cloud Apps.

Questions that remained unanswered for this lab

1. How to check if we have MDE licenses on azure (What are the options)

2. How to enable MDE licenses

18 - Defender for Cloud Apps Access and Session Policies

Login type = Microsoft 365 admin

Exercise 1 - Create and test the Conditional Access App Contol policy

1. First ask user to login to forms.microsoft.com, the user should have unconditional access to Forms then configure Entra ID to work with Defender for Cloud Apps

2. Navigate to Entra ID > Identity > Protection > Conditional Access > Create new policy > Enter policy name: “Monitor the user using Forms“ > select the user > add Microsoft Forms on target resources> under Access Control select Session and select use conditional access app control and leave the default of Monitor only selected and then enable the policy

   

3. Ask the user to login to forms.microsoft.com again, user will get a pop up message “Your company is monitoring the usage of this application.“

Exercise 2 - Setup alerts in Microsoft Defender for Cloud Apps

Task 1 - Access Microsoft Defender for Cloud Apps(security.microsoft.com) and create Conditional Access App Control

Registering your application creates a trust relationship with the Microsoft identity platform. This trust is one-way—your app trusts the Microsoft identity platform, but not vice versa.

Navigate to Microsoft Defender for Cloud Apps via https://security.microsoft.com using a Global Administrator account.

1. Go to Cloud Apps > Policies > Policy Management > + Create policy > Select Access policy. Enter policy name: “Monitor Microsoft Forms access” and Leave Category as Access control.

2. Under Activities matching all of the following, open the filter for Intune compliant, Microsoft Entra Hybrid joined, and unselect Microsoft Entra Hybrid joined. Also choose select apps > Choose Microsoft Forms. Leave Actions set to Test.

3. Under Alerts, leave Create an alert… checked and select Send alert as email. Enter the lab admin email address, then press Enter. Click Create to finalize the access policy.

4. Now if user logs in to the forms.microsoft.com again he will get this message

Your company is monitoring the usage of this application.

5. Return to the browser running Defender for Cloud Apps and refresh the page then navigate to Investigate > Activity log and use the App filter to select Microsoft Forms. Review the sign-in records of the user.

Lab 19 - Register an application

Login type = Microsoft 365 admin

Exercise 1 - Register an application

Task 1 - App registration:

1. Entra ID\> Identity > Applications > App registrations > + New registration.

Enter the application name: Demo app. Leave all other fields as default (Redirect URI not required).

Click Register.

Task 2 - Configure platform settings

Settings for each application type, including redirect URIs, are configured in Platform configurations in the Azure portal. Some platforms, like Web and Single-page applications, require you to manually specify a redirect URI. For other platforms, like mobile and desktop, you can select from redirect URIs generated for you when you configure their other settings.

2. Entra ID \> Identity > Application > App registrations \> Select your application > Manage > select Authentication > Platform configurations > + Add a platform > Select Web as the platform > In Redirect URI, enter: https://localhost > Click Configure to save the platform settings.

Task 3 - Add credentials, certificate and client secret

Credentials are used by confidential client applications that access a web API. Examples of confidential clients include web apps, other web APIs, and service-type and daemon-type applications. Credentials allow your application to authenticate as itself, requiring no interaction from a user at runtime.

You can add both certificates and client secrets (a string) as credentials to your confidential client app registration.

Note: Sometimes called a public key, certificates are the recommended credential type, because as they provide a higher level of assurance than a client secret. When using a trusted public certificate, you can add the certificate using the Certificates & secrets feature. Your certificate must be one of the following file types: .cer, .pem, .crt.

Note: The client secret, also known as an application password, is a string value your app can use in place of a certificate to identity itself. It's the easier of the two credential types to use. It's often used during development, but is considered less secure than a certificate. You should use certificates in your applications running in production.

3. Azure portal > App registrations > Select your application > Select Certificates & secrets > Click + New client secret. > Enter description: SC300 lab secret > Set duration: 90 days (3 months) > Click Add\> Save the secret's value in notepad for use in your client application code; The Certificate & Secrets page will display the new secret value. It's important you copy this value as it's only shown this one time; if you refresh your page and come back, it will only show as a masked value.

With your web App registered, you're ready to add the scopes that your API's code can use to provide granular permission to consumers of your API.

Task 5 - Add a scope

The code in a client application requests permission to perform operations defined by your web API by passing an access token along with its requests to the protected resource (the web API). Your web API then performs the requested operation only if the access token it receives contains the scopes (also known as application permissions) required for the operation.

First, follow these steps to create an example scope named Employees.Read.All:

5. Applications > App registrations > Select your API’s app registration.

   Select Expose an API > Click + Add a scope\> Set the Application ID URI to: api://DemoAppAPI > Click Save and continue > In Add a scope, fill in the scope details (use “Value” column info in the table below) > Set State to Enabled > Click Add scope.

Note - The App ID URI acts as the prefix for the scopes you'll reference in your API's code, and it must be globally unique. You can use the default value provided, which is in the form api://<application-client-id>, or specify a more readable URI like https://contoso.com/api.

(Optional) To suppress prompting for consent by users of your app to the scopes you've defined, you can pre-authorize the client application to access your web API. Pre-authorize only those client applications you trust since your users won't have the opportunity to decline consent.

Under Exposed an API > Authorized client applications \> click Add a client application\> Enter the Application (client) ID of the trusted client app (you can dind app id on overview tab) > Select the authorized scopes checkmark > Click Add application.

If you followed this optional step, the client app is now a pre-authorized client app (PCA), and users won't be prompted for their consent when signing into it.

Task 6 - Add a scope requiring admin consent

Next, add another example scope named Employees.Write.All that only admins can consent to. Scopes that require admin consent are typically used for providing access to higher-privileged operations, often by client applications that run as backend services or daemons that don't sign in a user interactively.

6. Follow the above steps to add a new scope named Employee.Write.All, enable it, and click Add scope to save.

As shown in the image, a scope's full string is the concatenation of your web API's Application ID URI and the scope's Scope name.

Note: For example, if your web API's application ID URI is https://contoso.com/api and the scope name is Employees.Read.All, the full scope is: https://contoso.com/api/Employees.Read.All

Note: Next, you will configure a client app's registration with access to your web API and the scopes you defined by following the steps above. Once a client app registration is granted permission to access your web API, the client can be issued an OAuth 2.0 access token by the Microsoft identity platform. When the client calls the web API, it presents an access token whose scope (scp) claim is set to the permissions you've specified in the client's app registration. You can expose additional scopes later as necessary. Consider that your web API can expose multiple scopes associated with several operations. Your resource can control access to the web API at runtime by evaluating the scope (scp) claim(s) in the OAuth 2.0 access token it receives.

Exercise 2 - Manage app registration with a custom role

Task 1 - Create a new custom role to grant access to manage app registrations

1. Entra ID > Identity > Roles and admins > + New custom role > Basics tab > enter the role name: My custom app role > Click Next > Permissions tab > search for credentials > Select Manage permissions from the results > Click Next twice > Review the settings and click Create.

microsoft.directory/servicePrincipals/managePasswordSingleSignOnCredentials - Manage password single sign-on credentials or service principals. microsoft.directory/servicePrincipals/synchronizationCredentials/manage - Manage application provisioning secrets and credentials.

Why pick those two - For application provisionsing these two items are the bare minimum permissions needed to enable and enforce single sign-on for the application or service principal being created; and be able to assign the enterise application to a set of users or groups. Other permissions could also be granted. You can get a full list of available permissions at https://docs.microsoft.com/azure/active-directory/roles/custom-enterprise-app-permissions.

Lab 20 - Implement access management for apps

Login type = Microsoft 365 admin

Your organization requires that only specific users or groups have access to enterprise applications. You must assign a user to a specific application.

Task 1 - Add an app to your Microsoft Entra tenant

1. Identity > Applications > Enterprise applications > + New application > Browse Microsoft Entra Gallery page > search for GitHub > Select GitHub Enterprise Cloud – Enterprise Account from the results > Review the settings and click Create.

   (Once created, you’ll be redirected to the GitHub Enterprise Cloud – Enterprise Account page.)

Task 2 - Assign users to an app

2. On the GitHub Enterprise Cloud – Enterprise Account page, go to Overview > Getting Started > 1. Assign users and groups( Or, go to Manage > Users and groups in the left menu.) > Click + Add user/group.

   In the Add Assignment page, click None selected under Users and groups.

   Select Adele Vance and your MOD administrator account > Click Select >Select Assign

Azure Roles (RBAC)

Azure uses Role-Based Access Control (RBAC) to manage access to Azure resources. These roles determine what actions users can take on Azure services.

Common Built-in Azure Roles:

Custom Roles

You can also create custom roles tailored to specific needs using JSON to define:

• Allowed actions

• Denied actions

• Assignable scopes

Microsoft Entra Roles (Azure AD Roles)

Microsoft Entra (formerly Azure Active Directory) uses its own set of roles to manage identity-related tasks such as users, groups, security policies, and authentication settings.

Common Entra (Azure AD) Roles:

🔐 Privileged Identity Management (PIM) Integration

Many of these roles can be made eligible through PIM, so they are only activated when needed, reducing security risks.

These roles are part of Microsoft Entra ID, which is the identity and access management service in Azure and are assigned at the directory/tenant level and are separate from Azure RBAC roles and are used to manage identity-related tasks, like users, groups, enterprise apps, security settings, and more.

Microsoft 365 Roles

Microsoft 365 has its own set of roles designed to manage specific M365 services like Exchange Online, SharePoint, and Teams.

Core Microsoft 365 Admin Roles

Product-Specific Admin Roles

Security & Compliance Roles

Support & Reporting Roles

🧠 Notes:

• These roles are Entra ID (Azure AD) roles but are especially used for Microsoft 365 service management.

• They can be assigned in both the Microsoft 365 admin center and the Entra admin center.

These roles are focused on M365 apps and services, and are often used alongside Entra roles.

Summary: Role Systems at a Glance

Does a Global Administrator Have Access to Azure Resources?

✅ Yes — to Microsoft Entra (formerly Azure AD) and Microsoft 365

• Full control over:

  • User and group management

  • Role assignments

  • Security configurations (e.g., MFA, Conditional Access)

  • Microsoft 365 tenant settings (e.g., organization-wide policies, service configurations)

• ❌ No — not automatically to Azure subscriptions or resources

• Global Administrators do not have access to Azure resources like virtual machines, storage accounts, or databases

• To manage these, they must be explicitly assigned an Azure RBAC role (e.g., Owner, Contributor, Reader)

How Can a Global Administrator Gain Access to Azure Resources?

To manage Azure resources, the Global Administrator must:

• Be assigned an Azure RBAC role such as Owner, Contributor, or Reader at the subscription, resource group, or resource level

• Use Privileged Identity Management (PIM) to elevate their access (if available)

Using Privileged Identity Management (PIM)

If your organization uses Microsoft Entra PIM, a Global Administrator can activate temporary access to Azure resources by:

1. Going to the Microsoft Entra Admin Center

2. Navigating to Roles and Administrators

3. Selecting Global Administrator

4. Activating a role like Subscription Owner or Contributor via PIM

This is useful for just-in-time privileged access without assigning permanent roles.

Summary

When you launch Azure Cloud Shell, it needs a place to:

1. Persist your files

• Any scripts, profile customizations, or downloaded files are stored in your Cloud Shell home directory.

• This directory is stored in Azure Files, which requires a Storage Account.

2. Maintain your environment across sessions

• Without storage, everything would reset every time you open Cloud Shell.

• The storage account ensures your files and shell environment persist.

3. Enable features like:

• Running long scripts

• Saving logs

• Mounting file shares

• Using tools like git, vim, etc.

🧠 TL;DR: (Too Long; Didn’t Read)

The storage account is used to store your Cloud Shell files and environment, so your work isn’t lost between sessions.

Lab 06: Add a federated identity provider

Lab scenario

Your company works with many vendors and, on occasion, you need to add some vendor accounts to your directory as a guest and allow them to use their Google account to sign-in.

Exercise 1 - Configure identity providers

Task 1 - Configure Google to be used as an identity provider

1. Go to the Google APIs at https://console.developers.google.com, and sign in with your Google account. We recommend that you use a shared team Google account.

2- Click on select a project and then create a new project

3. Select the project and on the left menu select OAuth consent screen

4. Click “Get Started”, select the app name Entra ID, and sign in with your Gmail account.

5. For the Audience, choose External.

6. Contact information:

7. I agree to.. :

8. Click continue and create:

9. Click on create OAuth client and for application type select web application, name: Entra B2B, under authorized redirect URIs select the following URIs:

https://login.microsoftonline.com

https://login.microsoftonline.com/te/**tenant ID**/oauth2/authresp

(where <tenant ID> is your tenant ID)

• To find your tenant id and tenant (directory)name:

• Entra>“Identity” > “Overview” (under Tenant).

• Azure >the top-right corner> account name > “Switch directory” (if needed)>Click on your directory> Under Overview

https://login.microsoftonline.com/te/**tenant name**.onmicrosoft.com/oauth2/authresp

(where <tenant name> is your tenant name)

10. Select Create. Copy your client ID and client secret. You'll use them when you add the identity provider in the Azure portal. You can leave your project at a publishing status of Testing

Task 2 - Add a test user

1. On https:// console.cloud.google.com go to APIs & Services > OAuth consent screen, then select Audience and add users under test ussers:

2. Enter your gmail and click on save

Exercise 2 - Configure Azure to work with an External identity provider

Task 1 - Configure Microsoft Entra ID for Google federation

1. Select Microsoft Entra ID > Identity > External Identities > All identity providers > Google > Configure

   (Microsoft provides a direct federation for Google as an identity provider)

2. Enter the client ID and Client secret that we optained (or you can find it in console.cloud.google.com > > API and Services > credentials )

Task 2 - Invite you Test User account

1. If you used an existing Gmail account, remember to delete the account with External Identities | All identity providers. You can also return to the Google developer console and delete the project that you created.

2. Entra > All users > Invite External user and enter your test gmail information

Task 3 - Accept the invitation and login

1. check your email and accept the invite and follow the prompts untill you gets to myapplications.microsoft.com

Task 4 - Login to Microsoft 365 using your Google account

1. Login to login.microsoft.com using your gmail account(choose sigin in option and then choose sign in to an organization)

2. enter yout lab tenant domain name

3. and then it takes you to google login page:

Lab 07: Add Hybrid Identity with Microsoft Entra Connect (Optional)

Lab 08: Enable multi-factor authentication

Login type = Microsoft 365 admin

A Microsoft Entra ID Premium license is required for this exercise.

1. Login to entra and search for multifactor authentication (or just go to identity> protection> risky activity > multifactor authentication)

2. Under configure click on additional cloud-based multifactor authentication settings

3. You can enable/ disable or enforce MFA from here:

4. In service settings : You can also enable or disable app passwords here, which allow users to create unique account passwords for apps that don't support multi-factor authentication. This feature lets the user authenticate with their Microsoft Entra identity using a different password specific to that app.

Task 2 - Setup conditional access rules for MFA for Delia Dennis

1. Go to Entra > Identity> Protection > Conditional Access and for the policy name: MFA_for_username and then select the user:

2. For target resource select office 365 (previously we gave her o365 license)

3. For network select no for configure

4. Also any network or location configured for condition:

5. Under grant do these settings and enable the policy and click on create:

Task 3 - Test Delia's login

1. login on www.office.com using Delia’s credential. You can see you need to have MFA.

Exercise 2 - Configure MFA to be required for login

Task 1 - Configure Microsoft Entra Per-User MFA

1. click on per user MFA

2. select the user and enable the MFA for the user and then try to login with the user:

3. When you want to login you will be asked to use microsoft authenticator:

Lab 09 - Configure and deploy self-service password reset

1. Create a security group of 3 users:

2. Enable SSPR for your test group (add the group on entra>protection>password reset>properties):

3. 

   Under *Manage, select and review the default values for each of the Authentication methods, Registration, Notifications, and Customization settings.

3. Register a user in our test group for SSPR ( just login with the user on https://login.microsoftonline.com/ ) and you will get this prompt:

4. To test SSPR Use one of the users in your test group and in login screen of http://portal.azure.com click on forgot my password :

5. Use a user account that you previously configured with Multi-Factor Authentication (MFA) during Step 3 when signing in and click on forgot my password.

6. If you attempt to log in with a user who is not part of the SSPRTesters group and click ‘Forgot my password,’ you’ll see the following prompt:

Lab 10 - Microsoft Entra Authentication for Windows and Linux Virtual Machines

Login type = Azure Resource login

1. Create a vm and on the management tab select login with Microsoft Entra ID (On the Management tab, check the box to Login with Microsoft Entra ID under the Microsoft Entra ID section.)

   You will notice that the System-assigned managed identity in the Identity section is automatically selected and grayed out. This behavior occurs by default when ‘Login with Microsoft Entra ID’ is enabled.

2. Assign a job function role of “virtual machine administrator login” to a user

3. Start an RDP session with the user to the virtual machine. Then, go to the Remote settings and uncheck “Allow connections only from computers running Remote Desktop with Network Level Authentication”.

4. Modify your RDP file to support the Microsoft Entra ID login: Select the Connect menu item. On the RDP tab select the Download RDP File.

5. Make a copy of the RDP file and add -EntraID to the end of the filename.

6. Edit the new version of the RDP file you just copied using Notepad. Add the these two lines of text to the bottom of the of the file:

enablecredsspsupport:i:0

authentication level:i:2

7. Save the RDP file. You should now have two versions of the file:

   • <>.RDP

   • <>-EntraID.RDP

8. Run the rdp-entraid and login with entra id user with vm admin login access(try with any other user and you cannot login)

Governance and Compliance

Assign built-in roles and verify permissions

# Define the variables
$userPrincipalName = "dev-test@example.com"
$resourceGroupName = "test-rg"
$roles = @(
    "Storage Account Contributor"
    "Virtual Machine Contributor"
    "Network Contributor"
)

# Loop through the roles and assign them to the user
foreach ($roleName in $roles) {
    New-AzRoleAssignment -RoleDefinitionName $roleName -SignInName $userPrincipalName -ResourceGroupName $resourceGroupName
}

• Use role-based access control (RBAC) to allow the dev-test@example.com developer account to manage certain resources in the test-rg resource group by adding the following role assignments: Storage Account Contributor, Virtual Machine Contributor, Network Contributor.

Create a virtual machine as a developer

• Identify the operations associated with virtual machines by using the Get-AzProviderOperation cmdlet.

Note the operations for read, start, and deallocate.

You can use the operations associated with an Azure resource as actions when you create an Azure role-based access control (RBAC) custom role.

Want to learn more? Review the documentation on the Get-AzProviderOperation cmdlet.

# Get all operations for virtual machines (using a wildcard)
$vmOperations = Get-AzProviderOperation "Microsoft.Compute/virtualMachines/*"

# Identify read, start, and deallocate operations
$readOperation = $vmOperations | Where-Object { $_.Operation -match "read" }
$startOperation = $vmOperations | Where-Object { $_.Operation -match "start/action" }
$deallocateOperation = $vmOperations | Where-Object { $_.Operation -match "deallocate/action" }

# Output the relevant operations
Write-Host "Read Operation:"
$readOperation | Format-Table Operation, Description # Corrected line

Write-Host "Start Operation:"
$startOperation | Format-Table Operation, Description # Corrected line

Write-Host "Deallocate Operation:"
$deallocateOperation | Format-Table Operation, Description # Corrected line

• Retrieve the role definition for the Virtual Machine Contributor role and then output it to $home\clouddrive\VMOperatorRole.json by using the Get-AzRoleDefinition and the ConvertTo-Json cmdlets.

You can use Azure role-based access control (RBAC) role assignments to grant access to resources at a specific scope—subscription, resource group, resource—by assigning a role to a user, group, service principal, or managed identity. There are two types of roles that you can use: built-in and custom. You can create a custom role by using the Azure portal, Azure PowerShell®, Azure command-line interface (CLI) 2.0, and the REST API.

Want to learn more? Review the following documentation:

• Get-AzRoleDefinition

• ConvertTo-Json

• Custom roles

# Get the role definition for the Virtual Machine Contributor role
$roleDefinition = Get-AzRoleDefinition -Name "Virtual Machine Contributor"

# Convert the role definition to JSON format
$jsonRoleDefinition = $roleDefinition | ConvertTo-Json

# Output the JSON to the specified file
$jsonRoleDefinition | Out-File -FilePath $home\clouddrive\VMOperatorRole.json

• Open the VMOperatorRole.json file in the Azure Cloud Shell code editor by using the code command in the $home\clouddrive folder.

If prompted, switch to Cloud Shell classic mode, and then run the commands again.

You can edit the definition of a built-in role by using the Azure Cloud Shell code editor, and then you can save the definition as a new custom role.

Want to learn more? Review the documentation on Azure Cloud Shell code editor.

or

code ~/clouddrive/VMOperatorRole.jsoncode ~/clouddrive/VMOperatorRole.json

You can create a new custom role in Azure using the New-AzRoleDefinition cmdlet and your VMOperatorRole.json file. Run the following command in Azure PowerShell:

New-AzRoleDefinition -InputFile "home\clouddrive\VMOperatorRole.json"

Configure a Network Security Group in a Virtual Network

In this, you will configure a network security to allow secure (SSH) connections to a virtual machine. First, will create application security group, followed by creation of a network security. Next you will associate the security group with a subnet in the virtual network, and then you associate the application security group with the network interface on the virtual.

Finally, you will add an inbound security rule, and then you will verify that you can connect to the linux virtual machine in the subnet by using SSH.

Connect to the virtual machine at azureadmin@74.235.217.96 by using an SSH connection

first try before creating the rule was time out and second one after adding the rule to the nsg:

Configure Route Tables in a Virtual Network

Configure Front End:

• Create a Route table named app-frontend-rt by using the RG1lod49100900(909 here) resource group and the East US region, and then disable gateway route propagation.

• 

• Add a route named to-backend to the app-frontend-rt route table, and then configure the route by using an address prefix of 10.1.1.0/24 and a Virtual appliance next hop address of 10.1.255.4.

• 

• Associate the app-frontend-rt route table to the frontend subnet in the app-vnet virtual network.

You can associate a route to a subnet by using the Azure portal, the Set-AzVirtualNetworkSubnetConfig and Set-AzVirtualNetwork cmdlets, or the az network route-table route command.

Configure back-end:

• Create a Route table named app-backend-rt that uses the RG1lod49100900 resource group and the East US region, and then disable gateway route propagation. (process same as above)

• Add a route named “to-frontend” to the app-backend-rt route table, and then configure the route by using an address prefix of 10.1.0.0/24 and a Virtual appliance next hop address of 10.1.255.4.

• Associate the app-backend-rt route table to the backend subnet in the app-vnet virtual network.

• Open an Azure Cloud Shell Bash session without mounting a storage account.

• Create a secure shell (SSH) connection to VM3(Linux Machine) by using azureuser@20.172.210.22, and then when prompted, enter AzurePwd49100909 as the password.

• Enable IP forwarding by using the sudo user and the sysctl command, and then exit the SSH connection.

• In Cloud Shell, create an ssh connection to VM2 by using azureuser@4.236.142.95, and then when prompted, enter AzurePwd49100909 as the password.

• In the SSH session, update the virtual machine by using sudo and apt-get.

Ensure that you have updated the Linux virtual machine before moving on to the next task.

• Install the traceroute tool by using sudo and apt.

• Verify that traffic sent to VM1 is routed through the virtual appliance VM3 by using the traceroute tool, and then exit the SSH connection.

Configure Global Virtual Network Peering

In this challenge, you will configure a virtual network peering between the virtual networks for two applications hosted in different Azure regions.

First, you will review existing Azure resources, and then you will verify that you are unable to add virtual network peerings between the existing virtual networks.

Next, you will remove overlapping address spaces in the virtual network configuration. Finally, you will configure global virtual network peering between the two virtual networks.

VM1 Public IP: 172.206.208.169

vNet1 address space: 10.1.0.0/16

vNet2 address space: 10.1.0.0/16

The address spaces of virtual networks that you intend to connect should not overlap. You will correct this in an upcoming task.

• Attempt to add a virtual network peering named VNET1-to-VNET2 to the VNET2 virtual network.

  • A successful virtual network peering would allow traffic to flow in both directions between the VNET1 and VNET2 virtual networks.

  • You can use a virtual network peering to connect virtual networks together. For connectivity purposes, Azure will view the connected networks as if they are one network, and traffic will be routed between the peered virtual networks across the Microsoft backbone rather than through a gateway. For this reason, traffic between peered virtual networks will never traverse the public internet.

  • You can choose between two types of peering:

    • Virtual network peering connects virtual networks in the same region.

    • Global virtual network peering connects virtual networks in different regions.

You can use user-defined routes to implement service chaining by configuring a virtual machine in the peered virtual network as the next hop IP address.

You can also configure a gateway in a peered virtual network as a transit point to an on-premises network. This is referred to as gateway transit.

• 

  Add an address space of 10.2.0.0/16 to VNET2.

• Add a subnet named subnet2 to VNET2 by using a subnet address range of 10.2.0.0/24 .

When you design the address ranges of your subnets, remember that the first three IP addresses in each subnet are reserved by Azure for internal use.

• Associate VM2-nic to subnet2 in VNET2.

• Delete subnet1 in VNET2.

• Delete the 10.1.0.0/16 address space in VNET2.

• Add a virtual network peering to VNET2 that uses a remote virtual network connection named VNET1-to-VNET2 and a local virtual network connection named VNET2-to-VNET1, and that is configured to Allow 'VNET1' to receive forwarded traffic from 'VNET2' in remote settings and Allow 'VNET2' to receive forwarded traffic from 'VNET1' in local settings.

• Verify that the peering status of VNET1-to-VNET2 is Connected.

  

  • Verify that VNET1 and VNET2 are connected by using the ping command to 10.2.0.4.

Enable High Availability by Using Availability Sets

In this Challenge Lab, you will configure high availability by using availability sets. First, you will create an availability set and a virtual network. Next, you will deploy two Azure virtual machines to the availability set. Finally, you will configure load balancing.

1. Creating an Availability Set

• Availability sets help distribute virtual machines (VMs) across multiple fault domains (for power and hardware failure protection) and update domains (to stagger reboots during maintenance).

• You first create an Availability Set in Azure.

2. Creting a Virtual Network

• A virtual network (VNet) named “AVSet-Vnet” is created.

• This allows communication between the virtual machines deployed within it.

3. Deploying Two Virtual Machines

• Two Azure Virtual Machines (VMs) are created and assigned to the Availability Set.

• Each VM is placed in a different fault and update domain to ensure redundancy:

• Fault Domains: Protect against hardware failures (e.g., racks in different power circuits).

• Update Domains: Ensure that updates and reboots happen in phases without taking down all VMs at once.

After you deploy the virtual machines, each one should be in a separate fault and update domain for high availability.

4. Creating an Azure Load Balancer

• An Azure Load Balancer is deployed to distribute traffic evenly across the VMs.

• This ensures no single VM handles all requests, improving performance and availability.

5. Adding a Health Probe

• A Health Probe is configured to check the health of VMs.

• The probe ensures that only healthy VMs receive traffic, rerouting requests away from failed or unhealthy instances.

6. Adding a Load Balancing Rule

• A Load Balancing Rule is created to define how traffic is distributed across the VMs.

• It typically specifies:

  • Frontend IP

  • Backend pool (VMs in the availability set)

  • Port rules (e.g., HTTP on port 80)

  • Health probe association

You have successfully completed the following tasks:

• Created an availability set to ensure high availability.

• Deployed two Azure virtual machines within the availability set.

• Integrated an Azure load balancer with the availability set.

• Configured a health probe for the load balancer.

• Defined a load balancing rule to manage traffic distribution.

Outcome

By following these steps, you achieve:

• Improved high availability: No single failure (hardware, update, or maintenance) brings down the service.

• Load distribution: Requests are balanced across multiple VMs.

• Automated failover: If one VM fails, traffic is rerouted automatically.

Configure Blob Storage with Public Access

In this challenge, you will create an Azure storage account with a public container, upload files to the account, and test public access to the account.

1. Create a storage account by using standard performance, locally redundent storage and on advanced page allow enabling anounymous access on individual containers.

2. 

   Add a blob container named public on the storage account and set the public access level to Blob (in data storage select containers and add it there)

3. 

   you can find the access key in security and networking

4. Upload any image file (for example, .JPG, .PNG, or .GIF) on your computer to the public container, in the sa49292475 storage account, as a 64 KiB block blob by using the Hot access tier.

5. 

   Add a Blob index tag on the uploaded blob file by using the Key/Value pair of source / Portal. Click on the file and on the blob page , scroll down to Blob index tag

6. 

   In the same page you can see the URL property of the blob file here:

7. Upload another jpg with 64KiB block blob using Cool access tier and add a Blob index tag on the uploaded blob file by using the Key/Value pair of source / Archive

Note that the list of blob files is sorted by file name alphabetically not by creation time.

8. Open the Web App home page from the wa49292475 app service blade in the portal, and then select the Test Blob Containers link to open the File Test page.

   • On the Azure portal home page, select All resources, and then select the wa49292475 App Service.

   • On the wa49292475 Overview page, in default domain, select the wa49292475.azurewebsites.net link to open the home page.

9. On the home page, select the Test Blob Containers link to open the File Test page.

   

10. The File Test page should be displayed.

11. put the storage account name and key and click on test then the File Test page should be displayed after the test.

    

The Test Status should be set to 1 to show success.

You have provided the storage account name and the access key to the web app so it has full access to the storage account and is able to list the blob files in the container.

• On the File Test page, open the blob files by using the links provided. You should see your image files open in the browser.

When you open the blob files by using the links provided, you are then accessing the files by using anonymous read operations outside of the application. This shows the blob public access level in action.

Configure Blob Storage with Private Access

In this Challenge Lab, you will configure storage for various binary large object (blob) files used by a web app. First, you will create a storage account that has a private blob container, and then you will upload blob files to the container. Next, you will generate a shared access signature (SAS), and then you will configure application settings in a web app. Finally, you will test the configuration using a test page provided with the web app.

1. Create a storage account with standard performance and LRS redundency setting

2. add a blob container with private access level

Public access level set to Private (the default) means that blobs within the container cannot be read by anonymous request. Permissions must be granted either through a Shared Access Signature (SAS) key or through Role-Based Access Control (RBAC).

3. Upload an image with 64 KiB block and Hot access tier with blob index of source/private files

Bob index tags can be set when a file is uploaded or afterward. A tag consists of a simple key value pair, and it can be retrieved by applications, by using Azure Cloud Shell, or by using command line (CLI) tools.

4. Upload a second image with 256 KiB block and Cool access tier with blob index of source/private files

5. 

   go to web app and add these settings on environment variable, storage name and key:

6. 

   Add the key:

   

7. Open the Web App home page from the wa49297340 blade in the portal, ensure that the Status is Running, and then select the Test Blob Containers link to open the File Test page.

8. Since its not public wee should get an error message:

9. 

10. On the File Test page, locate the message: These are the files in the private container with a SAS. These links should return files.

11. Open the blob files by using the links provided—you should see your image files open in the browser.

Can You Provision Public and Private Blob Storage for a Web App?

In this Challenge Lab, you will configure storage for various files used by a web app. First, you will create a storage account that has public and private blob containers, and then you will upload files to both containers. Next, you will generate a shared access signature for the private container, and then you will configure application settings in a web app. Finally, you will test the configuration using a test page provided by the web app.

1. Create a storage account with standard performance and LRS setting and enable the anonymous access on advanced tab.

2. Add a blob container with public access set to blob

3. Add another one with public access set to private:

4. Keep record of key1 of storage account access key

5. Upload an image to public container as a 256 KiB block blob using Hot access tier (Key index source /Portal)

6. Upload the second image to private container as a 256 KiB block blob using Cool access tier

7. Generate a SAS token for the private container that allows read access for 8 hours and keep the token value

   

8. Add these three applicaion settings to the web app

9. on the web app file test page select test: (test status should be set to 3 to show success)The first and third links should return files. The second link should fail.

Create Linux VM in an Availability Set

In this challenge, you will enhance the redundancy of a front-end server tier to ensure continuous application availability during update reboots and potential failures of power sources or network switches. You will begin by creating an availability set, followed by generating an SSH key pair. Finally, you will deploy two Linux virtual machines within the availability set to maintain resilience and uptime.Create a managed availability set named app-frontend-avset in the rg1lod49333628 resource group by using 2 fault domains and 5 update domains.

1. Create a managed availability set named app-frontend-avset in the rg1lod49347139 resource group by using 2 fault domains and 5 update domains (Use managed disk)

2. Create an SSH key pair that uses the rsa algorithm, a key size of 4096 bits, the default file path, and no passphrase by using the ssh-keygen command

You can create an SSH key pair by using the ssh-keygen command, and then you can use the key pair when you create a Linux virtual machine in Azure.

3. Run the following command to display the generated RSA public key:

4. Create an Azure virtual machine by using the values in the following table.

5. Create a second Azure virtual machine by using the values in the following table. For any property that is not specified, use the default value.

6. Verify that app-frontend-vm1 and app-frontend-vm2 are in the app-frontend-avset availability set.

Configure a Virtual Machine Scale Set

In this challenge, you will configure an Azure virtual machine scale set. First, you will create a scale set that uses load balancing and a common Linux operating system disk image. Next, you will increase the number of virtual machines in the scale set. Finally, you will stop and deallocate a virtual machine instance.

1. Create a Virtual Machine Scale Set (VMSS) with the following specifications. Use default values for any unspecified properties.

   Configuration Details

   • Resource Group: rg1lod49347709

   • VMSS Name: webappscaleset

   • Orchestration Mode: Uniform

   • Image: Ubuntu Server (latest version, x64 Gen2)

   • VM Size: DS1_v2

   • Authentication Type: Password

   • Username: azureuser

   • Password: ******

   • Public IP Address: Enabled (NIC Properties)

   • Load Balancing Options: Azure Load Balancer

   • Load Balancer Selection: Create a new load balancer

   • Load Balancer Name: webappscaleset-lb

2. Verify that there are two virtual machine instances running in the webappscaleset scale set.

3. Increase the number of virtual machine instances to 3 in the webappscaleset scale set that is in the rg1lod49347709 resource group by using the az vmss scale command.

az vmss scale --resource-group rg1lod49347709 --name webappscaleset --new-capacity 3

4. Deallocate the webappscaleset_0 virtual machine instance in the webappscaleset scale set(select the webappscaleset_0 check box, and then on the command bar, select Stop).

Work with Managed Disk Snapshots

In this challenge, you will create a new test virtual machine that is based on an existing managed disk. First, you will prepare to create a snapshot, and then you will create a snapshot of an existing managed disk. Next, you will create a managed disk from the snapshot. Finally, you will create a virtual machine from the new managed disk.

1. Use the ip of the vm and open the auto-scale web app:

   

2. Stop and deallocate the vm

3. Create a snapshop from the vm disk that you can find in the resource group

4. Start the vm again

5. Create a managed disk in the resource group by using snapshot

6. Create a vm that uses new disk created from snapshot (allow inbound http, and ssh and disable boot diagnostics)

7. Restart vm2 to reload the web app

8. Open the web app on vm2, verify that you get the same web

Can You Design and Implement a Storage Solution on an Azure Virtual Machine?

In this Challenge Lab, you will deploy an Azure virtual machine and configure storage. First, you will create a virtual machine. Next, you will add a data disk to the virtual machine. Finally, you will resize the data disk, and then you will create a snapshot.

1. Create a vm with boot diagnostics enabled(with custom storage account)

2. create a new disk and attach it to the vm

3. remote to the vm and initialize the disk and create a folder in the disk

4. minimize the remote desktop and create the snapshot of the disk

5. Enable guest-level monitoring for VM1 by using the storage account.

6. Display the tables created for guest-level monitoring in the corpdatalod49350227diag storage account.

7. Create a chart that displays the \LogicalDisk(_Total)\Disk Bytes/sec Guest (classic) metric for VM1 and a time range of the last 30 minutes.

Can You Provision a Serverless Container-Based Environment?

In this challenge, you will provision a container-based environment. The environment will include a container registry, a container instance, and a container-based web app.

1. Provision an Azure Container Registry named acr49377787 in the Archlod49377787 resource group by using the Basic Pricing plan.

2. Enable admin user for the registry and record the password.

   

3. Configure an Azure Cloud Shell Bash session by using the existing Archlod49377787 resource group, the existing sa49377787 storage account, and a new file share named bash.

4. Establish an ssh connection to the Docker host VM by using ssh, student@dhpip49380771.eastus.cloudapp.azure.com++ as the username, and ******* as the password.

5. Authenticate by using the Container Registry from the Docker host: docker login acr49380771.azurecr.io using acr49380771 as the username and **** as the password.

6. Migrate the notlods/exampleservice:1.0 image from Docker Hub to your Container Registry by using the docker pull, docker tag, and docker push commands.

Pull the image from docker hub:

Tag the image for your azure container registry (ACR):

based on previous info our ACR is: acr49380771.azurecr.io

login to the azure container:(authenticate with ACR before pushing the image)

push the image to ACR:

Configure a Near Real-Time Metric Alert

In this challenge, you will configure a near real-time metric alert. First, you will create a Linux virtual machine. Next, you will create an action group, and then you will create a near real-time metric alert that uses the action group. Finally, you will test the alert.

1. Open an Azure Cloud Shell Bash session without mounting a storage account.

2. Create a new Linux virtual machine that generates an SSH key pair by using the az vm create command and the values in the following table:

   | Property | Value | | --- | --- | | Resource group | rg1lod49443856 | | Name | VM1 | | Image | Ubuntu2204 | | Size | Standard_DS1_v2 | | Admin Username | azureuser |

az vm create -g rg1lod49443856 --generate-ssh-keys --name VM1 --image Ubuntu2204 --size Standard_DS1_v2 --admin-username azureuser

3. Kep record the public IP address of VM1

4. Create an SSH connection to the virtual machine by using azureuser@20.39.47.37

    ssh azureuser@20.39.47.37
   

5. Update the Linux virtual machine by using the sudo command and the apt-get tool with the update option.

3. Create an action group by using the values in the following table. For any property that is not specified, use the default value.

You can create an action group before or during the creation of an alert rule by using the Azure portal, the Set-AzActionGroup cmdlet , or the az monitor action-group create Azure CLI 2.0 command.

You can use action groups to configure preferences for actions that you want Azure to take when a specific monitored event occurs.

4. Verify that your personal email has been added to the Cloud Operations action group(Check your email)

5. Create an alert rule named Percentage CPU greater than 85 for VM1 that will send a notification that has a description of Alert when the average Percentage CPU is greater than 85 to the Cloud Operations alert group.

You can create a metric alert rule by using the Azure portal, the Add-AzMetricAlertRuleV2 cmdlet, or the az monitor alert create CLI 2.0 command.

6. Establish an SSH connection to VM1 by using Cloud Shell and the apt-get command to install the stress tool.

7. Use the stress tool to generate a CPU load of 8 hogs on the virtual machine for a period of 480 seconds:

8. Leave the Cloud Shell window open to ensure that the generated CPU load triggers a notification alert. It may take up to 10 minutes for the alert to become active.

You have accomplished the following:

• Created a Linux virtual machine.

• Created an action group.

• Created a near real-time metric alert on a virtual machine.

• Tested the near real-time metric alert.

• Broad Scope: These roles grant extensive permissions across a wide range of Azure resources and services. They often have the ability to manage core aspects of your Azure environment, including users, subscriptions, and resource groups.

• High Impact: Actions taken by privileged administrators can have significant consequences for your organization's security and operations. They can potentially impact the availability, integrity, and confidentiality of your data and systems.

• Examples: Global Administrator, Security Administrator, User Access Administrator, Privileged Role Administrator

• Key Characteristics:

  • Elevated permissions

  • Wider access to resources

  • Greater potential for impact (positive or negative)

Job Function Roles:

• Specific Scope: These roles are designed to provide permissions necessary for performing specific tasks or functions within Azure. They have a narrower scope of access, limited to the resources and services relevant to the job role.

• Controlled Impact: The impact of actions taken by users with job function roles is typically limited to the specific area they are responsible for.

• Examples: Virtual Machine Contributor, Storage Account Contributor, Network Contributor, Website Contributor

• Key Characteristics:

  • Granular permissions

  • Focused access to specific resources

  • Limited potential for broader impact

Why the Distinction Matters:

• Security: Separating privileged administrator roles from job function roles helps to enforce the principle of least privilege. This means granting users only the permissions they need to perform their jobs, reducing the risk of accidental or malicious misuse of privileges.

• Operational Efficiency: Assigning job function roles allows users to efficiently manage the resources they are responsible for without needing excessive permissions that could potentially affect other parts of the environment.

• Compliance: Many regulatory frameworks and compliance standards require organizations to implement strong access controls and segregation of duties. Using a combination of privileged administrator roles and job function roles helps to meet these requirements.

In Summary:

Privileged administrator roles are like the "superusers" of your Azure environment, while job function roles are tailored to specific responsibilities. By carefully assigning these roles, you can maintain a secure, efficient, and compliant Azure environment.

This lab provides hands-on experience with Azure Monitor, a powerful platform for collecting, analyzing, and acting on telemetry from your Azure and on-premises environments. You'll learn to create alerts, configure notifications, and explore Log Analytics to gain insights into your resources.

Definitions

• Azure Monitor: A comprehensive service in Azure that provides a single platform for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments. It helps you understand how your applications are performing and proactively identify  ¹  issues affecting them and the resources they depend  ²  on. 1. learn.microsoft.com learn.microsoft.com2. github.com github.com

• Alert Rules: Defined conditions that monitor your Azure resources and trigger notifications when those conditions are met. For example, you might create an alert rule to notify you if a virtual machine's CPU usage exceeds a certain threshold.

• Action Groups: A collection of notification preferences that define how you want to be notified when an alert is triggered. This can include email, SMS, push notifications, or even automated actions like running an Azure Function.

• Log Analytics: A tool within Azure Monitor that allows you to collect and analyze log data from various sources, including your Azure resources, applications, and on-premises systems. You can use Log Analytics to perform queries, create visualizations, and gain insights into your environment.

• Alert Processing Rules: Rules that allow you to further customize the behavior of your alerts. This includes suppressing notifications during specific time periods, changing the severity of alerts, or adding additional actions to be taken when an alert is triggered.

Scenario

Your organization relies on Azure infrastructure. To ensure operational stability, you need to implement monitoring to detect and respond to critical events, such as virtual machine deletions. You'll use Azure Monitor to create alerts, define notification actions, and analyze logs.

Learning Objectives

By the end of this lab, you will be able to:

• Deploy a virtual machine for testing monitoring scenarios.

• Create alert rules in Azure Monitor.

• Configure action groups to receive alert notifications.

• Trigger an alert and verify its functionality.

• Configure alert processing rules to manage alert behavior.

• Use Azure Monitor Log Analytics to query resource data.

Job skills

• Task 1: Use a template to provision an infrastructure.

• Task 2: Create an alert.

• Task 3: Configure action group notifications.

• Task 4: Trigger an alert and confirm it is working.

• Task 5: Configure an alert processing rule.

• Task 6: Use Azure Monitor log queries.

Task 1: Provision a Virtual Machine

1. Sign in to the Azure portal: https://portal.azure.com

2. Deploy from a custom template: Search for and select "Deploy a custom template" and select "Build your own template in the editor".

   • Select "Load file" and choose the az104-11-vm-template.json file. and select "Save".

3. Configure deployment:

   • Subscription: Your Azure subscription

   • Resource group: az104-rg11 (create new if needed)

   • Region: East US

   • Username: localadmin and strong password.

4. Deploy:

   • Select "Review + Create" and then "Create".

   • Wait for deployment to complete.

   • Go to the resource group to verify the virtual machine and network are deployed.

Task 2: Enable Azure Monitor for VMs

1. Navigate to Monitor: Search for and select "Monitor" in the Azure portal.

2. Enable VM Insights:

   • Select "Insights" in the left-hand menu.

   • Select "Virtual Machines" (under "Compute" if necessary).

   • Select your virtual machine and click "Enable".

   • Accept the defaults and select "Enable" again and then configure.

   • Allow a few minutes for the agent to install.

Task 3: Create an Alert Rule

1. Go to Alerts: In the Monitor page, select "Alerts" in the left-hand menu.

2. Create an alert rule:

   • Select "Create +" and then "Alert rule".

   • Select the resource group (az104-rg11) and click "Apply".

3. Define the alert condition:

   • Select "Condition" and then "See all signals".

   • Search for and select "Delete Virtual Machine (Virtual Machines)".

   • Click "Apply".

   • In the "Alert logic" area, keep the default "Event level" and "Status" settings.

Task 4: Configure an Action Group

1. Create an action group: In the alert rule creation pane, select "Next: Actions" and select "Create action group".

2. Provide action group details:

   • Subscription: Your Azure subscription

   • Resource group: az104-rg11

   • Region: Global (default)

   • Action group name: AlertOpsTeam (or a unique name)

   • Display name: Alert the operations team

3. Configure email notification:

   • Select "Next: Notifications".

   • Notification type: Email/SMS message/Push/Voice

   • Name: VM was deleted

   • Select "Email" and enter your email address.

   • Click "OK".

4. Finalize alert rule:

   • Select "Next: Details".

   • Alert rule name: VM was deleted

   • Alert rule description: A VM in your resource group was deleted

   • Select "Review + create" and then "Create".

Task 5: Trigger and Test the Alert

1. Delete the VM: Go to "Virtual machines" in the portal and select the az104-vm0 virtual machine.

   and click "Delete", check "Apply force delete", and confirm the deletion.

2. Check for notification: Monitor the notifications in the portal and your email for the alert.

3. View alert details: In the Monitor blade, go to "Alerts" select the "VM was deleted" alert to see details.

Task 6: Configure an Alert Processing Rule

1. Create a processing rule:

   • In the "Alerts" blade, select "Manage alert processing rules" at the top.

   • Click "Create" and then "Suppression rule".

   • Select your resource group and click "Apply".

2. Schedule suppression:

   • Suppression schedule: Recurring schedule

   • Start time: Today's date at 10 PM

   • End time: Tomorrow's date at 7 AM

   • Time zone: Your local time zone

3. Provide rule details:

   • Rule name: Planned Maintenance

   • Description: Suppress notifications during planned maintenance.

   • Select "Review + create" and then "Create".

Task 7: Explore Azure Monitor Log Queries

no result!

1. Open Logs: In the Azure portal, search for and select "Monitor", then click "Logs" in the left-hand menu. (close the splash screen)

2. Set scope: Select your resource group (az104-rg11) and click "Apply".

3. Run pre-built queries:

   • In the "Queries" tab, select "Virtual Machines".

   • Run the "Count heartbeats" query.

   • Analyze the results.

4. Try a custom query:

   • Replace the existing query with the following and run it:Code snippet

       InsightsMetrics
       | where TimeGenerated > ago(1h)
       | where Name == "UtilizationPercentage"
       | summarize avg(Val) by bin(TimeGenerated, 5m), Computer 
       | render timechart
     

5. 

Cleanup Resources

To avoid unnecessary costs, delete the resource group az104-rg11 after you've completed the lab.

Extend your Learning

• Log Analytics Demo Environment: Practice with more log queries in a dedicated demo environment (provide a link if available).

• Microsoft Copilot: Use Copilot to explore Azure Monitor further:

  • Ask questions like:

    • "What are the basic configuration steps to be alerted in Azure when a virtual machine is down?"

    • "How can I be notified when an Azure alert is triggered?"

    • "Construct an Azure Monitor query to provide virtual machine CPU performance information."

• Self-paced training:

  • Improve incident response with alerting on Azure: [Link to relevant Microsoft Learn module]

  • Monitor your Azure virtual machines with Azure Monitor: [Link to relevant Microsoft Learn module]

Key Takeaways

• Azure Monitor provides essential tools for monitoring your Azure resources.

• Alert rules help you proactively identify and address issues.

• Action groups enable you to define notification methods for alerts.

• Alert processing rules offer fine-grained control over alert behavior.

• Log Analytics allows you to query and analyze log data for deeper insights.

Scenario: Your organization is evaluating Azure's data protection capabilities. You need to implement a backup solution for Azure VMs and explore Azure Site Recovery for disaster recovery preparedness.

Key Concepts:

• Recovery Services Vault: A storage entity in Azure that houses backup data and recovery points for protected resources (VMs, databases, etc.). It's the central management point for Azure Backup and Azure Site Recovery.

• Backup Policy: Defines the schedule for backups (frequency) and how long recovery points are retained (retention period).

• Azure Backup: A service for backing up data to a Recovery Services vault. It supports various workloads,including Azure VMs, on-premises servers, and Azure Files.

• Azure Site Recovery (ASR): A disaster recovery service that replicates workloads from a primary site to a secondary location. In case of an outage at the primary site, you can failover to the secondary site.

• Replication: The process of continuously copying data from a source (e.g., a VM) to a target (e.g., a Recovery Services vault in a different region).

• Failover: The process of switching from the primary site to the secondary site (replica) in the event of an outage.

• Failback: The process of switching back to the primary site after the outage is resolved.

• Soft Delete: Helps protect backup data from accidental deletion.

• Task 1: Use a template to provision an infrastructure.

• Task 2: Create and configure a Recovery Services vault.

• Task 3: Configure Azure virtual machine-level backup.

• Task 4: Monitor Azure Backup.

• Task 5: Enable virtual machine replication.

Task 1: Provision Infrastructure (Template)

1. Download Lab Files: Download the \Allfiles\Labs\Lab10 files (template and parameters: az104-10-vms-edge-template.json and az104-10-vms-edge-parameters.json).

2. Sign In: Log in to the Azure portal (https://portal.azure.com).

3. Deploy Custom Template:

   • Search for and select "Deploy a custom template."

   • Choose "Build your own template in the editor."

   • Click "Load file" and select az104-10-vms-edge-template.json.

   • Click "Save."

   • Click "Edit parameters" and load the az104-10-vms-edge-parameters.json file.

   • Click Save.

   • Basics:

     • Username: localadmin

     • Password: (Provide a strong password)

   • Click "Review + create," then "Create."

4. Go to Resource: Once deployed, click "Go to resource." (This will take you to the deployed VM, az104-10-vm0). You should have one VM in one VNet.

Task 2: Create and Configure a Recovery Services Vault

1. Create Vault: Search for and select "Recovery Services vaults" and click "+ Create."

   • Basics:

     • Vault Name: az104-rsv-region1

     • Region: East US (Must be the same region as the VM)

   • Click "Review + create," then "Create."

2. Go to Resource: Once deployed, click "Go to resource."

3. Configure Storage Redundancy (Before Backups):

   • In the vault, under "Settings," select "Properties."

   • Under "Backup Configuration," click "Update."

   • Storage replication type: Leave as Geo-redundant (default). Note: This can only be configured before any backups are created. Close the blade.

   • The Cross Region Restore option allows you to restore data in a secondary, Azure paired region.

4. Review Security Settings (Soft Delete):

   • Under "Security Settings," click "Update".

   • Note that "Soft Delete (For workload running in Azure)" is Enabled by default with a 14-day retention.This helps protect against accidental or malicious deletion of backups.

Task 3: Configure Azure VM Backup

1. Initiate Backup:

   • In your Recovery Services vault (az104-rsv-region1), click "Overview," then "+ Backup."

   • Backup Goal:

     • Where is your workload running?: Azure

     • What do you want to backup?: Virtual machine

   • Click "Backup."

2. Create Backup Policy:

   • Policy sub type: Standard

   • In "Backup policy", select "Create a new policy."

     • Policy name: az104-backup

     • Frequency: Daily

     • Time: 12:00 AM

     • Timezone: (Select your local time zone)

     • Retain instant recovery snapshot(s) for: 2 Days(s)

     • Click "OK."

3. Add VM to Backup:

   • In the "Virtual Machines" section, click "Add."

   • Select az104-10-vm0.

   • Click "OK."

   • Click "Enable backup." (Wait for backup to be enabled - about 2 minutes.)

4. Trigger an Initial Backup (On-Demand):

   • In the Recovery Services vault, under "Protected items", click "Backup items."

   • Click the "Azure Virtual Machine" entry.

   • Select "View details" for az104-10-vm0. Note the "Backup Pre-Check" and "Last Backup Status."

   • Click "Backup now."

   • Accept the default "Retain Backup Till" date.

   • Click "OK." (Do NOT wait for the backup to complete; proceed to the next task.)

Task 4: Monitor Azure Backup

1. Create a Storage Account: Search for and select "Storage accounts" and click "Create."

   • Basics:

     • Storage account name: (Provide a globally unique name)

2. Configure Diagnostic Settings:

   • Go back to your Recovery Services vault (az104-rsv-region1).

   • Under "Monitoring," select "Diagnostic settings."

   • Click "Add diagnostic setting."

     • Diagnostic setting name: LogsAndMetricsToStorage

     • Logs Categories: Check:

       • AzureBackupReportData

       • AddonAzureBackupJobData

       • AddonAzureBackupAlertData

       • AzureSiteRecoveryJobs

       • AzureSiteRecoveryEvents

       • Health

     • Destination details: Check "Archive to a storage account."

     • Storage account: Select the storage account you just created.

   • Click "Save."

3. View Backup Jobs:

   • In your Recovery Services vault, under "Monitoring," select "Backup jobs."

   • Locate the backup job for az104-10-vm0.

   • Review the job details (status, start time, etc.).

Task 5: Enable Virtual Machine Replication (for Disaster Recovery)

1. Create a Second Recovery Services Vault (in a Different Region): Search for and select "Recovery Services vaults" and click "+ Create."

   • Basics:

     • Resource Group: az104-rg-region2 (create if it doesn't exist)

     • Vault Name: az104-rsv-region2

     • Region: Central US (Must be a different region than your VM)

   • Click "Review + create," then "Create."

** I had to click on create automation account here to be able to activate the “Review + Start replication”

2. Enable Replication on the VM:

   • Search for and select the az104-10-vm0 virtual machine.

   • Under Backup + Disaster recovery, select Disaster recovery.

   • Select Review + Start replication.

   • Basics tab: Note the Target region.

   • Advanced Settings Tab: Review the automatically-selected resources. Crucially, ensure the “churn for the vmand ” and "Cache storage account" have values. If not, refresh the page, or create a storage account manually and return.

   • Click "Review + Start replication," then "Start replication."

   • Wait for Replication: This will take 10-15 minutes. Monitor the notification messages in the portal.

3. Check Replicated Items:

   • Once replication is complete (you'll see a notification), go to your second Recovery Services vault (az104-rsv-region2).

   • Under "Protected items," select "Replicated items."

   • You should see az104-10-vm0 listed with a "Healthy" replication status. The initial synchronization might still be in progress (showing a percentage). Eventually, it will show "Protected."

   • Click on the VM to view more details.

…

…