100+ Hands‑On Intune MD‑102 Labs and Tips for Endpoint Administrators (2025 Guide)


Lab 23 – Deploy a Microsoft Store app and manage updates

Goal: Add a Store app (new Store experience), deploy it, and confirm Intune handles updates.

  1. Add a Microsoft Store app.
    • In Intune, go to Apps → All apps → Add.
    • App type: Microsoft Store app (new) (wording may vary slightly).
    • Click Search the Microsoft Store app (new) and find a lightweight app (e.g., “Company Portal” or another free app).learn.microsoft
  2. Configure app details.
    • Select the app; Intune fills most fields automatically.
    • Review Assignments later; for now, just create the app to bring it into Intune.learn.microsoft
  3. Assign the app as Required to a Windows group.
    • After creation, open the app → Assignments.
    • Under Required, select a device/user group that includes your Windows 11 test machine.
    • Save.learn.microsoft
  4. Sync the device and verify install.
    • On the Windows device, trigger a sync from Access work or school → Info → Sync.
    • After a few minutes, confirm the app appears in Start → All apps and in Settings → Apps → Installed apps.learn.microsoft
  5. Confirm update behavior.
    • Store apps deployed via Intune are updated automatically through the Store infrastructure; you don’t manually patch them.
    • You can check the app’s version later in Installed apps to see if it moves to a newer version without you redeploying it.certlibrary+1

Lab 24 – Deploy a simple LOB MSI app and supersede it with a new version

Goal: Use the line‑of‑business app type for MSI, then replace it with a newer MSI using supersedence (if available) or upgrade logic.

  1. Add the initial MSI as a line‑of‑business app.
    • In Intune: Apps → All apps → Add → Line‑of‑business app.
    • Upload an MSI with version 1.x (you can re‑package a simple installer or reuse Notepad++ MSI as “v1”).
    • Fill in Name, Publisher, etc. and create the app.learn.microsoft
  2. Assign v1 as Required.
    • Open the LOB app → Assignments → Required.
    • Target your Windows test group.
    • Sync the device and confirm v1 installs (check Programs and Features / Installed apps).learn.microsoft
  3. Add v2 of the app.
    • Build or obtain a v2 MSI with a higher ProductVersion.
    • Add another Line‑of‑business app for v2.
    • In properties, configure Supersedence (if supported in your tenant for LOB) to supersede v1, or else just assign v2 as Required and unassign v1.certlibrary+1
  4. Assign v2 and verify upgrade.
    • Assign v2 to the same group as Required.
    • Optionally remove v1 from Required or mark it as superseded/uninstalled.
    • After sync, confirm:
      • v2 version appears in Installed apps.
      • v1 no longer appears (depending on your uninstall logic).learn.microsoft

Lab 25 – Use Proactive Remediation (Remediation scripts) for a simple fix

Goal: Create a detection + remediation script pair to fix a small configuration issue (e.g., a registry value).

  1. Open the Remediations area.
    • In Intune: Devices → Remediations (or Devices → Windows → Remediations, depending on UI).systemcenterdudes+1
  2. Create a new remediation script package.
    • Click Create script package.
    • Name: Fix-SampleRegistrySetting.
    • Description: something like “Ensure a specific registry value is set”.velessoftware+1
  3. Prepare a detection script.
    • Create a PowerShell detection script locally, for example:
      • Check if HKLM:\Software\Contoso\Config has ValueX set to 1.
      • Exit 0 if compliant, 1 if not.
    • Save as Detect-ValueX.ps1.systemcenterdudes
  4. Prepare a remediation script.
    • Create a remediation script Fix-ValueX.ps1 that:
      • Creates the key if missing.
      • Sets ValueX to 1.
    • Save it.velessoftware+1
  5. Upload scripts to the remediation package.
    • In the Intune remediation wizard:
      • Browse and upload the detection script.
      • Browse and upload the remediation script.
    • Review additional options (run frequency, run in 64‑bit, etc.) and leave reasonable defaults for the lab.systemcenterdudes
  6. Assign the remediation package.
    • For Assignments, target your Windows test group.
    • Set a schedule (e.g., every 1 hour) for ongoing enforcement.velessoftware+1
  7. Test on the client.
    • On the test device, manually break the setting (delete the key or set ValueX to 0).
    • Wait for the schedule or force Intune Management Extension to check by syncing.
    • Confirm:
      • The detection script identifies non‑compliance and triggers remediation.
      • The registry value is corrected to 1 after remediation.youtube​systemcenterdudes

Lab 26 – Trigger a remediation script on demand for multiple devices (PowerShell helper)

Goal: Use a helper script (outside the portal) to call a remediation script package on specific devices, simulating targeted fixes.

  1. Identify an existing remediation script package.
    • In Intune portal: Devices → Remediations.
    • Open one of your packages (like Fix-SampleRegistrySetting).
    • Note the Script ID from the URL or properties (often visible as a GUID in the URL).youtube​systemcenterdudes
  2. Prepare a list of devices.
    • Create a text file (e.g., devices.txt) with one hostname or device ID per line for your target devices.youtube​
  3. Use a sample PowerShell script from GitHub.
    • Find a script that triggers on‑demand remediations using Graph (for example, from the referenced GitHub repos in the training video).github​youtube​
    • Update the script with:
      • Your tenant ID and app registration details (if required).
      • The remediation script package ID.
      • A loop reading devices.txt to trigger the remediation for each device.youtube​
  4. Run the PowerShell helper.
    • From a management workstation with appropriate permissions, run the script.
    • Verify in Intune:
      • The remediation package shows recent runs on the specified devices.
      • The underlying issue is corrected on those devices.github​youtube​

Lab 27 – Enable Windows Autopatch and assign a test ring

Goal: Turn on Windows Autopatch and place your lab device into a test ring so OS and app patching are automated.

  1. Check Windows Autopatch eligibility.
    • Confirm your tenant has eligible licenses (e.g., Business Premium or E3/E5, depending on current rules).intunestuff+1
    • Device must be Intune‑managed and Entra joined (no domain‑only devices).learn.microsoft
  2. Enable Windows Autopatch.
    • In Intune: Tenant administration → Windows Autopatch.
    • Click Feature activation.
    • Accept the terms and click Activate.intunestuff+1
  3. Create or identify an Autopatch registration group.
    • Follow the guidance in the Autopatch overview to create a group that will act as the registration source (e.g., Autopatch-Registration).
    • Make it a dynamic or static device group containing your test device.intunestuff
  4. Register the device with Autopatch.
    • Add your Windows 11 lab device to the Autopatch-Registration group.
    • In Autopatch, use the Autopatch devices view to confirm the device is discovered and registered into rings (like Test, First, Fast, Broad).learn.microsoft+1
  5. Verify ring assignment.
    • In the Autopatch UI, check which ring your device falls into (e.g., Test).
    • Rings control when your device receives updates relative to others.sonnes+1
  6. Monitor compliance and updates.
    • Use Devices → Windows updates → Autopatch devices / Reports to see:
      • Update status.
      • Compliance/patch level.
    • On the test machine, check Windows Update to confirm settings are being managed by Autopatch and updates are being offered on the schedule defined by the ring.sonnes+1

Here’s another set of concise labs, this time on advanced app scenarios and cross‑platform compliance + CA.learn.microsoft+1


Lab 28 – Win32 app with dependency chain

Goal: Deploy App B that depends on App A, and make Intune install them in the right order.

  1. Package two Win32 apps.
    • Use IntuneWinAppUtil to package:
      • AppA.intunewin (e.g., .NET Desktop Runtime or a helper tool).
      • AppB.intunewin (main app that needs App A).learn.microsoft
  2. Create App A in Intune.
    • Apps → All apps → Add → Windows app (Win32).
    • Upload AppA.intunewin.
    • Configure install/detection like your earlier Win32 lab.
    • Save (no assignments yet).learn.microsoft
  3. Create App B in Intune.
    • Add another Win32 app with AppB.intunewin.
    • Configure install and detection.
  4. Configure dependency on App A.
    • In App B, go to Dependencies.
    • Click Add, select App A, and choose Auto install.
    • Save.learn.microsoft
  5. Assign App B as Required.
    • In App B → Assignments, set Required for your test device group.
    • Do not assign App A directly.learn.microsoft
  6. Verify install order.
    • On the device, sync and wait.
    • Intune should:
      • Install App A first.
      • Then install App B.
    • In App → Device install status, confirm both show Installed, and check IME logs if you want to see the dependency chain.learn.microsoft

Lab 29 – Win32 app uninstall and cleanup

Goal: Use Intune to uninstall an app on demand and verify it’s removed.

  1. Pick an existing Win32 app.
    • Use your previous Win32 lab app (e.g., Notepad++).
  2. Confirm uninstall command.
    • Edit the app in Intune, ensure the Uninstall command is correctly set (e.g., msiexec /x "{ProductCode}" /qn or vendor uninstall EXE).learn.microsoft
  3. Create an “Uninstall” assignment.
    • In the app → Assignments, add a group under Uninstall.
    • For the lab, create a group containing just your test device, and assign that group here.
    • Save.learn.microsoft
  4. Sync and validate removal.
    • Sync the device.
    • After some time, confirm:
      • The app disappears from Installed apps / Programs and Features.
      • The app folder is removed from Program Files (if expected).
    • In Intune, the app’s Device install status should show Uninstalled for that device.learn.microsoft

Lab 30 – Cross‑platform compliance: Windows + iOS + Android

Goal: Build a minimal, consistent compliance baseline across all three platforms.

  1. Create a Windows compliance policy.
    • Devices → Compliance policies → Policies → Create.
    • Platform: Windows 10 and later.
    • Settings:
      • Require BitLocker: Required.
      • Firewall: Required.
      • Real‑time protection: Required.ninjaone
    • Assign to a Windows group.
  2. Create an iOS compliance policy.
    • New policy → Platform: iOS/iPadOS.
    • Settings:
      • Require passcode: Required.
      • Minimum OS version: set to a reasonable modern version (e.g., 17.0 for lab).
    • Assign to an iOS users/devices group.linkedin+1
  3. Create an Android compliance policy.
    • Platform: Android Enterprise (work profile).
    • Settings:
      • Require screen lock: Required.
      • Block rooted devices: Required.
      • Minimum OS version: set to modern Android.ninjaone
    • Assign to Android users/devices.
  4. Verify compliance per platform.
    • On each platform’s device, sync via Company Portal.
    • In Intune:
      • Devices → Windows → Windows devices → check Compliance.
      • Devices → iOS/iPadOS devices → check Compliance.
      • Devices → Android → Android devices → check Compliance.
    • Confirm each device’s non‑compliance reasons match your policies when you intentionally break them (e.g., remove passcode).ninjaone

Lab 31 – Single Conditional Access policy that covers all 3 platforms

Goal: Use one CA policy that enforces compliance across Windows, iOS, and Android for M365 access.

  1. Create a CA policy in Entra.
    • Entra admin center → Security → Conditional Access → Policies → New policy.
    • Name: CA-All-Platforms-Require-Compliant.
    • Users: test group containing users from all three platforms.learn.microsoft
  2. Configure cloud apps and platforms.
    • Cloud apps: Office 365 (or at least Exchange Online + SharePoint Online).
    • Conditions → Device platforms: select Windows, iOS, and Android.reddit+1
  3. Set the grant control.
    • Access controls → Grant → Grant access.
    • Select Require device to be marked as compliant.
    • Enable the policy (or start in Report‑only for safety).learn.microsoft
  4. Test on each platform.
    • On Windows, iOS, Android:
      • Make devices compliant first; sign into Outlook on the web / Outlook app and confirm access works.
      • Then make each device non‑compliant (e.g., disable BitLocker, remove passcode, or root emulator for testing) and re‑test.
    • You should be blocked on each platform until compliance is restored.learn.microsoft+1
  5. Review CA results.
    • In Entra Sign‑in logs, filter by test users.
    • For each failed sign‑in, check the Conditional Access tab to confirm your policy is what blocked access and that the condition is “device not compliant.”reddit+1

Lab 32 – App protection (MAM) + CA enforcement for mobile only

Goal: Require either MDM compliance or app protection for iOS/Android, a pattern that shows up in MD‑102 scenarios.ninjaone+1

  1. Ensure you have:
    • iOS and Android app protection policies targeting Outlook and other M365 apps.
    • Mobile devices with Outlook installed (enrolled or not).
  2. Create a mobile‑focused CA policy.
    • In Entra CA, create CA-Mobile-MAM-Or-Compliance.
    • Users: test mobile users.
    • Cloud apps: Exchange Online (email focus).
    • Device platforms: iOS and Android.youtube​learn.microsoft
  3. Configure grant controls.
    • In Grant:
      • Choose Require device to be marked as compliant OR Require app protection policy (if your licensing/tenant features show that control).
    • Combine them with Require one of the selected controls (logical OR).learn.microsoft
  4. Test with three scenarios:
    • Device enrolled + compliant with Outlook: should pass even if MAM not applied.
    • Device not enrolled but Outlook has app protection policy (MAM‑only): should pass.
    • Device not enrolled and no MAM policy: should be blocked.ninjaone+1
  5. Validate in logs.
    • Again, use Entra → Sign‑in logs and inspect the Conditional Access evaluation to see which control satisfied the policy (compliant device vs app protection).learn.microsoft

Here are a few more labs, this time aimed at Graph + automation and a simple end‑to‑end exam‑style scenario.github+1


Lab 33 – Use Graph to list Intune devices

Goal: Call Microsoft Graph to fetch a list of Intune‑managed devices.

  1. Register an app in Entra.
    • Entra admin center → App registrations → New registration.
    • Name: IntuneGraph-Lab.
    • Supported account type: Single tenant.
    • After creation, note:
      • Application (client) ID
      • Directory (tenant) ID.msadvance
  2. Grant API permissions.
    • In the app → API permissions → Add a permission.
    • Choose Microsoft Graph → Application permissions.
    • Add:
      • Device.Read.All
      • DeviceManagementManagedDevices.Read.All
    • Click Grant admin consent for the tenant.msadvance
  3. Create a client secret.
    • In the app: Certificates & secrets → New client secret.
    • Copy the secret value (you won’t see it again).msadvance
  4. Test with Graph Explorer or PowerShell.
    • Option A: Graph Explorer (browser):
      • Sign in with an admin account.
      • Run: GET https://graph.microsoft.com/v1.0/deviceManagement/managedDevices.
    • Option B: PowerShell (using Invoke-RestMethod and your app credentials) to call the same endpoint and output device names.github+1
  5. Confirm you see your Intune devices.
    • Result should show your enrolled devices with properties such as deviceName, operatingSystem, complianceState.msadvance

Lab 34 – Export all Intune configuration profiles via Graph

Goal: Pull a JSON dump of all configuration profiles for version control / documentation.

  1. Reuse the same app registration.
    • Use the IntuneGraph-Lab app from the previous lab.
  2. Ensure permissions include Intune config.
    • In the app: API permissions.
    • Add DeviceManagementConfiguration.Read.All (Application).
    • Grant admin consent.msadvance
  3. Call the config profiles endpoint.
    • Using Graph Explorer or PowerShell, hit:
      • GET https://graph.microsoft.com/v1.0/deviceManagement/deviceConfigurations.github+1
  4. Save the output.
    • In Graph Explorer, copy the JSON to a file (intune-configprofiles.json).
    • In PowerShell, pipe the result to ConvertTo-Json and then Out-File for local save.
  5. Use it as a backup/reference.
    • This JSON provides:
      • Profile names, types, settings payload.
    • Helps you compare changes over time or quickly see what’s configured without clicking around the portal.certlibrary+1

Lab 35 – Scenario lab: secure new remote laptops from first boot to conditional access

Goal: Walk through a realistic exam‑style scenario end‑to‑end.

Scenario:
You must deploy new Windows 11 laptops to remote users. Devices should be pre‑configured via Autopilot, encrypted with BitLocker, and blocked from accessing M365 until they are compliant.

  1. Register devices with Autopilot.
    • Export hardware hashes, import into Windows Autopilot devices, and assign them to an Autopilot-Remote group.alexandrumarin
  2. Create a user‑driven Autopilot profile.
    • Join: Entra joined.
    • Deployment: User‑driven.
    • Enable ESP for device + user + apps.
    • Assign to Autopilot-Remote group.learn.microsoft
  3. Create baseline configuration and BitLocker policies.
    • Config profile (Settings catalog): basic restrictions (e.g., block Control Panel).
    • Disk encryption policy: require BitLocker and escrow keys.learn.microsoft+1
    • Assign both to Autopilot-Remote.
  4. Create a Windows compliance policy.
    • Require BitLocker, Firewall, and Defender real‑time protection.
    • Assign to all remote users receiving these laptops.ninjaone
  5. Create a Conditional Access policy.
    • Scope: remote users group.
    • Apps: Office 365.
    • Device platforms: Windows.
    • Grant: Require device to be marked as compliant.learn.microsoft
  6. Add a few required apps for ESP.
    • Example: Company Portal, Office, browser.
    • Assign as Required to Autopilot-Remote group.learn.microsoft
  7. Run a full Autopilot OOBE on a test laptop.
    • Reset to OOBE.
    • User signs in; watch ESP install apps and apply BitLocker.
    • Confirm device shows Compliant in Intune after policies evaluate.learn.microsoft+1
  8. Test Conditional Access.
    • Before compliance, try logging into Outlook on the web: should be blocked.
    • After compliance, access should be allowed.
    • Use Sign‑in logs to verify your CA policy is the one enforcing this.reddit+1