MD-102 Intune Lab Guide: Compliance, Restrictions, and Reporting (Hands-On Practice)

If you’re preparing for the MD-102 Endpoint Administrator exam, you’ll see lots of questions around Intune compliance, restrictions, and reporting. Instead of just memorizing answers, it’s better to actually do the tasks once in a lab tenant. This blog walks through five small labs you can run to lock in the concepts.

---

Lab 1: Block Windows Insider Program with Intune

Goal: Stop users from opting their corporate devices into Windows Insider builds.

Why it matters: Insider builds bring preview features and potential instability into your environment. For managed devices, you usually want to stay on supported, production channels only.

Steps:

1. In the Intune admin center, go to
   Devices → Windows → Configuration profiles → Create profile.
2. Platform: Windows 10 and later.
   Profile type: Templates → Device restrictions.
3. In the settings, find the Windows Update / Insider / preview build options and set them to block Insider enrollment (wording varies slightly, but look for Insider or preview builds).
4. Assign the profile to a group that represents all managed Windows 10/11 devices.
5. On a test device, open Settings → Windows Update → Windows Insider Program and confirm the user can no longer join.

Key takeaway: Blocking the Insider Program is done with a device restrictions profile, not with an update ring.

---

Lab 2: Explore the Device Compliance Trends Report

Goal: Understand how long compliance trend data is kept and how to read it.

Why it matters: Trend reports are how you prove to management that compliance is improving after policy changes.

Steps:

1. In Intune, open Reports → Device compliance → Compliance trends.
2. Use the time picker to switch between 7, 14, 30, and 60 days. Notice that 60 days is the maximum window.
3. Look at the graph showing numbers of compliant, noncompliant, and not evaluated devices over time.
4. As a mini experiment, tighten a compliance policy (for example, require BitLocker) on a test group. Over the next few days, watch how the trend line changes as devices become compliant or noncompliant.

Key takeaway: The compliance trends report keeps up to 60 days of history and is great for before/after views when you roll out new rules.

---

Lab 3: Apply the Microsoft Edge Security Baseline

Goal: Deploy the Edge security baseline and see which devices it actually targets.

Why it matters: Security baselines are a common exam topic, and Edge is a frequent example. You need to know that the Edge baseline is Windows-focused.

Steps:

1. Go to Endpoint security → Security baselines → Microsoft Edge.
2. Create a new baseline profile (call it “Edge1”) and review the default hardened settings.
3. Assign the baseline to a mixed group that includes Windows devices and, if you have them, non-Windows endpoints like macOS or mobile.
4. After devices sync, inspect a few endpoints:
   • Windows 10/11 devices should receive and enforce the baseline.
   • Non-Windows devices will not apply this baseline.

Key takeaway: Microsoft Edge security baselines apply to Windows endpoints, not to every platform in your environment.

---

Lab 4: Custom Compliance for BIOS Version (PowerShell + JSON)

Goal: Build a custom compliance rule that checks BIOS version using PowerShell and a JSON rule file.

Why it matters: MD-102 expects you to know the difference between built-in compliance checks and custom ones. BIOS version is a classic example of something you verify with a script.

Steps:

1. Write a discovery script
   • Create a PowerShell script that reads the BIOS version using something like Get-CimInstance -ClassName Win32_BIOS.
   • At the end, output a simple one-line JSON object, for example:
     Write-Output "{""BiosVersion"":""$($bios.SMBIOSBIOSVersion)""}".
2. Upload the script
   • In Intune, go to the section for custom compliance or scripts and upload your PowerShell script.
   • Assign it to a small Windows 11 test group.
3. Create the JSON rules file
   • Build a JSON file that defines what counts as compliant (for example, BIOS version must be equal to or newer than a specific version).
   • The file maps the BiosVersion property to compliance states.
4. Create a custom compliance policy
   • Go to Devices → Compliance policies → Create policy → Windows 10 and later → Custom.
   • Upload the JSON rules file and link it to your discovery script.
   • Assign the custom compliance policy to the same test group.
5. Check the results
   • After devices check in, look at their compliance state.
   • Devices with an outdated BIOS should show as noncompliant according to your custom rules.

Key takeaway: A standard compliance policy only uses built-in checks (BitLocker, OS version, etc.). A custom compliance policy uses PowerShell plus a JSON rules file to evaluate whatever logic you need.

---

Lab 5: Build an Intune Device Inventory Report with Power BI

Goal: Use the Intune Data Warehouse and Power BI to build a custom inventory/compliance report.

Why it matters: The exam tests that you know which tool to use for deeper reporting. For cross-tenant or long-term analytics, the answer is Power BI hooked into the Intune Data Warehouse.

Steps:

1. In the Intune admin center, go to Reports → Intune Data Warehouse and copy the OData URL.
2. Open Power BI Desktop on your admin workstation.
3. Click Get Data → OData feed, paste the Intune OData URL, and sign in with your Intune admin account.
4. Select tables like:
   • devices
   • managedDevice
   • deviceCompliancePolicyStatus
5. Load the data and build a simple report:
   • Table visual with device name, primary user, OS version, and compliance state.
   • Maybe a bar chart showing counts of compliant vs noncompliant devices.
6. If you want to go further, publish the report to the Power BI service and share it with your team.

Key takeaway: For custom reporting that includes data from the Intune Data Warehouse, the go-to tool is Microsoft Power BI using the OData connector.

---

These five labs line up directly with the types of scenarios that appear on MD-102: blocking Insider builds, reading compliance trends, applying baselines, using custom compliance, and reporting from the data warehouse.