Lab 06: Extend capabilities

Lab scenario

You are Jordan Chen, Modern Endpoint Administrator at Contoso Healthcare. You’ve implemented a comprehensive Intune environment (Labs 01-05) and now want to leverage premium capabilities from the Microsoft Intune Suite. You’ll configure Endpoint Privilege Management (EPM) to control application elevation, deploy Remote Help for secure remote assistance, review Advanced Analytics dashboards, and explore cloud-hosted desktop scenarios (Windows 365 and Azure Virtual Desktop).

By the end of this lab, you’ll have:

Enabled Endpoint Privilege Management in tenant settings
Created Windows elevation settings and elevation rules policies
Tested EPM elevation scenarios (automatic, user-confirmed, support-approved)
Rolled EPM out to the pilot cohort first, then expanded to the fleet (the canonical pilot-first pattern)
Enabled Remote Help and assigned licenses
Deployed the Remote Help app to devices
Initiated a Remote Help session between devices
Demonstrated that the Pharmacy Helpdesk delegated admin (Lee Gu, from Lab 05 Exercise 3) can launch Remote Help on Pharmacy-scoped devices only
Reviewed Advanced Analytics dashboards (demonstration)
Explored Windows 365 Cloud PC provisioning (demonstration)
Reviewed Azure Virtual Desktop session host enrollment (demonstration)

Lab Duration

Estimated Time: 90 minutes

Instructions

Before you begin

This lab requires:

Completion of Lab 01 (devices enrolled)
Microsoft Intune Suite trial active (activated in Lab 01 prerequisites) — required for Endpoint Privilege Management, Remote Help, and Advanced Analytics
Access to the Contoso Microsoft 365 tenant (<TenantPrefix>.onmicrosoft.com)
Global Administrator or Intune Administrator credentials
SEA-DEV1, SEA-DEV2, and SEA-DEV3 (enrolled Windows 11 devices)

Exercise 1: Configure Endpoint Privilege Management (EPM)

Scenario

Endpoint Privilege Management allows standard users to run specific applications with elevated privileges without granting full administrator rights. With the Intune Suite trial active (from Lab 01 prerequisites), EPM is already provisioned in your tenant. You’ll verify it’s available, create elevation settings and rules policies, and test different elevation scenarios.

Task 1: Verify Endpoint Privilege Management is available

Endpoint Privilege Management is one of the Microsoft Intune Suite add-on capabilities. With the Suite trial activated in Lab 01 prerequisites, EPM is already provisioned in your tenant — there is no separate tenant-wide “Enable EPM” toggle. Instead, you enable EPM on individual devices by deploying a Windows elevation settings policy with the Endpoint Privilege Management setting set to Enabled (you’ll do that in Task 2).

In the Microsoft Intune admin center, navigate to Endpoint security → Endpoint Privilege Management.
Confirm the EPM blade loads with the following tabs across the top:
- Overview (insights dashboard — may show “Insufficient data” on a new tenant)
- Reports (elevation report, elevation requests, file trends)
- Policies (where you’ll create elevation settings and elevation rules policies)
- Reusable settings (shared certificate groups for use across rules)
- Elevation requests (live and historical support-approved elevation requests)
[!IMPORTANT] If the EPM blade shows a licensing banner, return to Lab 01 prerequisites and complete the Microsoft Intune Suite trial activation before continuing.

You have successfully verified Endpoint Privilege Management is available.

Task 2: Create an elevation settings policy

Elevation settings policies define the default elevation behavior for devices — and they’re also what enables EPM on a device in the first place. The Endpoint Privilege Management setting inside this policy is what installs the EPM agent and starts evaluating elevation requests.

In the Microsoft Intune admin center, on the Endpoint Privilege Management page, select the Policies tab.
Select + Create from the top toolbar.
In the Create a profile pane, set:
- Platform: Windows
- Profile: Windows elevation settings policy
Select Create.
On the Basics page, enter:
- Name: EPM Settings - Default Behavior
- Description: Default EPM settings for the Contoso fleet
Select Next.
On the Configuration settings page, configure:
- Endpoint Privilege Management: Enabled (this is the toggle that actually enables EPM on the device; leaving it disabled or removing the policy disables EPM on those devices after seven days)
- Default elevation response: Require user confirmation
  - Validation: Business justification (require the user to enter a reason)
- Send elevation data for reporting: Yes
  - Reporting scope: Diagnostic data and managed elevations only (enables the Elevation report under the Reports tab to populate)
[!NOTE] Select Require user confirmation for this lab so you can see the EPM prompt later in Task 6. “Not Configured” behaves the same as “Deny all requests”.
Select Next.
On the Scope tags tab, select Next.
On the Assignments tab, under Included groups, select Add groups.
Search for and select dyn-Windows-Devices.
Select Select → Next → Create.

You have successfully created an elevation settings policy.

Task 3: Create an automatic elevation rule

Automatic elevation rules allow specific applications to always run elevated without user prompts.

On the Endpoint Privilege Management page, on the Policies tab, select + Create.
In the Create a profile pane, set Platform to Windows and Profile to Elevation rules policy. Select Create.
On the Basics page, enter:
- Name: EPM Rules - Automatic Elevation
- Description: Allows Registry Editor to always run elevated
Select Next.
On the Configuration settings tab, expand Privilege Management.
Select + Edit instance, then in the Rule properties pane, configure:
- Rule name: Elevate Registry Editor
- Description: Automatically elevates regedit.exe without user prompt
- Elevation type: Automatic
- File name: regedit.exe
- File path: C:\Windows\regedit.exe
- Signature source: Not configured
On SEA-DEV1, open an elevated PowerShell window and run the following command to obtain the SHA256 hash for regedit.exe, then copy the hash value into the File hash field in the rule properties pane:
```
  Get-FileHash -Path "C:\Windows\regedit.exe" -Algorithm SHA256
```
Select Save to add the rule, and then select Next.
On the Scope tags tab, select Next.
Select Add groups under Included groups, search and select sg-Intune-Pilot-Users (pilot-first rollout for EPM — same cohort as the blocking ESP, pilot update ring, and Block-mode ASR rules from earlier labs), then select Next → Create.

You have successfully created an automatic elevation rule scoped to the pilot cohort.

Task 4: Create a user-confirmed elevation rule

User-confirmed elevation rules prompt the user to approve elevation (with optional business justification).

On the Endpoint Privilege Management page, on the Policies tab, select + Create.
In the Create a profile pane, set Platform to Windows and Profile to Elevation rules policy. Select Create.
On the Basics tab, enter:
- Name: EPM Rules - User Confirmed Elevation
- Description: Prompts user to approve elevation for MSConfig
Select Next.
On the Configuration settings tab, expand Privilege Management.
Select + Edit instance, then in the Rule properties pane, configure:
- Rule name: Elevate MSConfig with User Confirmation
- Elevation type: User confirmed
- Validation: Business justification (require the user to enter a reason)
- File name: msconfig.exe
- File path: C:\Windows\System32\msconfig.exe
- Signature source: Not configured
On SEA-DEV1, open an elevated PowerShell window and run the following command to obtain the SHA256 hash for msconfig.exe, then copy the hash value into the File hash field in the rule properties pane:
```
  Get-FileHash -Path "C:\Windows\System32\msconfig.exe" -Algorithm SHA256
```
Select Save, and then select Next.
On the Scope tags tab, select Next.
On the Assignments tab, under Included groups, select Add groups, search and select sg-Intune-Pilot-Users (pilot-first rollout for EPM — same cohort as the blocking ESP, pilot update ring, and Block-mode ASR rules from earlier labs), then select Next → Create.

You have successfully created a user-confirmed elevation rule scoped to the pilot cohort.

Task 5: Create a support-approved elevation rule

Support-approved elevation rules require a help desk agent to approve elevation requests remotely.

On the Endpoint Privilege Management page, on the Policies tab, select + Create.
In the Create a profile pane, set Platform to Windows and Profile to Elevation rules policy. Select Create.
On the Basics tab, enter:
- Name: EPM Rules - Support Approved Elevation
- Description: Requires help desk approval for CMD elevation
Select Next.
On the Configuration settings tab, expand Privilege Management.
Select + Edit instance, then in the Rule properties pane, configure:
- Rule name: Elevate Command Prompt with Support Approval
- Elevation type: Support approved
- File name: cmd.exe
- File path: C:\Windows\System32\cmd.exe
- Signature source: Not configured
On SEA-DEV1, open an elevated PowerShell window and run the following command to obtain the SHA256 hash for cmd.exe, then copy the hash value into the File hash field in the rule properties pane:
```
  Get-FileHash -Path "C:\Windows\System32\cmd.exe" -Algorithm SHA256
```
Select Save, and then select Next
On the Scope tags tab, select Next.
On the Assignments tab, under Included groups, select Add groups, search and select sg-Intune-Pilot-Users (pilot-first rollout for EPM — same cohort as the blocking ESP, pilot update ring, and Block-mode ASR rules from earlier labs), then select Next → Create.

You have successfully created a support-approved elevation rule scoped to the pilot cohort.

Task 6: Test EPM elevation on SEA-DEV3

Switch to SEA-DEV3 (this device needs to be Entra joined with a standard user account, e.g. Alex Wilber).
Sign in with the Admin account.
Open Settings → Accounts → Access work or school → Connect → Join this device to Microsoft Entra ID
When prompted, sign in with **MeganB@.OnMicrosoft.com**.
Select Join and Done to complete the Microsoft Entra join.
Sign out and sign back in as **AlexW@.OnMicrosoft.com** (who will be a standard user, not a local administrator). If prompted to set up a PIN, do so.
Wait 10–15 minutes for policies to apply.

[!NOTE] If Run with elevated access doesn’t appear, select Show more options or press Shift+F10. If it’s still missing, sync the device and wait a few minutes before retrying.
Test automatic elevation (Registry Editor):
- Open the Start menu and search for regedit
- Select Open file location
- Select Registry Editor, right-click and select Run with elevated access to launch Registry Editor
- Expected behavior: The app launches elevated without prompting (automatic elevation rule applied)
Test user-confirmed elevation (MSConfig):
- Open the Start menu and search for msconfig
- Select Open file location
- Select System Configuration, right-click and select Run with elevated access to launch System Configuration
- Expected behavior: A prompt appears asking the user to confirm elevation and provide business justification
- Enter a justification (e.g., Troubleshooting startup issues) and select Continue to approve
Test support-approved elevation (Command Prompt):
- Open the Start menu and search for cmd
- Select Open file location
- Right-click Command Prompt and select Run with elevated access
- Enter a business justification (e.g., Need elevated command prompt for script execution) and select Continue
- Expected behavior: A prompt appears indicating the request is pending help desk approval.
[!NOTE] If Command Prompt opens elevated instead of prompting for approval, confirm the EPM Rules - Support Approved Elevation policy shows a Success check-in for SEA-DEV3 (Policies → select the policy → View report), sync the device, and test again. If it still doesn’t work after a few minutes, continue to the next task.

You have successfully tested EPM elevation scenarios.

Task 7: Monitor EPM elevation reports

On SEA-DEV1, in the Microsoft Intune admin center, navigate to Endpoint security → Endpoint Privilege Management → Reports.
Review the available reports by selecting each tile.
- Elevation report: Review all elevation activity
- Managed elevations report: Review elevations managed by policy
- Elevation report by applications: See all elevations grouped by application
- Elevation report by publisher: See all elevations for the same signed publisher
- Elevation report by user: See all elevations by each user
[!NOTE] EPM report data can be delayed because the data is processed once every 24 hours.

You have successfully monitored EPM elevation reports.

Exercise 2: Deploy Remote Help

Scenario

Remote Help provides secure, audited remote assistance for enrolled devices. IT administrators can remotely view and control devices to troubleshoot issues. You’ll enable Remote Help, assign licenses, deploy the app, and initiate a remote session.

Task 1: Enable Remote Help

In the Microsoft Intune admin center, select Tenant administration and select Remote Help.
On the Remote Help page, select the Settings tab.
Select Configure and configure the following settings:
- Enable Remote Help: Enabled
- Allow Remote Help to unenrolled devices: Not allowed
- Disable Chat: No
Select Save.

You have successfully enabled Remote Help.

Task 2: Assign Remote Help licenses

Remote Help requires Microsoft Intune Suite licensing.

In Microsoft Edge, navigate to https://admin.cloud.microsoft.
Sign in as **admin@.onmicrosoft.com**.
In the Microsoft 365 admin center, expand Users and select Active users.
Select Megan Bowen (helper role—help desk or admin).
Select the Licenses and apps tab.
Verify Microsoft Intune Suite is assigned (or assign it if not present).
Repeat for Joni Sherman (sharer role—end user receiving help) and for Lee Gu (Pharmacy Helpdesk role).

You have successfully assigned Remote Help licenses.

Task 3: Deploy the Remote Help app

[!IMPORTANT] If your lab host provided the required .intunewin file, skip to step 5.

In Microsoft Edge, open a new tab and navigate to https://aka.ms/downloadremotehelp.

Move the downloaded installer into the LabAssets folder created in Lab 03:

Move-Item "$env:USERPROFILE\Downloads\remotehelp*.exe" "C:\LabAssets\Win32-App\Source\remotehelpinstaller.exe"
Get-ChildItem "C:\LabAssets\Win32-App\Source\remotehelpinstaller.exe"

Navigate to the Win32 Content Prep Tool directory:
```
cd "C:\Program Files\IntuneWinAppUtil"
```

Run the content prep tool to package the app:

.\IntuneWinAppUtil.exe -c "C:\LabAssets\Win32-App\Source" -s "remotehelpinstaller.exe" -o "C:\LabAssets\Win32-App\Output"

In the Microsoft Intune admin center, navigate to Apps → All apps.
Select + Create from the top toolbar.
In the Select app type pane, set Platform to Windows and App type to Windows app (Win32). Select Select.
On the App information page, select Select app package file.
On the App package file pane, select the folder icon and upload the .intunewin file.
Select OK.
On the App information tab, enter:
- Name: Remote Help
- Description: Secure remote assistance app for enrolled devices
- Publisher: Microsoft Corporation
Select Next.
On the Program tab, configure:
- Install command: remotehelpinstaller.exe /quiet acceptTerms=1
- Uninstall command: remotehelpinstaller.exe /uninstall /quiet acceptTerms=1
- Install behavior: System
On the Requirements tab, configure:
- Check operating system architecture: Select Yes. Specify the systems the app can be installed on. Check Install on x64-system
- Minimum operating system: Windows 10 1607
Select Next. On the Detection rules tab, set Rules format to Manually configure detection rules, then select Add.
In the Detection rule pane, configure:
- Rule type: File
- Path: C:\Program Files\Remote help
- File or folder: RemoteHelp.exe
- Detection method: File or folder exists
- Associated with a 32-bit app on 64-bit clients: No
Select OK → Next until you reach the Assignments tab.
On the Assignments tab, select + Add group and assign as Required the group dyn-Windows-Devices.
Select Next → Create.

You have successfully deployed the Remote Help app.

Task 4: Initiate a Remote Help session

[!NOTE] If the Remote Help sign-in prompt shows “Device must comply with your organization’s compliance requirements”, set Require encryption of data storage on device to Not configured in both the Graph API - Windows Compliance Policy and the Compliance - Windows Security Baseline. Then Sync each device and confirm it shows Compliant.

On SEA-DEV1 (helper device—Megan Bowen), wait for Remote Help to install.
After installation, launch Remote Help from the Start menu.
Sign in as **MeganB@.OnMicrosoft.com** (helper role).
In the About your privacy prompt, select Accept.
In the Remote Help app, under Give help, select Get a security code.
A 6-digit security code is displayed (e.g., 123ABC).
Switch to SEA-DEV2 (sharer device—Joni Sherman) and sign in as **JoniS@.OnMicrosoft.com**.
Launch Remote Help from the Start menu.
Sign in as **JoniS@.OnMicrosoft.com** (sharer role).
On the About your privacy prompt, select Accept.
In the Remote Help app, under Get Help, in the Security code from assistant box, enter the 6-digit code from SEA-DEV1, then select Submit.
Switch back to SEA-DEV1. The Remote Help app displays a prompt indicating Joni is ready to receive help. Select View screen.
On SEA-DEV2, a consent prompt appears asking Joni to approve the remote session.
On SEA-DEV2, select Allow. Megan can now view Joni’s desktop.
Switch back to SEA-DEV1 and test the remote actions:
- Megan can use chat to communicate with Joni
- Megan can request control to interact with applications
- Megan can end the session at any time
After testing, select Leave to disconnect.

You have successfully initiated and tested a Remote Help session.

Task 5: Review Remote Help session logs

In the Microsoft Intune admin center, navigate to Tenant administration → Remote Help.
Select the Remote Help sessions tab.
Review the session log columns:
- Provider ID (the helper — for example, MeganB@<TenantPrefix>.onmicrosoft.com)
- Recipient ID (the sharer — for example, JoniS@<TenantPrefix>.onmicrosoft.com)
- Recipient name
- Device name
- OS
- Session start
- Session end

You have successfully reviewed Remote Help session logs.

Task 6: Demonstrate Pharmacy Helpdesk Remote Help scope

The Pharmacy Helpdesk role assigned to Lee Gu in Lab 05 Exercise 3 grants Read, Remote Help app, Remote assistance connectors: Read, and remote-task permissions (including Offer remote assistance, Sync devices, Restart now, and Collect diagnostics) scoped to objects tagged Pharmacy. Remote Help inherits the same scope: Lee Gu can initiate a Remote Help session against Pharmacy-tagged devices, but not against devices outside his scope. This is the upper-intermediate “delegated remote-assistance” pattern.

Open a new InPrivate or Incognito browser window. Navigate to https://intune.microsoft.com.
Sign in as **LeeG@.OnMicrosoft.com** (Lee Gu, the Pharmacy Helpdesk delegated admin).
In the Intune admin center as Lee Gu, navigate to Devices → All devices.

[!NOTE] Lee Gu sees only devices in dyn-Windows-Devices that have the Pharmacy scope tag. This list may be smaller than what your Global Admin sees.
Select a Pharmacy-tagged device (e.g., SEA-DEV1 tagged with Pharmacy).
In the device blade, select Remote actions, and then select Begin a remote assistance session.
Confirm Lee Gu can initiate the Remote Help session. The session opens in the Remote Help client — same flow as Task 4 above.
End the session.
Now try to select a device that’s not Pharmacy-tagged (Lee Gu won’t see one in his list, so this is a thought experiment): if such a device existed in his view, he would lack the Begin a remote assistance session option because the role’s scope tag intersection excludes it.
Sign out of the InPrivate window.

You have successfully demonstrated end-to-end that the Pharmacy Helpdesk delegated role, created in Lab 01 and assigned in Lab 05, scopes Remote Help operations exactly as designed. Thread A (custom RBAC + scope tag delegation) is now complete across all six labs.

Exercise 3: Use Advanced Analytics and Device Query

Scenario

Advanced Analytics (part of Intune Suite and other eligible Intune advanced capability licenses) provides ML-powered insights into device performance, anomaly detection, and resource utilization. Device Query uses Kusto Query Language (KQL) to run ad-hoc queries against Windows device telemetry — either against a single device (live) or across many devices. This is the upper-intermediate replacement for “please run remote desktop and check” — a delegated admin can answer real support questions without ever touching a user’s device.

The Intune Suite trial activated in Lab 01 includes Advanced Analytics, so this exercise is fully hands-on.

[!IMPORTANT] Device Query requires an active Intune Suite trial or another license that includes Intune Advanced Analytics. The device must also be enrolled in Endpoint Analytics.

[!NOTE] Empty results are normal on a fresh tenant until a Windows device checks in to Endpoint Analytics and returns the required inventory.

[!NOTE] Advanced Analytics dashboards need approximately 24 hours of device telemetry to populate. If SEA-DEV1 or SEA-DEV2 was enrolled less than 24 hours ago, Task 1 may show “Insufficient data”.

Task 1: Review Advanced Analytics dashboards

In the Microsoft Intune admin center, navigate to Reports → Analytics → Endpoint analytics.
Select the Anomalies tab and review the dashboard:
- Device anomalies: Devices exhibiting unusual behavior (high CPU, frequent crashes, app hangs)
- User anomalies: Users experiencing degraded experience scores
- Application anomalies: Apps with high crash rates or slow start times
[!NOTE] On a new lab device with limited history, you may see empty panels or a status banner. That’s expected.
Under Reports, select Resource performance and review the dashboard:
- CPU performance: Devices with sustained high CPU utilization
- Memory performance: Devices with memory pressure (page faults, working-set pressure)
- Disk performance: Devices with slow disk I/O
Under Reports, select Battery health and review the dashboard (if mobile devices are enrolled):
- Battery capacity degradation: Devices with reduced battery health vs. designed capacity
- Charging behavior: Frequent charging cycles

You have successfully reviewed the Advanced Analytics reports.

Task 2: Run live Device Query on a single device

Single-device Device Query runs a KQL query against one Windows device’s live state. It’s the canonical replacement for opening a remote control session just to check a service, a registry value, or an installed app version.

In the Microsoft Intune admin center, navigate to Devices → Windows → select SEA-DEV1.
Under the Monitor section, select Device query.

In the query editor, enter and run the following query to list the CPU information for SEA-DEV1:

Cpu
| project ProcessorId, Model, Architecture, CpuStatus, CoreCount, LogicalProcessorCount, Manufacturer

Select Run. Results appear in the Results tab within a few seconds.

[!NOTE] Single-device Device Query has a 15 queries / minute rate limit per admin, a 2048-character query input limit, and a 128 KB result limit.

Replace the query with this one to check BitLocker encryption status on SEA-DEV1’s drives:

EncryptableVolume
| project VolumeId, WindowsDriveLetter, ProtectionStatus, EncryptionMethod

Select Run. Confirm SEA-DEV1’s OS drive shows PROTECTED — this verifies the BitLocker policy from Lab 04 Exercise 3 is actively encrypting the drive (rather than just “assigned” in the Intune portal).
Replace the query with this one to verify the device’s OS version:
```
OsVersion
| project OsVersion, BuildVersion, Architecture
```
Select Run. Note the build SEA-DEV1 is running. You’ll compare it to the Windows 11 25H2 target from the Feature update profile in Lab 02 Exercise 4 in the next task.

You have successfully run live Device Query against a single device.

Task 3: Run multi-device Device Query and build a security group from results

Multi-device Device Query runs one KQL query across every Windows device in your scope and returns one row per device. The killer feature: you can create a Microsoft Entra security group directly from a query’s results, which means you can dynamically target Intune policies and Conditional Access at exactly the devices your query found.

In the Microsoft Intune admin center, navigate to Devices → Device query.
Below the empty query window, select Get started and then scroll down to the Example queries section and browse the pre-built samples. Microsoft maintains this list — it’s the fastest way to learn the supported tables and operators.
If you haven’t already deployed the required properties catalog policy, navigate to Devices → Manage devices → Configuration → Create → New Policy. Set Platform to Windows 10 and later, set Profile type to Properties catalog, and then select Create.
On the Basics page, enter:
- Name: Device Query Properties Catalog
- Description: Collects properties required for Device Query labs
Select Next. On the Configuration properties page, select Add properties. In the Properties picker, add CPU, Encryptable Volume, Logical Drive, and OS Version.
Select Next. On the Scope tags page, select Next.
On the Assignments page, add the All devices group. Select Next, and then on the Review + create page, select Create.

[!NOTE] Initial inventory collection can take up to 24 hours. If the query returns no data, wait for the properties catalog profile to apply and for devices to check in.
Enter and run this query to find every Windows device that is not BitLocker-encrypted — the canonical “these devices need attention now” query:
```
EncryptableVolume
| where ProtectionStatus != "PROTECTED"
| join LogicalDrive on Device
| distinct Device
```
Select Run. The Results tab returns one row per affected device.
With results on screen, select Add all items to a group from the top of the Results tab. In the dialog, name the new group sg-Devices-Unencrypted (description: Devices identified by Device Query as not BitLocker-encrypted). Select Create group.
Run a second query to find devices running an OS build older than your fleet target (Windows 11 25H2 — build number 26200):
```
OsVersion
| where toint(BuildVersion) < 26200
| project Device, OsVersion, BuildVersion
| order by BuildVersion asc
```
Select Run. This is your “hasn’t taken the feature update yet” working list — useful for chasing devices that fall behind the Feature update profile you created in Lab 02 Exercise 4. An empty result means all queried devices are at or above the target build.
Run a third query to summarize the fleet by processor architecture (a quick “who has ARM64 devices” inventory):
```
Cpu
| summarize DeviceCount = count() by Architecture
```
Select Run. The Results tab shows a summary row per architecture.
Select Export to save the result set as CSV — useful for handing a hardware inventory to procurement or for ticketing-system import. Because this query returns aggregate rows, Add all items to a group isn’t shown.

You have successfully run multi-device Device Query and converted a query result into a Microsoft Entra security group.

Exercise 4: Explore Windows 365 Cloud PC provisioning

Scenario

Windows 365 provides cloud-hosted Windows desktops (Cloud PCs) that users access via browser or Remote Desktop client. You’ll review the provisioning process and understand how Cloud PCs integrate with Intune.

[!NOTE] Windows 365 provisioning requires an Azure subscription and additional licensing. This exercise is a guided demonstration.

Task 1: Review Windows 365 provisioning policy (demonstration)

In the Microsoft Intune admin center, navigate to Devices → Manage Windows 365 Cloud PCs → Provisioning Cloud PCs.

[!NOTE] If Windows 365 is not available in your tenant, review the following steps conceptually.
Understand the Create provisioning policy workflow:
- Basics:
  - Policy name
  - Join type: Microsoft Entra join or Hybrid Microsoft Entra join
  - Network: Microsoft-hosted network or Azure network connection
- Image:
  - Gallery image (e.g., Windows 11 Enterprise + Microsoft 365 Apps)
  - Custom image (uploaded to Azure Compute Gallery)
- Configuration:
  - License type: Enterprise, Business, or Frontline
  - Region: Azure region for Cloud PC deployment
  - Enable single sign-on: Yes/No
Understand the Assignment workflow:
- Assign provisioning policy to Microsoft Entra groups
- Users in the group automatically receive a Cloud PC when policy is assigned
- Cloud PC is provisioned in Azure (typically 15–30 minutes)
Understand the User experience:
- User signs in to https://windows365.microsoft.com
- Cloud PC appears in the user’s dashboard
- User can launch the Cloud PC via browser or Remote Desktop client
- Cloud PC is managed by Intune (same policies as physical devices)

You now understand how Windows 365 provisioning policies deploy cloud-hosted Windows desktops.

Task 2: Review Cloud PC management in Intune (demonstration)

In the Microsoft Intune admin center, navigate to Devices → All devices.
Understand that Cloud PCs appear in the device list with:
- Device name: CloudPC-
- Managed by: Intune
- Ownership: Corporate
- OS: Windows 11 Enterprise
Understand that Cloud PCs receive the same Intune policies as physical devices:
- Configuration profiles
- Compliance policies
- Applications
- Security baselines
Understand Cloud PC-specific actions:
- Restart: Restarts the Cloud PC
- Resize: Changes the Cloud PC SKU (vCPU, RAM)
- Restore: Restores the Cloud PC from a backup snapshot
- Reprovision: Wipes the Cloud PC and re-provisions from the image

You now understand how Cloud PCs are managed in Intune like physical devices.

Exercise 5: Explore Azure Virtual Desktop session host enrollment

Scenario

Azure Virtual Desktop (AVD) provides multi-session Windows desktops for virtual desktop infrastructure (VDI) scenarios. You’ll review how AVD session hosts can be enrolled in Intune for policy management.

[!NOTE] AVD session host enrollment requires an Azure subscription and AVD deployment. This exercise is a guided demonstration.

Task 1: Understand AVD session host enrollment (demonstration)

Understand the AVD architecture:
- Host pool: Collection of identical session hosts (VMs)
- Session hosts: Windows 11 or Windows 10 multi-session VMs
- Workspaces: User-facing interface to access desktops and apps
Understand how session hosts are enrolled in Intune:
- Session hosts are Microsoft Entra joined (or Hybrid joined)
- Automatic MDM enrollment is enabled (same as physical devices in Lab 01)
- Session hosts enroll in Intune during initial provisioning
Understand AVD-specific policy considerations:
- User-based policies: Applied to the user session (e.g., OneDrive sync, app settings)
- Device-based policies: Applied to the session host VM (e.g., BitLocker, firewall, antivirus)
- Multi-session optimizations: Policies should account for multiple concurrent users (e.g., FSLogix profile containers)

You now understand how AVD session hosts enroll in Intune and how policies are applied in multi-session environments.

Task 2: Review AVD session host in Intune (demonstration)

In the Microsoft Intune admin center, navigate to Devices → All devices.
Understand that AVD session hosts appear in the device list with:
- Device name: AVD-SessionHost-
- OS: Windows 11 Enterprise multi-session or Windows 10 Enterprise multi-session
- Managed by: Intune
Understand that AVD session hosts receive Intune policies:
- Configuration profiles (e.g., Start menu layout, Edge policies)
- Compliance policies (e.g., antivirus, firewall)
- Applications (e.g., Microsoft 365 Apps, LOB apps)
Understand AVD-specific considerations:
- Do not apply BitLocker to session hosts (managed disks are encrypted at rest in Azure)
- Use FSLogix for user profile management (not OneDrive Known Folder Move)
- Apply Windows Update policies carefully (coordinate with AVD maintenance windows)

You now understand how AVD session hosts are managed in Intune.

Lab Summary

Congratulations! You’ve completed Lab 06: Extend capabilities — the final lab in the MD-102 series.

In this lab, you accomplished the following:

Exercise 1: Configure Endpoint Privilege Management (EPM)

Enabled Endpoint Privilege Management in tenant settings
Created an elevation settings policy defining default elevation behavior
Created automatic, user-confirmed, and support-approved elevation rules — all targeted to the pilot cohort first
Tested EPM elevation scenarios on a standard user device
Monitored elevation reports for audit and compliance
Established the pilot → fleet expansion plan for EPM rollout

Exercise 2: Deploy Remote Help

Enabled Remote Help and assigned licenses to helpers and sharers
Deployed the Remote Help app to managed devices
Initiated a Remote Help session and tested view-only and full control access
Reviewed Remote Help session logs for audit purposes
Demonstrated that the Pharmacy Helpdesk delegated admin (Lee Gu, from Lab 05 Exercise 3) can launch Remote Help on Pharmacy-scoped devices only — completing Thread A (custom RBAC + scope tag delegation) end-to-end across all six labs

Exercise 3: Use Advanced Analytics and Device Query

Reviewed Advanced Analytics dashboards for anomaly detection, resource performance, and battery health
Ran live single-device KQL queries via Device Query (CPU info, BitLocker status verification, OS version)
Ran multi-device KQL queries to find unencrypted devices and devices below the 25H2 feature-update target
Built a Microsoft Entra security group (sg-Devices-Unencrypted) directly from a Device Query result set

Exercise 4: Explore Windows 365 Cloud PC provisioning

Reviewed the Windows 365 provisioning policy workflow
Understood how Cloud PCs are automatically provisioned and managed in Intune

Exercise 5: Explore Azure Virtual Desktop session host enrollment

Understood AVD architecture and session host enrollment
Reviewed how AVD session hosts are managed in Intune with user-based and device-based policies

Key Takeaways:

Endpoint Privilege Management allows granular control of application elevation without granting full administrator rights; pilot-first rollout (same cohort as ESP, update ring, ASR) limits blast radius
Remote Help provides secure, audited remote assistance with session logging for compliance
Scope tags on a custom role apply to remote-task operations including Remote Help — the Pharmacy Helpdesk physically cannot initiate Remote Help on devices outside the Pharmacy scope
Advanced Analytics surfaces ML-driven anomaly detection against each device’s own historical baseline (not a fleet threshold); Device Query lets you ask live KQL questions of one device or the whole fleet without remote control
The “build a Microsoft Entra security group from query results” pattern is the upper-intermediate move: query reality, then target policy at exactly what you found
Windows 365 Cloud PCs are provisioned via Intune policies and managed like physical devices
Azure Virtual Desktop session hosts enroll in Intune and receive policies for multi-session environments

Course Completion: You have completed all 6 labs in the MD-102: Microsoft 365 Endpoint Administrator certification course. You are now prepared to:

Deploy and manage Microsoft Intune in a cloud-pure environment
Enroll devices using Microsoft Entra join and Windows Autopilot
Configure device policies, compliance, and Windows Update management
Deploy applications using multiple methods (Store, Win32, Microsoft 365 Apps, Enterprise App Catalog)
Implement endpoint security with Microsoft Defender for Endpoint, BitLocker, and endpoint security policies
Automate management with Microsoft Graph PowerShell
Implement RBAC with scope tags for delegated administration
Extend capabilities with Microsoft Intune Suite (EPM, Remote Help, Cloud PKI, Microsoft Tunnel)
Support cloud-hosted desktops with Windows 365 and Azure Virtual Desktop

Next Steps:

Review the MD-102 exam objectives and map your lab experience to the exam skills measured
Practice additional scenarios in your own test tenant
Explore the Microsoft Learn modules for MD-102 for additional conceptual knowledge
Schedule your MD-102 certification exam when ready

Thank you for completing the MD-102 hands-on lab series!

END OF LAB