Azure Resource Manager explained: a complete guide for IT admins and developers
Everything you need to know about ARM — how resources are organised, why resource groups matter, and how Bicep makes deployment painless.
Practical guides, real-world tutorials, and step-by-step walkthroughs for IT admins, Azure developers, students, and everyday Microsoft 365 users. Free, forever.
From first-principles explainers to advanced configurations — click any category to explore.
Everything you need to know about ARM — how resources are organised, why resource groups matter, and how Bicep makes deployment painless.
Whether you're just starting out or preparing for your next certification — you're in the right place.
Structured study guides for every major Microsoft cloud cert — written clearly, updated regularly.
"The AZ-104 study guide on Queclouds is the clearest breakdown I've found. Passed my exam on the first attempt — can't recommend it enough."
"Finally a site that explains Entra ID Conditional Access without burying me in Microsoft docs. The step-by-step guides are exactly what I needed."
"I've bookmarked Queclouds as my go-to reference for all things Microsoft 365. The Exchange and Teams governance articles are outstanding."
Everything you need to pass AZ-900 on your first attempt — free, comprehensive, and kept up to date with the latest exam objectives. No account needed, no paywall.
This domain tests whether you understand what cloud computing is, why organisations adopt it, and how different cloud models and service types compare. It's the most conceptual domain — no portal clicks required.
Cloud computing is the delivery of computing services — servers, storage, databases, networking, software, analytics — over the internet. Instead of owning and maintaining physical data centres, you rent capacity from a cloud provider and pay only for what you use.
Key characteristics of cloud computing:
The AZ-900 exam frequently tests the business benefits of cloud. Know these well:
Azure services fit into one of three service models. Understanding which layer of responsibility you own in each is a common exam question.
| Model | You manage | Azure manages | Azure example |
|---|---|---|---|
| IaaS — Infrastructure as a Service | OS, runtime, apps, data | Servers, storage, networking, virtualisation | Azure Virtual Machines |
| PaaS — Platform as a Service | Applications and data only | OS, runtime, middleware, infrastructure | Azure App Service, Azure SQL |
| SaaS — Software as a Service | Data and access settings | Everything else | Microsoft 365, Dynamics 365 |
Think of it as a pizza analogy: IaaS = you make the pizza in a rented kitchen. PaaS = dough and oven provided, you add toppings. SaaS = pizza delivered to your door.
There are three main deployment models tested on AZ-900:
This is the largest domain and covers the actual Azure services you'll encounter day-to-day. Focus on what each service does, how it fits into Azure architecture, and when you'd choose one over another.
Regions — Azure has 60+ regions worldwide (e.g. UK South, East US, Southeast Asia). A region is a geographical area containing one or more data centres. When you create a resource, you choose a region.
Region Pairs — Most Azure regions are paired with another region in the same geography at least 300 miles apart. During planned maintenance, only one region in a pair is updated at a time, reducing downtime risk.
Availability Zones — Physically separate data centres within a region, each with independent power, cooling, and networking. Deploy across zones for 99.99% SLA. Not all regions support Availability Zones.
Sovereign Regions — Azure Government (US) and Azure China are physically and logically isolated from commercial Azure, operated by separate entities to meet compliance requirements.
Azure organises everything into a management hierarchy. Know this from top to bottom:
Compute is how you run code and applications on Azure. The main services tested on AZ-900:
Azure has several storage types — know what each is best for:
AZ-900 only requires a high-level understanding of these — not deep technical knowledge.
This domain covers how you control costs, manage compliance, secure your environment, and use Azure tools to manage everything at scale. Governance is increasingly tested as organisations move large workloads to cloud.
Understanding Azure costs is a key part of Domain 3. You won't need to memorise prices, but you need to understand factors that affect cost:
az commands to manage Azure.Az cmdlets. Preferred by Windows administrators.Everything you need to pass MS-900 on your first attempt — free, comprehensive, and aligned with the latest exam objectives. Covers cloud services, M365 apps, security, compliance, and licensing.
The smallest domain — it mirrors the cloud concepts content in AZ-900. If you've already studied AZ-900, you can move quickly through this section.
MS-900 tests the same core cloud computing benefits as AZ-900 but from a productivity and business lens:
Microsoft 365 is primarily a SaaS (Software as a Service) offering. You don't manage servers, operating systems, or middleware — Microsoft manages everything. You manage your users, data, and configurations.
MS-900 occasionally asks about the spectrum:
This is by far the largest domain. It tests your knowledge of what each Microsoft 365 service does, how they interconnect, and which service is the right tool for a given scenario. Know each service's primary purpose.
Teams is the hub for teamwork in Microsoft 365 — combining chat, video meetings, calling, and file sharing in one app.
Exchange Online is Microsoft's cloud-hosted email and calendar service. It's the backbone of business email in M365.
SharePoint Online is the intranet, document management, and content collaboration platform in M365.
OneDrive for Business is personal cloud storage for each user — like Dropbox but integrated into M365.
Copilot is Microsoft's AI assistant embedded across M365 apps, powered by GPT-4 and connected to your organisational data via Microsoft Graph.
Microsoft Viva is a suite of employee experience tools built on top of Teams and M365. MS-900 tests awareness of the modules:
Power Platform is Microsoft's low-code/no-code suite for building apps, automating workflows, and analysing data. It integrates deeply with M365.
Intune is Microsoft's cloud-based mobile device and application management platform — part of Microsoft Endpoint Manager.
This domain tests your understanding of how Microsoft 365 protects organisations from threats, how it helps meet compliance obligations, and how Microsoft handles your data and privacy. High-value area for the exam.
Microsoft 365 Defender is a unified security platform that integrates multiple protection services:
Microsoft Purview is the compliance and data governance hub in M365. Key features tested on MS-900:
MS-900 asks about Microsoft's privacy principles — not in deep legal detail, but conceptually:
This domain covers Microsoft 365 licensing models, how subscriptions work, and the different support options available. It's the smallest domain but has some reliable exam question areas.
Microsoft 365 is sold as a per-user, per-month subscription. Key plan families to know:
| Plan Family | Target | User limit | Key features |
|---|---|---|---|
| M365 Business Basic | Small business | Up to 300 users | Web/mobile Office apps, Exchange, Teams, SharePoint, OneDrive |
| M365 Business Standard | Small business | Up to 300 users | + Desktop Office apps (Word, Excel, PowerPoint), Teams webinars |
| M365 Business Premium | Small business | Up to 300 users | + Intune, Defender for Business, Entra ID P1, Azure Information Protection P1 |
| M365 E3 | Enterprise | Unlimited | + Entra ID P1, Intune, Purview, compliance tools, advanced analytics |
| M365 E5 | Enterprise | Unlimited | + Defender for Office P2, Defender for Endpoint P2, Entra ID P2, Power BI Pro, Purview Premium |
Add-on licences — some features require add-ons on top of the base plan. Examples: Microsoft 365 Copilot (add-on), Teams Phone (add-on), Teams Rooms (add-on for meeting room devices), Audio Conferencing (add-on).
Microsoft commits to service availability through SLAs. Key facts for MS-900:
The AZ-104 is the core hands-on Azure admin certification. This free guide covers all five exam domains in full — manage identities, governance, storage, compute, and networking on Azure. Pass first time.
This domain covers Entra ID user and group management, RBAC, subscriptions, and Azure Policy. It's heavily tested with scenario questions about who should have what access and how to enforce governance at scale.
Creating users: You can create users in the Entra admin centre, via PowerShell (New-MgUser), or bulk import via CSV. Users can be cloud-only (created in Entra ID) or synced from on-premises AD DS via Entra Connect.
Guest users (B2B): External users invited to collaborate. They authenticate with their own organisation's identity. Manage them under External Identities. You can restrict what guest users can see and do in your tenant.
Group types — know both:
Membership types:
department -eq "Finance"). Automatically adds/removes users as attributes change. Requires Entra ID P1.Role assignment anatomy: Every role assignment has three parts: a security principal (who), a role definition (what permissions), and a scope (where it applies). Assignments are inherited down — a Contributor at the subscription level is a Contributor on all resource groups and resources in that subscription.
Key built-in roles for the exam:
Custom roles: When no built-in role fits, create a custom role with exactly the actions needed. Defined in JSON, scoped to specific subscriptions. Limit of 5,000 custom roles per tenant.
Azure Policy evaluates resources against rules you define. Policies can:
Policy initiatives (also called policy sets) group multiple policies together. For example, the "Azure Security Benchmark" initiative bundles 200+ policies. Assign the initiative to a scope rather than assigning each policy individually.
Remediation tasks: Existing non-compliant resources are not automatically fixed when a policy is assigned — you need to create a remediation task manually (or configure automatic remediation for DeployIfNotExists policies). The policy's managed identity performs the remediation.
Management groups: Assign policies at a management group to enforce them across all child subscriptions. This is how enterprises enforce standards like "all resources must be in approved regions" across 50+ subscriptions simultaneously.
Storage is a significant exam topic. You need to understand storage account types, access controls, redundancy, lifecycle management, and Azure File Sync. Expect scenario questions about which storage type to use and how to secure access.
Storage account kinds:
Access tiers for blob storage:
Access keys: Every storage account has two 512-bit access keys — full administrative access to all data. Rotate them regularly. Anyone with a key can read, write, and delete everything. Avoid using keys directly in application code — use Managed Identities or SAS tokens instead.
Shared Access Signatures (SAS): Time-limited, permission-scoped URIs that grant specific access to specific storage resources without exposing the account key.
Stored access policies: Define a policy on a container that SAS tokens can reference. If you need to revoke a SAS, delete or modify the stored access policy rather than rotating the account key.
Entra ID authentication (RBAC for storage): Use roles like Storage Blob Data Contributor to grant a user or managed identity access to blob data without using keys. This is the most secure approach for application access.
Network access controls: Restrict storage account access to specific VNets (service endpoints or private endpoints) or IP ranges via the Storage account → Networking → Firewalls and virtual networks settings. Enable "Allow Azure services" only if needed.
Azure Files provides fully managed file shares accessible via SMB 3.0 and NFS 4.1. Mount them on Windows, Linux, and macOS. Use cases: lift-and-shift of on-premises file servers, shared configuration files for applications, dev/test environments.
Azure File Sync extends Azure Files to on-premises Windows Server. Synchronises files between a Windows Server and an Azure File share, with optional cloud tiering — less frequently accessed files are automatically replaced by a pointer, freeing up local disk space while keeping files accessible (they download on-demand).
Components of Azure File Sync:
| Redundancy | Copies | Scope | Use when |
|---|---|---|---|
| LRS — Locally Redundant | 3 | Single data centre | Cost-sensitive, can tolerate data centre failure |
| ZRS — Zone Redundant | 3 | 3 availability zones in one region | High availability within a region |
| GRS — Geo Redundant | 6 (3+3) | Primary + secondary region | Disaster recovery, secondary is read-only only on failover |
| GZRS — Geo-Zone Redundant | 6 | ZRS primary + LRS secondary | Highest availability + geo protection |
| RA-GRS / RA-GZRS | 6 | Same as GRS/GZRS | Read access to secondary region at all times (not just on failover) |
The secondary region is determined by Azure — you don't choose it. It's always a fixed pair (e.g. UK South pairs with UK West). You can initiate an account failover to promote the secondary to primary during a regional outage, but this has data loss implications.
Lifecycle management policies automatically transition blobs between access tiers or delete them based on rules:
Policies are defined in JSON and applied at the storage account level. Filters can target specific containers or blob prefixes.
Object replication asynchronously replicates block blobs from a source storage account to a destination account (can be in a different region or subscription). Useful for keeping a copy of data in another geography, or feeding a CDN account. Requires versioning and change feed to be enabled on the source.
Immutability policies (WORM): Write Once Read Many — prevent blobs from being modified or deleted for a defined period. Used for compliance: financial records, healthcare data. Two types: time-based retention policies and legal holds.
Compute is the largest domain. VMs, availability sets, scale sets, App Service, containers, and ARM/Bicep templates are all tested. Expect scenario questions about choosing the right compute service and configuring VMs for high availability.
VM sizing families: Azure VMs come in families optimised for different workloads. Key ones for the exam:
VM disks:
Managed disk types: Ultra Disk (highest performance, sub-millisecond latency), Premium SSD v2, Premium SSD, Standard SSD, Standard HDD. Choose based on IOPS and throughput requirements vs cost.
Availability Sets protect against hardware failures within a single data centre by spreading VMs across:
Availability Sets give a 99.95% SLA. They protect only within one data centre — a full data centre failure takes down all VMs in an availability set.
Availability Zones spread VMs across physically separate data centres within a region (each with independent power, cooling, networking). Deploy VMs to Zone 1, 2, and 3 for 99.99% SLA. Protects against data centre failure. Not available in all regions.
VM Scale Sets (VMSS): Deploy and manage a group of identical, load-balanced VMs. Scale manually or automatically based on CPU, memory, custom metrics, or schedule. Two orchestration modes:
VM Extensions are small applications that provide post-deployment configuration and automation on Azure VMs. They run after VM deployment without needing you to RDP/SSH in.
Desired State Configuration (DSC): PowerShell-based configuration management. Define the desired state of a VM (IIS installed, specific services running, files in place) and DSC ensures the VM stays in that state.
Run Command: Execute scripts on a VM directly from the Azure portal or CLI without opening firewall ports or using SSH/RDP. Useful for emergency access when normal connectivity is broken.
App Service is a PaaS platform for hosting web applications, REST APIs, and mobile backends. You manage code and configuration; Azure manages the OS, runtime, patching, and scaling.
App Service Plans define the region, OS, and compute capacity for your app. Multiple apps can share one plan. Key tiers:
Deployment slots: Named environments (staging, production) within the same App Service. Deploy to staging, test, then swap slots with zero downtime. Blue-green deployment pattern.
App Service networking:
Azure Container Instances (ACI): The fastest way to run a Docker container in Azure. No VM management, no cluster setup. Billed per second of use. Best for: short-lived jobs, burst compute, simple applications, CI/CD build agents.
ACI supports Linux and Windows containers, can mount Azure File shares for persistent storage, and supports container groups (multiple containers sharing a network and lifecycle — similar to Kubernetes pods).
Azure Kubernetes Service (AKS): Managed Kubernetes. Azure manages the control plane (API server, etcd); you manage the node pools (VMs running your workloads).
The AZ-104 exam tests practical IaC knowledge — you need to understand ARM template structure and be able to read Bicep syntax.
ARM template sections:
$schema — identifies the template schema versioncontentVersion — your versioning for the templateparameters — values passed at deployment time (with types, defaults, allowed values)variables — computed values reused throughout the templateresources — the resources to deploy (required)outputs — values returned after deploymentdependsOn: Explicitly declare dependencies between resources when ARM can't infer them automatically. Example: a VM extension must deploy after the VM.
linked and nested templates: Break large templates into smaller files. Linked templates reference an external URI. Nested templates are defined inline within the parent template. Both help manage complexity and enable reuse.
Deployment scopes: Templates can deploy at resource group, subscription, management group, or tenant scope. Most deployments are at resource group scope. Subscription-scope deployments create resource groups and assign policies. Use az deployment sub create for subscription-level deployments.
Networking is consistently the most challenging domain for AZ-104 candidates. VNets, NSGs, routing, load balancers, VPN Gateway, and DNS — all tested with scenario questions. Read carefully: many scenarios hinge on a single configuration detail.
VNet basics: A Virtual Network (VNet) is an isolated, private network in Azure. Resources in the same VNet can communicate by default. VNets are scoped to a single region and subscription.
Address space: Defined using CIDR notation (e.g. 10.0.0.0/16 gives 65,536 IP addresses). Cannot overlap with other VNets you peer with or your on-premises networks. Plan address spaces carefully — they're hard to change after resources are deployed.
Subnets: Subdivisions of a VNet's address space. Each resource goes into a subnet. Azure reserves 5 addresses per subnet (first 4 + last): network address, gateway, DNS, broadcast, and another for Azure internal use. A /29 subnet gives only 3 usable addresses — use /27 or larger for production.
Special subnets:
NSGs are stateful firewalls containing inbound and outbound security rules. Each rule specifies: priority (100–4096, lower = higher priority), source/destination (IP, CIDR, service tag, or application security group), port, protocol, and Allow/Deny action.
Where NSGs can be applied:
Traffic evaluation when both subnet and NIC NSGs exist: inbound — subnet NSG evaluated first, then NIC NSG. Outbound — NIC NSG first, then subnet NSG. Both must allow traffic for it to pass.
Default rules (cannot be deleted, can be overridden with lower priority number):
Service tags: Named groups of IP prefixes managed by Microsoft. Use instead of hardcoding IP ranges. Examples: Internet, VirtualNetwork, AzureLoadBalancer, Storage, Sql, AppService.
Application Security Groups (ASGs): Group VMs logically by role (e.g. "WebServers", "DatabaseServers") and use ASG names in NSG rules instead of IP addresses. Rules automatically apply to all VMs in the ASG. Simplifies rule management as IPs change.
VNet peering connects two VNets (in the same or different regions, same or different subscriptions, same or different tenants) so their resources can communicate using private IP addresses. Traffic stays on the Microsoft backbone — never traverses the public internet.
Peering is non-transitive: if VNet A peers with VNet B, and VNet B peers with VNet C, VNet A cannot communicate with VNet C through VNet B. You need to peer A to C directly, or use a hub VNet with a gateway or NVA to route between them.
Key peering settings:
User-defined routes (UDR): Override Azure's default routing by creating a route table and associating it with a subnet. Common use: force all internet traffic through a Network Virtual Appliance (NVA) or Azure Firewall for inspection. Next hop types: Virtual appliance (specify NVA IP), Virtual network gateway, VNet, Internet, None (drop the traffic).
Azure Firewall vs NSG: NSGs are simple allow/deny rules at layer 4. Azure Firewall is a managed, stateful firewall with layer 7 filtering, FQDN rules, threat intelligence, and centralised logging. Use Azure Firewall for hub-and-spoke architectures where you need centralised egress inspection.
| Service | Layer | Scope | Use for |
|---|---|---|---|
| Azure Load Balancer | Layer 4 (TCP/UDP) | Regional | Load balance VMs within a region, internal or public |
| Application Gateway | Layer 7 (HTTP/S) | Regional | Web apps needing URL routing, SSL termination, WAF |
| Azure Front Door | Layer 7 (HTTP/S) | Global | Global web apps, CDN, WAF, anycast routing |
| Traffic Manager | DNS | Global | DNS-based routing across regions, failover, geographic routing |
Azure Load Balancer SKUs: Standard (zone-redundant, supports availability zones, HTTPS health probes, outbound rules) vs Basic (free, no zone support, no SLA). Always use Standard for production.
Application Gateway components: Frontend IP, Listener (port/protocol/hostname), Rules (map listeners to backend pools), Backend pools (VMs, VMSS, App Service, IPs), HTTP settings, Health probes.
WAF on Application Gateway: Web Application Firewall protects against OWASP top 10 (SQL injection, XSS, etc.). Detection mode logs and alerts; Prevention mode blocks malicious requests.
VPN Gateway connects on-premises networks to Azure VNets over encrypted IPsec/IKE tunnels across the public internet.
VPN Gateway SKUs: VpnGw1 through VpnGw5 (and AZ variants for zone-redundancy). Higher SKUs = more bandwidth and more S2S tunnels. Active-active mode uses two VPN instances for higher resilience.
ExpressRoute — dedicated private connectivity from on-premises to Azure, not over the internet. Offered through connectivity providers (BT, Equinix, Megaport etc.).
Public DNS zones: Host your public domain's DNS records in Azure DNS. Delegate from your registrar by setting Azure DNS name servers. Azure DNS is not a domain registrar — buy the domain elsewhere, then host the DNS in Azure.
Private DNS zones: Resolve names within your VNets without exposing records to the internet. Link a private DNS zone to VNets — VMs in those VNets resolve records in the zone automatically. Common pattern: use privatelink.blob.core.windows.net zone for storage private endpoints.
Azure-provided DNS (168.63.129.16): Default DNS for VMs in a VNet. Resolves Azure service names and forwards external queries to Azure's public resolvers. Can be replaced with custom DNS servers (point to your own DNS VM or Azure DNS Resolver).
Azure DNS Private Resolver: A managed DNS service that lets you query Azure private DNS zones from on-premises over ExpressRoute or VPN without deploying DNS server VMs. Inbound endpoints accept queries from on-premises; outbound endpoints forward queries to on-premises DNS servers.
The final domain covers monitoring, backup, and site recovery. Smaller in weight but often the difference between passing and failing — these are "easy marks" if you know the tools.
Azure Monitor is the central platform for all monitoring in Azure. It collects two types of data:
Diagnostic settings: Configure each resource to send its metrics and logs somewhere — a Log Analytics workspace, a Storage account, or an Event Hub. Not all data flows automatically — diagnostic settings must be explicitly configured per resource.
Alerts: Trigger when a metric or log query crosses a threshold. Alert rules have: scope (what resource), condition (what to watch), action group (what to do), and severity (0–4).
Action groups: Define what happens when an alert fires — email, SMS, push notification, voice call, webhook, Azure Function, Logic App, ITSM integration, Automation runbook.
Log Analytics workspaces: The central repository for logs. Multiple resources across multiple subscriptions can send to the same workspace. KQL query examples the exam tests:
Heartbeat | summarize LastCall = max(TimeGenerated) by Computer — find when VMs last reported inAzureActivity | where OperationName == "Delete Virtual Machine" — audit VM deletionsAzure Backup protects Azure VMs, SQL Server in Azure VMs, Azure Files, on-premises servers, and more.
Recovery Services Vault: The container for backup data and policies. Must be in the same region as the resources being backed up. Configure backup policies to define: frequency (daily, weekly), time, and retention (daily, weekly, monthly, yearly restore points).
Backup for Azure VMs:
Soft delete: When enabled, deleted backup data is retained for 14 additional days before permanent deletion. Protects against accidental or malicious deletion of backup data. Enabled by default on new vaults.
Backup Centre: A unified management experience for all backup across subscriptions and vaults from one place.
Azure Site Recovery is a disaster recovery (DR) service — it continuously replicates VMs from a primary location to a secondary and enables failover.
Supported scenarios:
Key concepts:
MS-102 is the core Microsoft 365 admin certification. This free guide covers all five domains — tenant management, identity, security, compliance, and Microsoft 365 apps. Written for real administrators, not just exam theory.
This domain covers everything at the tenant level — setting up a new tenant, managing subscriptions, configuring services, monitoring health, and deploying Microsoft 365 Apps. It's the administrative foundation everything else builds on.
Microsoft 365 tenant: A dedicated instance of Microsoft 365 services. Every organisation that subscribes gets a tenant with a unique .onmicrosoft.com domain. You add your own custom domains (verified via DNS TXT record).
Custom domains: Add your company domain (e.g. contoso.com) in the Microsoft 365 admin centre → Settings → Domains. Verify ownership by adding a TXT record to your public DNS. After verification, add DNS records for Exchange (MX, Autodiscover), Teams (SIP, lyncdiscover), and other services.
Organisational profile settings: Configure in admin centre → Settings → Org settings: organisation name, technical contact, release preferences (targeted release vs standard release — targeted release gives you new features 2–4 weeks early), password expiration policies.
Microsoft 365 Apps deployment:
Microsoft 365 admin centre roles: Key admin roles to know for the exam:
Service health dashboard: admin.microsoft.com → Health → Service health. Shows current status of all Microsoft 365 services (Exchange, Teams, SharePoint, etc.) — whether they're operating normally, have advisories, or are experiencing incidents. Subscribe to email notifications for services your organisation depends on.
Message centre: admin.microsoft.com → Health → Message centre. Microsoft posts planned changes, new features, and required actions here. Important: messages have action dates — if you miss an action by the deadline, your service may be affected. Filter by service, sort by urgency.
Microsoft 365 usage reports: admin.microsoft.com → Reports → Usage. Shows adoption data: active users per service, email volume, Teams meeting minutes, SharePoint storage used. Available for 7, 30, 90, and 180 day windows. User-level data can be anonymised for privacy compliance (GDPR).
Microsoft 365 Adoption Score: A score (0–800) measuring how effectively your organisation uses Microsoft 365 across people experiences (communication, meetings, content collaboration) and technology experiences (endpoint analytics, network connectivity, Microsoft 365 Apps health).
Support tickets: Raise service requests in the admin centre → Support → New service request. Microsoft provides 24/7 support for all paid subscriptions. Severity A (critical business impact) gets fastest response. You can also run diagnostic checks directly in the admin centre for many common issues.
Microsoft FastTrack is a free onboarding service for customers with 150+ eligible licences. A FastTrack engineer helps you plan and execute the deployment — not doing the work for you, but providing guidance, tools, and best practices.
Migration approaches for Exchange:
The largest domain. Identity is the foundation of Microsoft 365 security. Entra ID, hybrid identity, MFA, Conditional Access, and Privileged Identity Management are all heavily tested with scenario questions.
Microsoft Entra Connect (formerly Azure AD Connect) synchronises identities from on-premises Active Directory to Entra ID. It's the cornerstone of hybrid identity — enabling the same username and password to work for both on-premises and cloud services.
Authentication methods:
Entra Connect Health: Monitors the health of your Entra Connect infrastructure — sync errors, agent status, performance metrics. Available in the Entra admin centre under Monitoring → Entra Connect Health. Requires Entra ID P1.
Entra Connect Cloud Sync: A lighter alternative to Entra Connect for simpler scenarios. Runs as an agent on-premises (no sync server needed), configures from the cloud. Supports multi-forest topologies but fewer features than full Entra Connect. Good for organisations with a single forest and straightforward sync requirements.
Authentication methods available:
Authentication Methods policy (modern): Configure which methods are available to users in Entra admin centre → Protection → Authentication methods. The modern policy replaces the legacy per-user MFA settings and the legacy SSPR authentication methods policy.
MFA registration campaign: Nudge users who haven't registered for MFA to do so at sign-in time. Configure in Entra admin centre → Protection → Authentication methods → Registration campaign. Set a snooze limit (e.g. users can dismiss 3 times before forced to register).
Conditional Access evaluates every sign-in attempt and applies policies based on signals. For MS-102 you need to know not just what CA does, but how to configure specific policy scenarios.
Signal types (conditions):
Grant controls:
Session controls (restrict what happens after sign-in):
Access reviews (Entra ID P2) enable periodic reviews of group memberships, application assignments, and role assignments. A reviewer (manager, resource owner, or self-review) confirms whether access is still needed. Automated actions on review completion: remove access, require justification, send reminders.
Common use cases: quarterly review of all guest users, monthly review of Security Administrator role members, annual review of a sensitive SharePoint group.
Entitlement Management (Entra ID P2) provides self-service access request workflows for packages of resources (groups, apps, SharePoint sites). Users request access, approvers approve, access is granted with an expiry. Eliminates ad-hoc email requests for resource access.
Access packages bundle multiple resources together. Example: "Finance Team Access" package includes the Finance security group, the Finance SharePoint site, and a Power BI workspace. New finance employees request this one package instead of three separate requests.
Privileged Identity Management (PIM): Just-in-time activation for Entra ID roles and Azure RBAC roles. Eligible assignments require activation. Activation can require MFA, justification, approval, and is time-limited. Full coverage in the AZ-104 guide — same concepts apply here for M365 admin roles (Global Admin, Exchange Admin, etc.).
Microsoft Intune is the MDM/MAM platform used to manage devices accessing Microsoft 365. Full coverage in MS-102 because device compliance feeds directly into Conditional Access.
Device enrollment methods (Windows):
Compliance policies: Define what "compliant" means (BitLocker enabled, minimum OS version, no jailbreak, PIN required). Devices that don't meet the policy are marked non-compliant. Conditional Access can then block non-compliant devices from accessing Microsoft 365.
Configuration profiles: Push settings to devices — Wi-Fi, VPN, email, restrictions, certificates. Applied automatically when a device enrols and matches the profile's assignment (user group or device group).
App protection policies (MAM): Protect company data within specific apps on personal devices without enrolling the device. Prevent copy/paste from Outlook to personal apps, require PIN for Outlook, remotely wipe only company data when employee leaves.
Security is tested heavily in MS-102. Microsoft 365 Defender, Defender for Office 365, anti-spam, anti-malware, attack simulation, and security scores are all fair game. Know not just what each tool does but how to configure it.
The Microsoft 365 Defender portal (security.microsoft.com) is the unified security operations centre for Microsoft 365. It consolidates:
Exchange Online Protection is the baseline email filtering layer included with every Exchange Online licence. It protects against spam, malware, and bulk email.
Anti-spam policies: Configure in security.microsoft.com → Email & collaboration → Policies & rules → Anti-spam. Key settings:
Anti-malware policies: All attachments are scanned. Malware is blocked and quarantined. Configure notification settings (notify admin, not the recipient — notifying the sender teaches attackers that their malware was detected).
Quarantine: Messages filtered as spam, phishing, or malware go to quarantine. Admins can review and release quarantined messages. Users can manage their own spam quarantine (not phishing or malware). Configure quarantine policies to control what users can see and do with quarantined messages.
Plan 1 features (included in Microsoft 365 Business Premium, add-on for E3):
Plan 2 additional features (included in M365 E5, add-on for E3):
Defender for Identity (formerly Azure ATP) monitors on-premises Active Directory and Entra ID for identity-based attacks. It analyses Active Directory traffic and event logs to detect:
Requires a Defender for Identity sensor installed on domain controllers. The sensor monitors AD traffic passively — no agents on user workstations needed.
Alerts surface in the Microsoft 365 Defender portal (security.microsoft.com) alongside other Defender alerts, enabling correlated investigation across email, endpoint, and identity signals.
Defender for Cloud Apps is a Cloud Access Security Broker (CASB). It provides visibility and control over cloud app usage across your organisation.
Key capabilities:
Entra ID Protection (requires P2) analyses billions of sign-in signals to detect compromised accounts and risky sign-ins.
Risk types:
Risk policies:
Risky users and risky sign-ins are surfaced in the Entra admin centre → Protection → Risky users and Risky sign-ins. Admins can dismiss risk (if investigation shows false positive) or confirm compromise (marks user as compromised, triggers higher-risk classification).
Microsoft Purview compliance tools — information protection, DLP, retention, eDiscovery, and audit. Smaller domain but the questions are precise — know the difference between similar-sounding features.
Sensitivity labels classify and protect content. Labels can apply encryption, content markings (headers, footers, watermarks), and restrict what users can do with the content.
Label scope:
Auto-labelling policies: Automatically apply labels to content containing sensitive information types (credit card numbers, NHS numbers) — either as a recommendation ("This looks like sensitive content — apply label?") or automatically without user involvement. Server-side auto-labelling scans SharePoint and OneDrive at rest.
Encryption settings: When a label applies encryption, you configure who can decrypt (specific users, groups, or authenticated users), what they can do (view only, view and edit, full control), and whether offline access is permitted and for how long.
DLP policies detect and protect sensitive information across Exchange Online, SharePoint, OneDrive, Teams, and endpoint devices.
Sensitive information types (SITs): Pre-built patterns (regex + validation) for common sensitive data. Microsoft provides 200+ built-in SITs. You can create custom SITs using regex patterns, keyword lists, and confidence levels.
Trainable classifiers: Machine learning models that identify content by context, not just patterns. Built-in examples: Resume, Source Code, Tax, Financial Statements, Healthcare. Used when pattern-matching (regex) isn't sufficient — e.g. identifying internal project documents or customer communications.
DLP policy mode:
Endpoint DLP: Extends DLP to Windows 10/11 and macOS endpoints. Prevents sensitive data from being copied to USB drives, printed, uploaded to personal cloud apps, or shared via Bluetooth. Requires onboarding devices into Defender for Endpoint.
Retention policies (location-based) apply to all content in a scope: all Exchange mailboxes, all SharePoint sites, all Teams channels. Set once, forget.
Retention labels (item-level) are applied to individual items — either manually by users or automatically. Labels can declare content as a record (cannot be modified or deleted by users during the retention period) or a regulatory record (even admins cannot delete — for the most strict regulatory requirements).
Disposition review: When a retention label's retention period expires, instead of automatic deletion you can trigger a review. Reviewers are notified, examine the content, and decide: dispose (delete), relabel, or extend retention. Creates a full audit trail of the disposition decision.
Preservation Lock: When applied to a retention policy or label policy, it cannot be turned off, shortened, or deleted until the retention period expires. Required for FINRA, SEC 17a-4, and other regulations requiring immutable record retention. One-way action — cannot be reversed.
Content search — search across Exchange mailboxes, SharePoint sites, OneDrive, Teams chats, and Viva Engage for content matching keywords, date ranges, or senders. Export results to PST or as individual files.
eDiscovery (Standard) — includes content search plus the ability to place content on legal hold (preserves content even if a user deletes it) and export for legal review. Available in most M365 plans.
eDiscovery (Premium) — adds custodian management (track people involved in a case), near-duplicate detection, email threading (group related emails), attorney-client privilege detection, and smart tag suggestions. Requires E5 or E5 Compliance add-on.
Legal hold vs retention policy: Legal hold (in an eDiscovery case) preserves content for a specific legal matter — indefinitely, or until the hold is removed. Retention policies preserve content for a fixed period for compliance. Both can coexist — preservation lock from eDiscovery takes precedence.
Audit (Standard): Records user and admin activity across Microsoft 365 — sign-ins, file access, mailbox access, admin actions. Retained for 90 days. Search the audit log in compliance.microsoft.com → Audit.
Audit (Premium): Longer retention (up to 1 year, extendable to 10 years with add-on licence), high-value audit events (when email was read, not just received — MailItemsAccessed), higher bandwidth access to the API. Requires E5 or E5 Compliance.
Exchange Online administration, SharePoint and OneDrive management, Teams policies, and collaboration settings. These are the day-to-day admin tasks — practical hands-on knowledge is the best preparation here.
Mailbox types:
Mail flow rules (transport rules): Conditions + Actions applied to messages in transit. Common uses: add legal disclaimers, block external forwarding, add recipients to all outbound emails, apply sensitivity labels, route through compliance journal.
Accepted domains: Domains that Exchange Online will accept mail for. Three types: Authoritative (Exchange is the final destination), Internal relay (some recipients may be elsewhere — hybrid), External relay (Exchange relays to another mail system).
Email address policies: Define the email address format for users in your organisation (e.g. [email protected]). Applied automatically as users are created or updated.
Address lists and Global Address List (GAL): The GAL is the directory of all recipients visible in Outlook's address book. Address lists are subsets of the GAL (e.g. by department or location). Hidden from address list: mailboxes and groups with "Hide from Exchange address lists" checked — still receive email, just not visible in the GAL.
SharePoint admin centre (admin.microsoft.com → SharePoint):
SharePoint storage: Default 1TB + 10GB per licence. Can purchase additional storage. Shared across all site collections — no per-site quota by default (you can set one).
OneDrive admin settings: Configure default storage per user (1TB default, can set higher for E plans), sync client restrictions (only sync to domain-joined devices), retention of deleted accounts' OneDrive (default 30 days before permanent deletion — configurable up to 10 years).
Microsoft 365 Groups expiration: Set expiration period (e.g. 180 days). Group owners are emailed to renew. Unrenewed groups are soft-deleted. Restoreable for 30 days. Reduces SharePoint and Teams sprawl.
Teams admin centre (admin.teams.microsoft.com):
Teams policies (assigned to users or groups):
Teams Phone: Cloud-based PBX functionality. Requires Teams Phone licence. Options for PSTN connectivity: Microsoft Calling Plans (buy minutes from Microsoft), Operator Connect (use your telco's SIP trunks), Direct Routing (connect your own SBC to Teams).
Live events: Broadcast to up to 20,000 attendees (higher with Teams Premium). Requires producer, presenters, and attendees. One-way broadcast — attendees watch but don't interact directly.
Teams Rooms: Purpose-built meeting room devices (Surface Hub, Logitech Tap, Poly). Require Teams Rooms licence (Basic free for limited features, Pro for full features). Managed centrally from Teams Rooms Pro Management portal.
The confusion between Microsoft Entra ID and Active Directory Domain Services is one of the most common in the Microsoft ecosystem. They look similar on the surface — both are Microsoft identity systems, both manage users and groups — but underneath they are fundamentally different in almost every way that matters for your day-to-day administration.
Active Directory Domain Services (AD DS) is an on-premises identity system built in the Windows Server 2000 era to manage domain-joined Windows computers and network resources inside a corporate building. Microsoft Entra ID (formerly Azure Active Directory) is a cloud-based identity service built to manage access to web applications, SaaS services, and cloud resources — from any device, anywhere.
They are not the same product. Entra ID is not "Active Directory hosted in the cloud." You cannot simply lift and shift your AD DS to Azure and call it Entra ID. They use different protocols, have different objects, and solve different problems.
AD DS runs on domain controllers — Windows Server VMs or physical servers you own and manage, typically on-premises in your data centre or server room. Every Windows PC that joins the domain communicates with these domain controllers continuously. AD DS manages computers, printers, file shares, Group Policy Objects, and organisational units (OUs) — the traditional on-premises infrastructure of an enterprise IT department.
Entra ID runs entirely in Microsoft's cloud. There are no servers for you to manage, no domain controllers to patch. It manages users, groups, application registrations, and service principals — the identities needed to access Microsoft 365, Azure, Salesforce, GitHub, and thousands of other SaaS applications. It has no concept of Group Policy, OUs, or domain-joined computers in the traditional sense.
This is where the architectural difference becomes most visible. AD DS uses Kerberos and NTLM — authentication protocols from the 1980s and 1990s designed for closed corporate networks where every device is trusted and on the same LAN. When you log into a domain-joined Windows PC, Kerberos issues a ticket granting ticket (TGT) from the domain controller, and your PC uses that ticket to access file servers, printers, and applications on the internal network. This works beautifully inside the office. It falls apart the moment you work from a coffee shop.
Entra ID uses OAuth 2.0, OpenID Connect (OIDC), SAML 2.0, and WS-Federation — modern, internet-native protocols designed for applications accessed over HTTPS from anywhere. These protocols issue tokens (JSON Web Tokens) that carry claims about who you are and what you're allowed to do. Modern web applications, Microsoft 365, Azure, and virtually every SaaS app speaks these protocols natively. Your smartphone, Chromebook, and Mac can all authenticate to Entra ID just as easily as a Windows PC.
| Feature | AD DS (Active Directory) | Microsoft Entra ID |
|---|---|---|
| Where it runs | Your on-premises domain controllers | Microsoft's cloud (no servers to manage) |
| Authentication protocols | Kerberos, NTLM | OAuth 2.0, OIDC, SAML 2.0 |
| Organisational structure | OUs, GPOs, Sites | Groups, Administrative Units |
| Device management | Domain join + Group Policy | Entra join + Intune MDM |
| Primary query method | LDAP | Microsoft Graph API (REST/JSON) |
| Built-in MFA | No (requires RADIUS or AD FS) | Yes, native |
| Conditional Access | No | Yes (requires P1 licence) |
| Works on personal devices | Limited (requires VPN or hybrid join) | Yes, fully supported |
| SaaS app sign-on (SSO) | Only via AD FS federation | Native SSO to 3,000+ apps |
In AD DS, you organise objects into Organisational Units (OUs) — folders in a hierarchy. You apply Group Policy Objects (GPOs) to OUs to enforce settings across all computers and users in that OU. Want to block USB drives on all computers in the Finance OU? Link a GPO. Want to push a printer to everyone in the London site? GPO. It's powerful and battle-tested for managing on-premises Windows environments.
Entra ID has no OUs and no GPOs. Instead, you manage settings through Intune configuration profiles (for device settings) and Entra ID security groups (for access control). Groups can be assigned dynamically — if a user's department attribute changes to "Finance," they're automatically added to the Finance group and inherit everything assigned to it. There's no hierarchy, but there's considerably more flexibility.
Most organisations don't choose one or the other — they run both, connected via Microsoft Entra Connect (formerly Azure AD Connect). This sync tool runs on a Windows Server on-premises and continuously copies user accounts, groups, and (optionally) password hashes from AD DS to Entra ID.
The result: your users have one identity. They use the same username and password for their on-premises Windows logon (Kerberos, domain controller) and their Microsoft 365 sign-in (OAuth 2.0, Entra ID). HR creates a user in AD — Entra Connect syncs them to the cloud within 30 minutes, and their Microsoft 365 licence is ready.
Device joining is where the two systems interact most confusingly for new administrators.
If you're starting a new organisation from scratch today, the answer is almost certainly Entra ID only, with Intune for device management and no on-premises AD at all. Microsoft 365 works natively with Entra ID. You get Conditional Access, MFA, passwordless authentication, and Intune out of the box without a single server in your office.
If you have an existing on-premises infrastructure — file servers, on-premises applications, legacy software that requires Kerberos — you'll run a hybrid model for the foreseeable future. AD DS manages on-premises resources. Entra ID handles cloud access. Entra Connect keeps them in sync. This is where most medium and large enterprises are today.
The long-term direction is clear: Microsoft is investing heavily in Entra ID, passwordless authentication, and cloud-native identity. AD DS is in maintenance mode. The migration path is long for large enterprises, but the destination is a world where Entra ID is the only identity system you need.
Retention policies are your compliance safety net — keeping what regulators require you to keep, and automatically disposing of what you shouldn't hold onto. This step-by-step guide walks through creating, testing, and managing retention policies in Microsoft Purview for Exchange Online email.
Before touching the portal, it's worth understanding what Exchange Online retention policies actually do to your data — because it's not what most people expect.
When a retention policy is applied to an Exchange mailbox, Microsoft 365 creates (or uses an existing) hidden folder in the mailbox called the Preservation Hold Library. When a user deletes an email, the message doesn't disappear — a copy is silently moved to this hidden folder where it stays for the retention period. Users can't see it, can't access it, and don't know it's there. But compliance administrators can find it via eDiscovery, and it counts toward mailbox size.
This means: users can delete email freely, the inbox stays clean, but nothing that falls under a retention policy is ever truly gone until the retention period expires.
All retention configuration happens in the Microsoft Purview compliance portal at compliance.microsoft.com. Navigate to: Data lifecycle management → Microsoft 365 → Retention policies.
You'll need the Compliance Administrator or Records Management role in Purview. The Exchange Administrator role is not sufficient — retention is a compliance function, not an Exchange admin function.
Click New retention policy and work through the wizard:
Use a descriptive name that captures what the policy does: Exchange-Retain-7yr-Then-Delete or Finance-Email-7y. You'll thank yourself later when you have 15 policies and need to audit them.
For most organisations, start with Static.
Select Exchange mailboxes. You can then choose:
Other available locations you can add to the same policy: SharePoint sites, OneDrive accounts, Teams channel messages, Teams chats, Viva Engage messages. A single policy can cover multiple locations.
This is the core of the policy. Configure:
| Option | What happens | Use when |
|---|---|---|
| Delete items automatically | Items are permanently deleted after the retention period | You need automatic disposal (most compliance scenarios) |
| Trigger a disposition review | Reviewers are notified to manually approve deletion | High-value records needing human sign-off before deletion |
| Do nothing (retain only) | Items are kept but never automatically deleted | You only need a minimum keep — no max retention |
After creating the policy, don't enable it immediately. Use the policy status toggle to leave it in monitoring mode first. In monitoring mode, the policy evaluates content and logs what it would have done — but makes no changes.
Review the results in Data lifecycle management → Disposition and the Compliance Manager activity explorer. Check for unexpected scope (are you capturing mailboxes you didn't intend to?) and estimate the volume of content affected.
When you're satisfied, toggle the policy to On. Propagation to all mailboxes in a large tenant takes up to 7 days. The policy status shows "Pending" during propagation and "On" when fully applied. Don't assume it's active until the status shows On.
Retention policies apply automatically based on location — all emails in all mailboxes, or all files on all SharePoint sites. They're blunt but powerful. Use them for tenant-wide baseline retention.
Retention labels are applied to individual items — either manually by users or automatically based on content. They're surgical. Use labels when you need item-level control: a specific contract that must be kept for 10 years, or emails with "board minutes" in the subject that need special handling.
Labels can also declare content as a record — preventing users from modifying or deleting the item during the retention period. This is the right tool for formal records management where you need an immutable audit trail.
Check your policies regularly in the Purview portal. The Data lifecycle management → Overview dashboard shows policy health and any errors. Common issues:
Role-Based Access Control is how Azure decides who can do what to which resources. Getting it right is the difference between a secure, auditable cloud environment and one where every developer is accidentally a Subscription Owner. This guide explains how RBAC works and how to design a model that actually scales.
Every RBAC decision in Azure comes down to three components combined into a single role assignment:
Actions) are allowed and which are explicitly blocked (NotActions).When a request hits Azure Resource Manager, it evaluates: does any role assignment for this principal (or any group they're a member of) at this scope (or any parent scope) grant permission for this action? If yes — allowed. If no — denied. RBAC is additive: permissions accumulate across all role assignments. There's no inheritance of denial except for explicit deny assignments (which are rare and only created by Azure itself for managed apps and blueprints).
Scope is hierarchical: Management Group → Subscription → Resource Group → Resource. A role assigned at a higher scope is automatically inherited by all child scopes.
Assign someone as Reader at the subscription level — they can read every resource group and every resource in that subscription. Assign them as Contributor at a specific resource group — they can create and manage resources only within that group. The subscription-level Reader assignment doesn't give them Contributor elsewhere.
Azure has over 170 built-in roles, but four apply at every scope and cover the vast majority of use cases:
| Role | Read | Create/modify | Delete | Grant access | Use for |
|---|---|---|---|---|---|
| Owner | ✓ | ✓ | ✓ | ✓ | Platform engineers, subscription administrators |
| Contributor | ✓ | ✓ | ✓ | ✗ | Developers, DevOps engineers managing a resource group |
| Reader | ✓ | ✗ | ✗ | ✗ | Auditors, monitoring teams, new joiners |
| User Access Administrator | ✓ | ✗ | ✗ | ✓ | Teams responsible for access management without resource management |
The critical distinction: Owner can grant access, Contributor cannot. This matters enormously. A Contributor who can't assign roles cannot elevate their own privileges or give access to others. An Owner with a compromised account can hand Owner to an attacker.
Using Contributor as a default is a common mistake. Azure provides service-specific roles that limit permissions to exactly what's needed. Using them reduces the blast radius of any compromised identity:
One of the most important RBAC patterns is using managed identities for applications instead of service principals with stored secrets. A managed identity is an Entra ID identity automatically created for an Azure resource (a VM, an App Service, an Azure Function, etc.) and managed entirely by Azure.
The application never sees a client secret or certificate. It requests a token from the Instance Metadata Service (a local endpoint only accessible from within Azure) and uses that token to call Azure APIs. Azure rotates the underlying credentials automatically. There is nothing to leak, nothing to rotate manually, and nothing to accidentally check into a code repository.
The pattern: create a managed identity on your resource → assign it the minimum necessary RBAC role at the minimum necessary scope → done. Your application calls Azure APIs as that identity without any stored credentials.
Never assign roles to individual users if you can avoid it. Assign them to Entra ID security groups instead. When someone joins the team, add them to the group — they inherit all the group's role assignments immediately. When they leave, remove them from the group — access is revoked everywhere the group had assignments instantly.
This becomes especially important in large organisations where a developer might have access to 20 resource groups across 5 subscriptions. Managing that as individual role assignments means 20 changes when they leave. As a group member? One group removal, all access gone.
When no built-in role fits exactly, you can create a custom role. Define it as a JSON document specifying allowed actions, excluded actions, and assignable scopes:
{
"Name": "VM Restart Operator",
"Description": "Can view and restart VMs only",
"Actions": [
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Resources/subscriptions/resourceGroups/read"
],
"NotActions": [],
"AssignableScopes": [
"/subscriptions/your-subscription-id"
]
}
Custom roles have a limit of 5,000 per Entra ID tenant. More importantly, they carry maintenance overhead — you must keep them updated when Azure adds new actions to services. Use built-in roles wherever possible. Create custom roles only for genuinely unique access patterns.
A practical framework for any new Azure environment:
Review role assignments quarterly. Azure Advisor flags resources with excessive permissions. Use Entra ID Access Reviews to automate the review cycle — set it up once and get quarterly reminders to confirm who still needs what.
Without governance, a Microsoft Teams environment becomes unmanageable within months — hundreds of duplicated teams, abandoned projects, and teams with names like "New Team (2) - FINAL v3 USE THIS". This guide shows you how to put the right controls in place from the start, or get an existing environment back under control.
When Microsoft 365 is first deployed, creating a Team takes three clicks. That's intentional — Microsoft wants adoption. But every Team creates a Microsoft 365 Group, which creates a SharePoint site, a shared mailbox, a Planner board, and a OneNote notebook. Multiply that by 500 employees and two years of project work, and you have thousands of orphaned resources, no naming convention, and no idea what any of it is for.
Governance doesn't mean locking everything down. It means having answers to: Who is responsible for each Team? How long does it live? Who can invite external guests? What should it be called? Get those answers into policy before Teams sprawl becomes a support burden.
By default, any licensed user can create a Microsoft 365 Group — and therefore a Team. To restrict this, you use an Entra ID setting that limits group creation to members of a specific security group.
How to configure it:
SG-Teams-CreatorsNaming policies enforce consistent Team names across the tenant. Configure them in Entra admin centre → Groups → Naming policy. There are two mechanisms:
Automatically prepend or append text to every new group name. You can use fixed strings or user attributes (Department, Country, Office). Examples:
GRP-[GroupName] — prefix all groups with GRP- to distinguish them from other objects in the directory[GroupName]-[Department] — append the creator's department: "Marketing-Budget 2026"[Country]-[GroupName] — prefix with country code for multinational orgs: "UK-Payroll Team"The preview in the portal shows exactly how the name will appear. Prefixes and suffixes apply automatically — the user only types the middle part.
A list of words that cannot appear in group names. Case-insensitive. Use for: profanity, words that might reveal confidential projects before announcement (acquisition codenames, product launch names), or generic terms so vague they're useless (team, group, test).
Group expiration policies automatically soft-delete inactive Microsoft 365 Groups (and their Teams) after a defined period. This is one of the most effective ways to reduce sprawl over time — Teams that nobody renews are cleaned up automatically.
How it works:
Guest access allows external users (with their own Microsoft or work accounts) to be added to Teams. It's essential for collaboration with clients, partners, and contractors — but needs the right guardrails.
In Teams admin centre → Org-wide settings → Guest access, you control:
In Entra admin centre → External Identities → External collaboration settings:
The most important guest governance control that most organisations skip: Entra ID Access Reviews. Set up a quarterly review of all guest users in Teams. Reviewers (typically Team owners) confirm each guest still needs access. Guests not confirmed are automatically removed. Requires Entra ID P2.
Without access reviews, guests accumulate. A contractor who left 18 months ago still has access to your Teams channels because nobody remembered to remove them.
Beyond governance at the group level, Teams admin centre lets you create policies assigned to users or groups. Key policies to configure early:
Azure bills for exactly what you use — every VM hour, every GB stored, every GB egressed. Without visibility into where that spend goes, costs grow silently until someone in finance asks questions you can't answer. Here's how to get in front of it.
Azure Cost Management + Billing is built into the Azure portal at no extra charge. Search "Cost Management" in the portal search bar. You can access it at three scopes — each gives a different view of spending:
The Cost Analysis view (left menu within Cost Management) is where you spend most of your time. The default view shows spending for the current billing period as a bar chart by day.
The most useful view to start with: change the grouping to Service name. This immediately tells you whether your biggest cost is compute (Virtual Machines), storage, networking, databases, or something else. You can't fix what you can't see.
Once you know the dominant service, drill down. If compute is 70% of your bill, group by Resource to see which specific VMs are the most expensive. Click any bar in the chart to filter to that time period. Use the Add filter button to narrow to a specific resource group, location, or tag.
If your team has implemented resource tagging (Environment, CostCentre, Project, Owner), the tag view turns Cost Management into a proper cost allocation tool. You can show finance: "the Production environment cost £12,400 this month, Development cost £3,200, and the Q1-ERP-Project tag accounts for £4,800 of that." Without tags, all you have is a list of cryptic resource names.
If tags aren't in place yet, this is the moment to prioritise them. Use Azure Policy with the Append or Modify effect to enforce required tags on all new resources.
Budgets let you define a spending limit and get notified when you're approaching or exceeding it. Navigate to Cost Management → Budgets → + Add.
Configure the budget:
Configure alert conditions — use all three:
For each alert, specify email recipients. You can also trigger an Action Group — which can send to Teams via webhook, run a Logic App, or even call an Azure Function to take automated remediation action (like scaling down a VM).
Most unexpected Azure bills come from a handful of repeatable patterns. Know these and you'll catch 80% of waste before it compounds:
Shutting down a VM from within the operating system (Start → Shut down) does not stop Azure billing. The VM is "stopped" but not "deallocated" — the underlying hardware is still reserved for you. You must use the Stop button in the Azure portal, which shows "Stopped (deallocated)" to stop compute charges. The managed disk still costs money when deallocated, but the VM compute stops.
When a VM is deleted, its attached managed disks and network interfaces are not automatically deleted — they're detached and left behind. They accumulate silently and cost money indefinitely. In Cost Analysis, filter by resource type Microsoft.Compute/disks and look for disks with no associated VM. In the Azure portal, go to Disks and filter by "Unattached."
A D4s_v3 VM running continuously costs roughly £250/month. If your development team only uses it during working hours (8 hours/day, 5 days/week), that's about 24% utilisation — you're wasting £190/month per VM. Use auto-shutdown schedules (available under each VM's settings in the portal) to shut down dev VMs at 7pm and optionally start them at 8am.
Azure Advisor (free, built-in) analyses your VM CPU and memory utilisation over 7 days and flags VMs consistently below 5% CPU utilisation as candidates for downsizing. Navigate to Advisor → Cost and work through the recommendations. Each one shows an estimated annual saving. A D4s_v3 running at 3% CPU average should probably be a D2s_v3 — half the cost.
Static public IP addresses cost around £3–5/month each. An Application Gateway with no backend pool still costs its hourly rate. An empty Standard Load Balancer with no rules still has a fixed monthly cost. Filter your resource list for these resource types and check for any that aren't attached to anything.
Azure Advisor monitors your configuration and surfaces personalised recommendations across five pillars: Cost, Reliability, Security, Operational Excellence, and Performance. For cost, it surfaces:
Advisor shows an estimated annual saving for each recommendation. Work through Cost recommendations monthly. High-confidence, high-savings ones take minutes to implement and can save thousands per year.
For resources you know you'll run for 1 or 3 years — production VMs, Azure SQL, App Service plans — Azure Reservations let you commit upfront and save significantly:
Reservations apply to your running resources automatically — you don't need to do anything to the resource itself, just buy the reservation for the right VM size and region. The discount is applied at billing time.
The Microsoft 365 admin centre is powerful, but it reaches its limits quickly when you need to manage hundreds of users, generate bulk reports, or automate repetitive tasks. PowerShell is where Microsoft 365 administration actually scales — and these are the commands that will save you hours every week.
Microsoft 365 PowerShell management is split across several modules. Install them once from an elevated PowerShell session (Run as Administrator):
# Microsoft Graph — the modern, unified API (replaces MSOnline and AzureAD modules)
Install-Module Microsoft.Graph -Scope CurrentUser -Force
# Exchange Online Management — for mailbox and mail flow administration
Install-Module ExchangeOnlineManagement -Scope CurrentUser -Force
# Microsoft Teams — for Teams administration
Install-Module MicrosoftTeams -Scope CurrentUser -Force
# SharePoint Online Management Shell
Install-Module Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser -Force
MSOL) and AzureAD modules are deprecated and will be retired. All new scripts should use Microsoft.Graph. If you have existing scripts using Get-MsolUser or Get-AzureADUser, plan to migrate them to Get-MgUser.Each module has its own connection command. You need to connect before running any commands:
# Connect to Microsoft Graph
# The -Scopes parameter requests the permissions you need
Connect-MgGraph -Scopes "User.ReadWrite.All","Group.ReadWrite.All","Directory.ReadWrite.All"
# Connect to Exchange Online (prompts for MFA automatically)
Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com
# Connect to Microsoft Teams
Connect-MicrosoftTeams
# Connect to SharePoint Online (replace yourdomain with your tenant name)
Connect-SPOService -Url https://yourdomain-admin.sharepoint.com
When automating (no interactive sign-in), use a service principal with certificate authentication or a managed identity rather than storing credentials in scripts. For interactive admin sessions, MFA prompts are fine.
# Get a single user — essential starting point
Get-MgUser -UserId "jane.smith@company.com"
# Get all users (including unlicensed)
Get-MgUser -All
# Get all LICENSED users only
Get-MgUser -Filter "assignedLicenses/`$count ne 0" `
-ConsistencyLevel eventual -Count userCount -All
# Export all users to CSV — the most common admin report
Get-MgUser -All `
-Select "DisplayName,UserPrincipalName,Department,JobTitle,AccountEnabled,Mail" |
Export-Csv -Path "C:\Reports\AllUsers.csv" -NoTypeInformation
# Find users who haven't signed in recently (last 90 days)
$cutoff = (Get-Date).AddDays(-90).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgUser -Filter "signInActivity/lastSignInDateTime le $cutoff" `
-Select "DisplayName,UserPrincipalName,signInActivity" `
-ConsistencyLevel eventual -All
# Disable a user account (leaver process step 1)
Update-MgUser -UserId "jane.smith@company.com" -AccountEnabled $false
# Enable a user account
Update-MgUser -UserId "jane.smith@company.com" -AccountEnabled $true
# Update a user's department (useful for dynamic group triggers)
Update-MgUser -UserId "jane.smith@company.com" -Department "Finance"
# Bulk disable users from a CSV list
Import-Csv "C:\leavers.csv" | ForEach-Object {
Update-MgUser -UserId $_.UserPrincipalName -AccountEnabled $false
Write-Host "Disabled: $($_.UserPrincipalName)"
}
# Get all groups
Get-MgGroup -All
# Get members of a specific group
Get-MgGroupMember -GroupId "group-object-id-here" -All |
ForEach-Object { Get-MgUser -UserId $_.Id } |
Select-Object DisplayName, UserPrincipalName
# Add a user to a group
New-MgGroupMember -GroupId "group-object-id" `
-DirectoryObjectId "user-object-id"
# Remove a user from a group
Remove-MgGroupMemberByRef -GroupId "group-object-id" `
-DirectoryObjectId "user-object-id"
# Find groups a user is a member of
Get-MgUserMemberOf -UserId "jane.smith@company.com" |
Where-Object { $_.AdditionalProperties["@odata.type"] -eq "#microsoft.graph.group" } |
ForEach-Object { Get-MgGroup -GroupId $_.Id } |
Select-Object DisplayName, GroupTypes
# Get all mailboxes
Get-Mailbox -ResultSize Unlimited
# Get mailbox size for all users — run this before licence renewals
Get-Mailbox -ResultSize Unlimited |
Get-MailboxStatistics |
Select-Object DisplayName,
@{N="SizeGB";E={[math]::Round($_.TotalItemSize.Value.ToBytes()/1GB,2)}},
ItemCount |
Sort-Object SizeGB -Descending |
Export-Csv "C:\Reports\MailboxSizes.csv" -NoTypeInformation
# Check who has access to a shared mailbox
Get-MailboxPermission -Identity "helpdesk@company.com" |
Where-Object { $_.IsInherited -eq $false -and $_.User -ne "NT AUTHORITY\SELF" }
# Add full access to a shared mailbox (with auto-mapping so it appears in Outlook)
Add-MailboxPermission -Identity "helpdesk@company.com" `
-User "jane.smith@company.com" `
-AccessRights FullAccess `
-AutoMapping $true
# Grant Send As permission on a shared mailbox
Add-RecipientPermission -Identity "helpdesk@company.com" `
-Trustee "jane.smith@company.com" `
-AccessRights SendAs
# Get all mail flow (transport) rules — useful for auditing
Get-TransportRule | Select-Object Name, State, Priority, Description |
Format-Table -AutoSize
# Search for a specific message in message trace (last 48 hours)
Get-MessageTrace -SenderAddress "external@partner.com" `
-StartDate (Get-Date).AddHours(-48) `
-EndDate (Get-Date) |
Select-Object Received, SenderAddress, RecipientAddress, Subject, Status
# Enable archive mailbox for a user
Enable-Mailbox -Identity "jane.smith@company.com" -Archive
# Enable Litigation Hold (preserves all mailbox content for legal)
Set-Mailbox -Identity "jane.smith@company.com" `
-LitigationHoldEnabled $true `
-LitigationHoldDuration 2555 # 7 years in days
# Get all Teams in the tenant
Get-Team
# Get all Teams with guest users (useful for guest access audits)
Get-Team | ForEach-Object {
$guests = Get-TeamUser -GroupId $_.GroupId |
Where-Object { $_.Role -eq "Guest" }
if ($guests.Count -gt 0) {
[PSCustomObject]@{
TeamName = $_.DisplayName
GuestCount = $guests.Count
Guests = ($guests.User -join "; ")
}
}
} | Export-Csv "C:\Reports\TeamsWithGuests.csv" -NoTypeInformation
# Get all Teams with no activity (no messages in 90 days) — identify stale Teams
# Note: Requires Teams activity report data from Graph
Get-Team | Where-Object { $_.Archived -eq $false } |
Select-Object DisplayName, GroupId
# Create a new private Team with specific owners
$team = New-Team -DisplayName "Project Falcon" `
-Description "Q2 2026 product launch" `
-Visibility Private
Add-TeamUser -GroupId $team.GroupId -User "owner@company.com" -Role Owner
# Archive a stale Team (makes it read-only, preserves all data)
Set-TeamArchivedState -GroupId "team-group-id" -Archived $true
# Get all licence SKUs and available counts
Get-MgSubscribedSku | Select-Object SkuPartNumber,
@{N="Assigned";E={$_.ConsumedUnits}},
@{N="Total";E={$_.PrepaidUnits.Enabled}},
@{N="Available";E={$_.PrepaidUnits.Enabled - $_.ConsumedUnits}} |
Sort-Object SkuPartNumber
# Find all unlicensed user accounts (potential cleanup targets)
Get-MgUser -Filter "assignedLicenses/`$count eq 0" `
-ConsistencyLevel eventual -Count userCount -All |
Select-Object DisplayName, UserPrincipalName, CreatedDateTime |
Where-Object { $_.CreatedDateTime -lt (Get-Date).AddDays(-30) }
# Assign a licence to a user (get SkuId from Get-MgSubscribedSku)
Set-MgUserLicense -UserId "jane.smith@company.com" `
-AddLicenses @{SkuId = "licence-sku-id-here"} `
-RemoveLicenses @()
# Remove a licence from a user (leaver process)
Set-MgUserLicense -UserId "jane.smith@company.com" `
-AddLicenses @() `
-RemoveLicenses @("licence-sku-id-here")
One of the most common admin automation needs — handling employee offboarding consistently every time:
# Leaver-Process.ps1
# Run when an employee leaves. Requires Exchange Online and Graph connections.
param([Parameter(Mandatory)][string]$UserUPN)
Write-Host "Processing leaver: $UserUPN" -ForegroundColor Yellow
# 1. Disable the Entra ID account
Update-MgUser -UserId $UserUPN -AccountEnabled $false
Write-Host "✓ Account disabled"
# 2. Revoke all active sessions (sign out everywhere)
Revoke-MgUserSignInSession -UserId $UserUPN
Write-Host "✓ Sessions revoked"
# 3. Reset password to something random (prevents any cached auth)
$newPwd = [System.Web.Security.Membership]::GeneratePassword(20, 5)
Update-MgUser -UserId $UserUPN -PasswordProfile @{
Password = $newPwd
ForceChangePasswordNextSignIn = $false
}
Write-Host "✓ Password reset"
# 4. Remove from all groups
$groups = Get-MgUserMemberOf -UserId $UserUPN -All
foreach ($g in $groups) {
try {
Remove-MgGroupMemberByRef -GroupId $g.Id -DirectoryObjectId `
(Get-MgUser -UserId $UserUPN).Id
} catch { }
}
Write-Host "✓ Removed from $($groups.Count) groups"
# 5. Convert mailbox to shared (preserves email, removes licence need)
Set-Mailbox -Identity $UserUPN -Type Shared
Write-Host "✓ Mailbox converted to shared"
# 6. Set out-of-office auto-reply
Set-MailboxAutoReplyConfiguration -Identity $UserUPN `
-AutoReplyState Enabled `
-InternalMessage "Jane has left the company. Please contact manager@company.com." `
-ExternalMessage "Jane has left the company. Please contact manager@company.com."
Write-Host "✓ Out-of-office set"
Write-Host "Leaver process complete for $UserUPN" -ForegroundColor Green
-WhatIf which shows what would happen without making any changes. Before running bulk operations, pipe to Select-Object -First 5 to preview the first five results. One accidental bulk change to the wrong scope can ruin your morning.