Lab Overview

This lab covers three high-frequency Azure admin tasks:

1. Use Azure Monitor metrics to identify infrastructure performance bottlenecks.
2. Configure Azure Backup to schedule VM backups in a Recovery Services vault and understand which VM OS types and states are supported.
3. Bulk onboard external users as Azure AD (Entra ID) guests using the correct bulk operation and PowerShell invitation cmdlets.

---

Lab Objectives

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

• Use Azure Monitor to analyze time-series metrics and isolate a performance issue.
• Differentiate when to use Metrics, Logs, Activity log, Advisor, and Traffic Analytics.
• Configure VM backup policies and confirm supported VM workloads.
• Bulk invite external users to your tenant using:
  • Portal-based Bulk invite users
  • PowerShell automation using New-AzureADMSInvitation (or Microsoft Graph equivalent)

---

Prerequisites

Permissions

• Monitoring Reader or higher on the Azure resources you are troubleshooting.
• Backup Contributor (or Contributor) on the Recovery Services vault and protected VMs.
• User Administrator or Guest Inviter role (Entra ID) for guest invitations.
  • Some tenants restrict guest invites via External collaboration settings.

Resources

• An Azure subscription with at least one workload showing performance symptoms (VMs, App Service, AKS, Storage, etc.).
• A Recovery Services vault in the same subscription.
• A CSV file with external user names and email addresses (500 users).

---

Lab 1: Troubleshoot Infrastructure Performance Using Azure Monitor Metrics

Goal

Identify the likely cause of performance degradation using Azure infrastructure metrics (fast, near-real-time signals like CPU, memory-related counters, disk, and network).

Why Azure Monitor (Metrics) is the correct tool

• Metrics are stored in a time-series database optimized for fast charting, alerting, and trend analysis.
• This is the first stop for “performance issues” when you suspect the platform layer (VM host, disk throughput, network) or resource limits.

Where Azure Monitor fits compared to other options

Use this as your mental model:

Tool	What it answers	When to use
Azure Monitor (Metrics)	“What is the resource doing over time?”	CPU spikes, disk queue, NIC throughput, saturation, throttling
Azure Monitor (Logs / Log Analytics)	“What happened and why?”	Deep investigation across logs, KQL correlation, app + OS events
Activity log	“Who/what changed my resource?”	Deployments, scale operations, NSG changes, restart, write operations
Advisor	“What should I improve?”	Recommendations: cost, performance, reliability, security posture
Traffic Analytics	“What’s the flow pattern on the network?”	NSG flow logs analytics, traffic patterns, security review

---

Step-by-step: Metrics investigation workflow (Portal)

Step 1: Identify the affected resource(s)

Start from the resource you suspect:

• Virtual machine: check CPU, disk, network
• App Service: check CPU, memory working set, requests, response time
• Storage: check latency, throttling
• AKS: check node metrics, pod pressure, cluster autoscaler behavior (often via Container Insights)

Step 2: Open Metrics

Azure portal → Monitor → Metrics
Or resource → Monitoring → Metrics

Step 3: Select scope

Pick the specific resource(s):

• VM: VM-SRV01, VM-SRV02
• Disk: managed disk resource (if needed)
• NIC: network interface resource (if needed)

Step 4: Add the “first-pass” metrics (typical for VM performance triage)

For Windows/Linux VMs (platform metrics vary by SKU/agent, but these are common checks):

Compute

• CPU Percentage (or CPU utilization)

Disk

• Disk Read Bytes/Sec
• Disk Write Bytes/Sec
• Disk Read Operations/Sec
• Disk Write Operations/Sec
• Disk Queue Depth (if available)

Network

• Network In Total
• Network Out Total

Step 5: Set time range and granularity

• Time range: last 1 hour (then expand to 24 hours for patterns)
• Granularity: start with 1 minute for spikes, then 5 minutes for trends

Step 6: Interpret common patterns (quick diagnosis)

Use these “symptom to cause” mappings:

• CPU pinned 90–100% for long periods
  Likely compute saturation, too small VM size, runaway process, scaling needed.
• Disk throughput flatlines at a ceiling + latency symptoms
  Likely disk IOPS/throughput limit for SKU/disk tier, or heavy IO pattern.
• Network in/out spikes + packet drops (if you have NVA or guest stats)
  Likely network saturation, large data transfers, or misrouted traffic.
• Performance changed suddenly at a specific time
  Cross-check Activity log for a deployment, resize, restart, NSG change.

Step 7: Create an alert (to catch recurrence)

Azure portal → Monitor → Alerts → Create

• Signal type: Metrics
• Example: CPU > 85% for 10 minutes
• Action group: email / ITSM / webhook

---

Validation checklist

• Metrics show a clear correlation between user-reported slowness and infrastructure saturation.
• You captured the “before/after” baseline.
• You created at least one metric alert to detect recurrence.
• If root cause is unclear, you escalated to Logs (Log Analytics / VM insights).

---

Lab 2: Schedule Azure VM Backups to a Recovery Services Vault

Goal

Enable scheduled backups for Azure VMs using Azure Backup with a Recovery Services vault, and confirm which VMs are supported.

Core concept: What you can back up

Azure VM backup supports a wide range of OS types and also supports backing up VMs regardless of whether they are currently running.

In practice, for typical Azure IaaS workloads:

• Windows client (including Windows 10) can be protected (64-bit).
• Windows Server versions (including 2012 and above) are supported.
• Many Linux distros are supported (Debian versions are supported, subject to Azure’s backup support matrix).
• VM power state (running vs stopped) does not prevent backup eligibility.

---

Step-by-step: Configure backups (Portal)

Step 1: Open the vault

Azure portal → Recovery Services vaults → select your vault

Step 2: Start backup configuration

Vault → Backup

• Where is your workload running? Azure
• What do you want to back up? Virtual machine

Step 3: Select the VMs

Choose the VMs you want to protect.

Step 4: Assign or create a backup policy

Pick:

• Backup frequency (daily/weekly)
• Backup time
• Retention (daily/weekly/monthly/yearly)

Step 5: Enable backup

Submit. The vault registers the VM for protection.

Step 6: Trigger an on-demand backup (recommended for validation)

Vault → Backup items → Azure Virtual Machine → select VM → Backup now

---

Verification steps

Vault → Backup jobs

• Confirm job status: Completed

Vault → Backup items → VM

• Confirm latest recovery point exists

---

Operational notes (what admins should watch)

• Ensure the VM has required connectivity and that backup extension operations succeed.
• Ensure retention aligns with ransomware recovery needs.
• For ransomware scenarios:
  • Prefer restoring to a new VM for full restore.
  • Use File recovery to retrieve specific files safely into a clean environment.

---

Lab 3: Bulk Create Guest Users from a CSV (Correct Methods)

Goal

Create guest user accounts for 500 external users listed in a CSV file.

Key concept: Guests are invited, not created like members

A guest user workflow is an invitation flow.

• Creating “normal users” uses user creation operations.
• Creating guests uses invitation operations.

This matters because:

• “Bulk create users” is for member users, not guest invites.
• For guests, use Bulk invite users or an invitation cmdlet/API.

---

Method A: Portal bulk invite users (fastest for admins)

Step 1: Prepare CSV

Use columns that align with Entra ID bulk invite requirements. Common fields:

• email
• displayName
• optional: invitedUserMessageInfo or redirect URL preferences (tenant-dependent)

Step 2: Run bulk invite

Azure portal → Microsoft Entra ID

• Users → All users
• Select Bulk operations → Bulk invite users
• Upload the CSV
• Start the operation

Step 3: Verify results

• Entra ID → Users → filter by User type = Guest
• Check invitation status if available

---

Method B: PowerShell automation (invitation cmdlet)

Why this works

The invitation cmdlet is designed to:

• Invite external users
• Create guest objects in the directory
• Send invitation emails (unless configured otherwise)

Steps (high-level workflow)

1. Import CSV
2. Loop each record
3. Send invitation per user
4. Log successes and failures
5. Validate guest objects exist

Example structure (AzureAD module pattern)

If using New-AzureADMSInvitation, the flow is:

• Connect to AzureAD
• For each user:
  • Invite with New-AzureADMSInvitation
  • Set redirect URL
  • Optionally customize invitation message

Validation

• Confirm 500 guest user objects exist
• Confirm invitations were issued successfully (audit logs can help)

Note: In many environments, admins now prefer Microsoft Graph PowerShell (New-MgInvitation) because AzureAD module is being phased out. The principle stays the same: use an invitation operation for guests.

---

Common failure points and fixes

1) Guests can’t be invited

• Check Entra ID → External Identities → External collaboration settings
• Ensure your role is allowed to invite (or that “admins only” is not restricting you)

2) Duplicate invites

• If a guest object already exists, invitation may fail or re-invite depending on settings.
• Pre-check by email (UPN or mail attribute) before inviting.

3) CSV formatting issues

• Wrong headers or extra whitespace
• Bad email formats
• Encoding issues (save as UTF-8 CSV)

---

Final validation checklist

• You can see guest user objects for the invited emails.
• Invitation process completed without significant failures.
• You captured a log of failed invites for reprocessing.
• You confirmed external collaboration policy allows invitations.

---