Microsoft Intune Interview Questions – Part 5: Windows Autopilot, Deployment, Co-Management & Advanced Scenarios

Windows device deployment has changed significantly from the traditional model of manually imaging every computer.

Modern Microsoft environments can use:

• Windows Autopilot
• Windows Autopilot device preparation
• Microsoft Intune
• Microsoft Entra ID
• Configuration Manager
• Co-management
• Cloud attach
• Windows Autopilot Reset
• Microsoft Entra join
• Microsoft Entra hybrid join

A senior Intune administrator should understand not only how to deploy a Windows device, but also how the different deployment technologies interact.

This part focuses on the areas that are most relevant in senior System Administrator, Endpoint Administrator and Intune Engineer interviews:

• Windows Autopilot architecture
• User-driven deployment
• Pre-provisioned deployment
• Windows Autopilot device preparation
• Enrollment Status Page
• Device registration
• Hardware information
• Deployment troubleshooting
• Existing-device scenarios
• Autopilot Reset
• Configuration Manager integration
• Co-management
• Workload ownership
• Cloud attach
• Tenant attach
• Large-scale migration
• Production troubleshooting

Microsoft describes Windows Autopilot as a collection of technologies for setting up and preparing Windows devices with little traditional deployment infrastructure. It can also support device reset, repurpose and recovery scenarios.

Continue the Microsoft Intune Interview Series

← Previous Part: [Part 4: Compliance, BitLocker, Defender & Conditional Access] | Complete Series: [Microsoft Intune Interview Questions & Answers – Complete Series]

Windows Autopilot Interview Questions

Q1. What is Windows Autopilot?

Windows Autopilot is a cloud-based Windows deployment technology that allows organizations to provision and configure Windows devices without relying on traditional operating-system imaging for every deployment.

Instead of creating and maintaining customized Windows images, Autopilot uses the OEM-installed Windows image and applies organizational configuration during deployment.

It can:

• Configure Windows
• Join the device to Microsoft Entra ID
• Enroll the device into Intune
• Apply policies
• Install applications
• Configure security settings
• Support device reset and repurposing

The key concept is:

Autopilot transforms an OEM Windows installation into a business-ready corporate device.

Q2. How is Autopilot different from traditional imaging?

Traditional imaging

A traditional deployment may involve:

Windows Image
     ↓
Drivers
     ↓
Applications
     ↓
Configuration
     ↓
Capture/Deploy
     ↓
PC

The organization may need to maintain images for different hardware models.

Autopilot

OEM Windows
     ↓
Autopilot
     ↓
Microsoft Entra ID
     ↓
Intune
     ↓
Policies + Applications
     ↓
Business-ready device

The device does not need to be rebuilt with a custom corporate image for the standard Autopilot workflow.

Q3. What are the major Windows Autopilot deployment scenarios?

Important scenarios include:

• User-driven deployment
• Pre-provisioned deployment
• Self-deploying deployment
• Existing devices
• Autopilot Reset

Microsoft also documents Windows Autopilot device preparation as a newer Windows 11 deployment approach with a different provisioning experience.

Q4. What is Windows Autopilot user-driven mode?

User-driven mode allows the end user to receive a new corporate Windows device and complete the deployment themselves.

Typical workflow:

OEM ships device
       ↓
User turns on device
       ↓
Windows OOBE
       ↓
Internet connection
       ↓
Corporate authentication
       ↓
Microsoft Entra join
       ↓
Intune enrollment
       ↓
Policies + Applications
       ↓
Desktop

IT does not need to manually configure every device before shipping it to the user.

Microsoft documents user-driven mode for Microsoft Entra joined and Microsoft Entra hybrid joined scenarios, although Microsoft currently recommends cloud-native Microsoft Entra join for new deployments rather than new hybrid-join deployments.

Q5. What is Windows Autopilot pre-provisioned deployment?

Pre-provisioned deployment splits the provisioning process into two phases.

Technician phase

IT, an OEM or reseller prepares the device.

User phase

The end user completes the remaining deployment steps.

Conceptually:

                 Autopilot Pre-Provisioning

              Technician / OEM
                     ↓
          Device configuration
                     ↓
          Device applications
                     ↓
              Device ESP
                     ↓
              Hand over PC
                     ↓
                 End user
                     ↓
               User ESP
                     ↓
                  Desktop

This is useful when an organization wants the device to be substantially prepared before it reaches the employee.

Microsoft documents that pre-provisioned deployment splits the provisioning work between the technician/OEM/reseller phase and the end-user phase.

Q6. What is the difference between user-driven and pre-provisioned Autopilot?

The major difference is when the device provisioning work happens.

Q7. What is Windows Autopilot device preparation?

Windows Autopilot device preparation is a Windows 11 deployment technology designed to simplify and improve device provisioning.

It focuses on:

• Simpler deployment configuration
• Faster setup
• Improved troubleshooting
• Near real-time deployment reporting
• Enrollment-time grouping
• Application deployment
• PowerShell script deployment

Current Microsoft documentation lists Windows 11 requirements for device preparation and supports Microsoft Entra join rather than Microsoft Entra hybrid join.

Q8. How is Windows Autopilot device preparation different from traditional Windows Autopilot?

They solve a similar overall problem but use different deployment mechanisms.

Traditional Windows Autopilot

Uses concepts such as:

• Autopilot device registration
• Deployment profiles
• Deployment modes
• ESP
• Autopilot-specific configuration

Device preparation

Focuses on:

• A streamlined profile
• Enrollment-time grouping
• Applications
• PowerShell scripts
• Near real-time deployment reporting
• Simpler troubleshooting

Microsoft describes device preparation as an improved provisioning experience intended to be simpler, faster, more observable and more reliable.

Q9. What operating systems support Windows Autopilot device preparation?

Windows Autopilot device preparation is specifically a Windows 11 capability.

Microsoft currently documents support for:

• Windows 11 version 24H2 or later
• Windows 11 version 23H2 with the required update
• Windows 11 version 22H2 with the required update

It requires Microsoft Entra join for the documented device-preparation scenario.

Q10. What is the Windows Autopilot hardware hash?

The hardware hash is device-identification information used to register a physical device with Windows Autopilot.

It contains hardware-related information that allows the Autopilot service to recognize the device.

In a traditional manual registration scenario, hardware information can be collected and uploaded to the Autopilot service.

However, organizations commonly have the OEM or hardware reseller register devices on their behalf, which reduces administrative work.

Q11. How can devices be registered with Windows Autopilot?

Common approaches include:

OEM or reseller registration

The OEM or partner registers the device for the organization.

This is generally preferable for large-scale procurement.

Manual registration

IT can collect the required device information and import it.

Existing-device scenarios

Existing Windows devices can also be prepared for Autopilot through supported deployment workflows.

The objective is to associate the physical device with the organization’s Autopilot deployment process.

Q12. Why is OEM Autopilot registration preferred in large enterprises?

Imagine an organization purchasing:

5,000 laptops.

Manually collecting and uploading hardware information for every device creates unnecessary operational work.

A better process is:

Organization
     ↓
OEM / Reseller
     ↓
Autopilot registration
     ↓
Organization's tenant
     ↓
Device shipped directly
     ↓
Employee

This supports a true zero-touch deployment model.

Enrollment Status Page

Q13. What is the Enrollment Status Page?

The Enrollment Status Page, or ESP, is the Windows provisioning interface that shows the progress of device setup during supported deployment scenarios.

It can track the installation/configuration of:

• Applications
• Policies
• Security configuration
• Device setup components

It is particularly important during Windows Autopilot deployments.

Microsoft documents ESP troubleshooting around the policies, applications and tracking information received by the device.

Q14. What are the main phases of ESP?

Conceptually, ESP can be understood in terms of:

Device setup

The device is configured before the user can work with it.

Account setup

User-related configuration occurs after the user authenticates.

The exact behavior depends on the deployment scenario and ESP configuration.

For pre-provisioned deployment, Microsoft documents a device ESP phase followed by the user ESP phase.

Q15. A Win32 application is stuck during ESP. How would you troubleshoot it?

I would investigate the application rather than immediately disabling ESP.

Check:

1. Application assignment.
2. Installation context.
3. Detection rule.
4. Requirement rule.
5. Dependency.
6. Return code.
7. Installation command.
8. Whether the application actually installed.
9. Whether the detection rule correctly detects it.
10. Intune Management Extension logs.

Useful log locations include:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\

Important logs include:

IntuneManagementExtension.log
AgentExecutor.log
AppActionProcessor.log

If the application installed successfully but detection is incorrect, ESP can still appear stuck.

Q16. How do you troubleshoot an Autopilot ESP failure?

I would use a structured workflow.

Step 1 — Determine the phase

Is the failure during:

• Device preparation?
• Device ESP?
• User ESP?

Step 2 — Identify the failing item

Determine whether it is:

• Application
• Policy
• Script
• Enrollment
• Authentication
• Network

Step 3 — Check Intune

Review:

• Device status
• Policy status
• Application status
• Deployment report

Step 4 — Check the device

Use:

mdmdiagnosticstool.exe -out "C:\Temp\MDMDiagReport.zip"

Step 5 — Check logs

Review MDM and Intune Management Extension logs.

Step 6 — Check registry information

ESP stores relevant tracking information in the device registry, which can help identify what ESP is waiting for.

Q17. Why can a device appear stuck at ESP even though an application is installed?

Because installation success and detection success are separate things.

Example:

Application installed
       ↓
Detection rule runs
       ↓
Detection rule says "Not installed"
       ↓
Intune retries
       ↓
ESP waits

Therefore, when an application is apparently installed but ESP remains blocked, always inspect the detection rule.

Autopilot Deployment Troubleshooting

Q18. A new laptop starts Windows normally instead of showing the corporate Autopilot experience. What would you check?

I would check:

1. Is the device registered with Autopilot?
2. Is the hardware identity correct?
3. Is the device associated with the correct tenant?
4. Is the Autopilot profile assigned?
5. Is the device connected to the internet?
6. Is the Windows edition supported?
7. Is there a profile assignment delay?
8. Has the device been reset/reimaged correctly?
9. Is the device actually reaching the Autopilot service?

The first question is:

Does the service recognize the physical device as an Autopilot device?

Q19. An Autopilot profile exists but isn’t applied to the device. What would you investigate?

Check:

• Device group membership
• Dynamic group rules
• Autopilot registration
• Profile assignment
• Assignment filters
• Device association
• Synchronization/update timing
• Whether another deployment mechanism has precedence

Do not assume that creating a profile automatically means every device receives it.

Q20. What is the difference between an Autopilot profile and an Intune configuration profile?

An Autopilot deployment profile controls aspects of the Windows deployment/OOBE experience.

An Intune configuration profile configures Windows after enrollment according to the settings contained in that policy.

For example:

Autopilot profile:

• Deployment mode
• OOBE behavior
• User experience

Configuration profile:

• Windows settings
• Security settings
• Device configuration

They work together but have different purposes.

Q21. What is Windows Autopilot Reset?

Windows Autopilot Reset is designed to quickly prepare an existing Windows device for reuse while maintaining the organization’s management relationship.

It can be useful when:

• An employee leaves
• A device changes ownership
• A device is repurposed
• A device needs to be prepared for another user

The goal is to return the device to a managed state without performing the same manual provisioning process from scratch.

Q22. What is the difference between Autopilot Reset and a traditional Windows reimage?

A traditional reimage generally involves reinstalling Windows using an imaging or deployment process.

Autopilot Reset is designed to reset and repurpose a managed Windows device while preserving appropriate organizational management characteristics.

Therefore:

Traditional reimage
     ↓
Reinstall Windows
     ↓
Deploy image
     ↓
Install drivers/apps
     ↓
Configure

Autopilot Reset
     ↓
Reset device
     ↓
Preserve organizational management context
     ↓
Reapply managed configuration

The exact reset behavior depends on the selected reset/deployment scenario.

Existing Device Deployment

Q23. Can Windows Autopilot be used with existing devices?

Yes.

Microsoft documents an Autopilot for existing devices scenario where Configuration Manager can be used to install a fresh Windows OS before the Autopilot deployment process continues.

This is particularly useful when an organization wants to modernize an existing fleet.

Q24. When would you use Autopilot for existing devices?

A common scenario is:

Existing Windows PC
       ↓
Configuration Manager
       ↓
Fresh Windows installation
       ↓
Autopilot deployment
       ↓
Microsoft Entra / Intune
       ↓
Modern managed endpoint

This can help organizations transition from traditional imaging toward modern cloud-managed deployment.

Configuration Manager and Co-Management

Q25. What is co-management?

Co-management allows a Windows device to be managed concurrently by:

• Configuration Manager
• Microsoft Intune

The device has the Configuration Manager client and is enrolled into Intune.

The organization can then decide which management service should control particular workloads.

Microsoft describes co-management as a way to continue using existing Configuration Manager investments while gradually introducing cloud-based Intune management.

Q26. Why would an organization use co-management instead of immediately migrating everything to Intune?

Because large enterprises may already have:

• Thousands of Configuration Manager clients
• Complex application deployments
• Existing software packages
• Task sequences
• Patch-management processes
• On-premises dependencies
• Operational teams experienced with Configuration Manager

A gradual transition reduces operational risk.

For example:

Configuration Manager
        │
        ├── Applications
        ├── OS Deployment
        └── Some management
                │
                ▼
             Intune
        ├── Compliance
        ├── Conditional Access
        ├── Security
        └── Modern management

The organization can gradually move workloads as the environment becomes ready.

Q27. What are co-management workloads?

Co-management allows management responsibility for supported workloads to be moved between Configuration Manager and Intune.

The important concept is:

Enrollment into co-management does not automatically mean that every workload has moved to Intune.

Microsoft explicitly documents that organizations can control which workloads are switched from Configuration Manager to Intune.

Q28. Does enabling co-management automatically move all workloads to Intune?

No.

This is a very important interview point.

You can enroll devices into co-management while keeping workloads under Configuration Manager.

For example:

Co-managed device

Configuration Manager
 ├── Applications
 ├── Windows Update
 └── Other workloads

Intune
 ├── Compliance
 ├── Conditional Access integration
 └── Security policies

The actual workload ownership depends on the organization’s configuration.

Microsoft’s cloud-attach documentation explicitly notes that enrolling devices does not itself move workloads to Intune.

Q29. How would you migrate a large Configuration Manager environment to Intune?

I would not perform a “big bang” migration.

I would use phases.

Phase 1 — Assessment

Inventory:

• Devices
• Windows versions
• Applications
• GPOs
• Configuration Manager workloads
• Hardware
• VPN
• Certificates
• Security policies

Phase 2 — Cloud readiness

Establish:

• Microsoft Entra integration
• Intune enrollment
• Licensing
• Network connectivity
• Identity architecture

Phase 3 — Co-management pilot

Enroll a controlled group.

Phase 4 — Move selected workloads

For example:

Pilot
   ↓
Compliance
   ↓
Endpoint security
   ↓
Windows Update
   ↓
Applications
   ↓
Other workloads

Phase 5 — Expand

Move additional device groups.

Phase 6 — Decommission unnecessary legacy management

Only after validating that the replacement architecture works.

Q30. What is Cloud Attach?

Cloud attach is the broader concept of connecting an existing Configuration Manager environment to Microsoft cloud capabilities.

Microsoft currently describes three primary cloud-attach capabilities:

• Tenant attach
• Endpoint analytics
• Co-management

These can be enabled independently or together.

Q31. What is Tenant Attach?

Tenant attach connects Configuration Manager devices to the Microsoft Intune admin center for cloud-based visibility and management capabilities.

It allows administrators to access additional device information and actions from the cloud-based administration experience without immediately converting every device into an Intune-managed endpoint.

This makes tenant attach different from full co-management.

Q32. What is the difference between Tenant Attach and Co-management?

The key distinction:

Tenant attach extends Configuration Manager visibility and management into the cloud; co-management allows workloads to be shared between Configuration Manager and Intune.

Q33. What is the Cloud Management Gateway?

Cloud Management Gateway, or CMG, is a Configuration Manager cloud service that allows Configuration Manager clients on the internet to communicate with the Configuration Manager environment without requiring traditional VPN connectivity to the corporate network.

It can help support internet-based Configuration Manager management.

Microsoft lists CMG as an additional cloud feature associated with cloud-attached Configuration Manager environments.

Q34. Does CMG replace Intune?

No.

CMG and Intune solve different problems.

CMG

Extends Configuration Manager management to internet-based clients.

Intune

Provides cloud-native endpoint management through Microsoft cloud services.

An organization may use:

• Configuration Manager
• CMG
• Intune
• Co-management

depending on its architecture.

Co-Management Troubleshooting

Q35. A device is enrolled into Intune but isn’t showing as co-managed. What would you check?

I would verify:

1. Configuration Manager client exists.
2. Device is eligible for co-management.
3. Microsoft Entra identity is correct.
4. Automatic enrollment configuration.
5. Intune enrollment status.
6. Configuration Manager co-management settings.
7. Collection membership.
8. Client health.
9. Policy retrieval.
10. Logs.

I would also check whether stale or duplicate Microsoft Entra device records exist.

Microsoft specifically warns that stale device records can contribute to co-management enrollment failures.

Q36. A co-managed device receives an Intune policy, but Configuration Manager keeps changing the setting. What is the likely issue?

This is usually a management-authority conflict.

I would determine:

Which platform owns the workload?

If Configuration Manager owns the workload, it may continue configuring the setting.

If the workload has moved to Intune, Configuration Manager should no longer be the authority for that workload.

The solution is not simply to repeatedly reapply the Intune policy.

Q37. How would you troubleshoot a co-management workload that doesn’t appear to have moved?

Check:

1. Co-management enrollment.
2. Device eligibility.
3. Workload slider/configuration.
4. Pilot collection.
5. Device collection membership.
6. Policy refresh.
7. Configuration Manager client health.
8. Intune enrollment.
9. Device records.
10. Relevant logs.

Then compare:

Working co-managed device
        VS
Problematic co-managed device

The difference often identifies the problem faster than examining one device in isolation.

Q38. What is the importance of pilot collections in co-management?

Pilot collections allow administrators to test workload migration with a controlled population.

For example:

5,000 devices
      ↓
100 pilot devices
      ↓
Test Intune workload
      ↓
Validate
      ↓
500 devices
      ↓
2,000 devices
      ↓
5,000 devices

This reduces the risk of moving an entire enterprise workload incorrectly.

Advanced Enterprise Scenarios

Q39. Your company has 10,000 Configuration Manager devices and wants to adopt Intune. What architecture would you recommend?

I would consider a gradual cloud-transition architecture.

                Microsoft Entra ID
                       │
          ┌────────────┴────────────┐
          │                         │
       Intune                Configuration Manager
          │                         │
          └──────────┬──────────────┘
                     │
                Co-management
                     │
          ┌──────────┴──────────┐
          │                     │
      Intune-owned         CM-owned
      workloads            workloads
          │                     │
          └──────────┬──────────┘
                     │
                  Windows
                  Devices

I would:

1. Establish cloud identity.
2. Assess Configuration Manager workloads.
3. Enable cloud attach where appropriate.
4. Start co-management with a pilot.
5. Move workloads gradually.
6. Validate applications and security.
7. Monitor user experience.
8. Expand in controlled phases.
9. Retire unnecessary legacy dependencies only after successful migration.

Q40. A company wants all new laptops to be cloud-native but existing laptops must remain on Configuration Manager. How would you design this?

Use two lifecycle models.

New devices

OEM
 ↓
Autopilot
 ↓
Microsoft Entra join
 ↓
Intune
 ↓
Cloud-native endpoint

Existing devices

Configuration Manager
 ↓
Cloud Attach
 ↓
Co-management
 ↓
Gradual modernization

This avoids forcing an immediate migration of the entire installed base.

Microsoft currently recommends cloud-native Microsoft Entra join for new device deployments rather than creating new Microsoft Entra hybrid-joined deployments.

Q41. A user receives a new laptop and reports that deployment takes two hours. How would you investigate?

I would identify where the time is being spent.

Measure:

• Network connectivity
• Windows setup
• ESP
• Applications
• Policies
• PowerShell scripts
• Security configuration
• Windows updates

Then determine whether the bottleneck is:

Network
   OR
Application
   OR
Policy
   OR
Script
   OR
Authentication

I would use deployment reporting and local logs rather than guessing.

Windows Autopilot device preparation provides near real-time deployment information that can help identify application, script and deployment-time issues.

Q42. How would you reduce Autopilot deployment time for a large enterprise?

I would optimize the deployment architecture rather than simply increasing timeouts.

Review:

• Number of required applications
• Application dependencies
• Application installation context
• Large installers
• Detection rules
• PowerShell scripts
• Network bandwidth
• Security policies
• ESP configuration
• Device preparation strategy

I would also avoid installing unnecessary applications during the critical provisioning phase.

The principle is:

Only make the device wait for what is genuinely required before the user receives it.

Q43. A critical application fails during Autopilot but works after the device reaches the desktop. What would you investigate?

I would compare the deployment context.

Check:

• Device context vs user context
• Required vs available assignment
• Dependencies
• Detection rule
• Installation command
• Network availability during OOBE
• Authentication requirements
• User-specific dependencies
• ESP tracking

An application that requires an interactive user session may not behave correctly during the provisioning phase.

Q44. How would you design an Autopilot deployment for remote employees?

I would aim for a true cloud-based deployment.

OEM
 ↓
Autopilot registration
 ↓
Ship directly to employee
 ↓
Internet
 ↓
OOBE
 ↓
Corporate authentication
 ↓
Microsoft Entra
 ↓
Intune
 ↓
Security + Applications
 ↓
Production device

This minimizes dependency on:

• Corporate LAN
• Imaging servers
• Local deployment teams
• VPN during initial provisioning

For supported scenarios, this is one of the major benefits of cloud-based Windows deployment.

Q45. A remote employee cannot complete Autopilot because the device cannot reach the required services. What would you check?

I would investigate network connectivity first.

Check:

• Wi-Fi
• Ethernet
• Captive portal
• Proxy
• DNS
• Firewall
• SSL inspection
• Authentication
• Required Microsoft endpoints
• Device time/date

Autopilot is highly dependent on network connectivity during OOBE.

A device can have a perfectly valid Intune policy and still fail deployment if it cannot communicate with required cloud services.

Q46. How would you handle a failed Autopilot deployment without immediately wiping the device?

I would first collect evidence.

Check:

• Autopilot deployment status
• ESP
• Intune policy status
• Application status
• MDM diagnostics
• Intune Management Extension logs
• Event Viewer
• Registry ESP information
• Network connectivity

Useful command:

mdmdiagnosticstool.exe -out "C:\Temp\MDMDiagReport.zip"

Only after understanding the failure would I decide whether:

• Retry
• Reassign policy
• Correct application
• Correct configuration
• Reset
• Re-enroll
• Reimage

is appropriate.

Q47. How would you safely move a workload from Configuration Manager to Intune?

I would use a controlled migration process.

Step 1

Identify the current Configuration Manager workload.

Step 2

Create the equivalent Intune configuration.

Step 3

Test on pilot devices.

Step 4

Confirm the Intune policy works.

Step 5

Move the workload authority.

Step 6

Monitor for conflicts.

Step 7

Expand deployment.

Step 8

Retire the old Configuration Manager configuration only after successful validation.

This prevents a situation where both systems attempt to manage the same setting.

Q48. What is the biggest mistake administrators make during Intune and Configuration Manager migration?

One of the most common architectural mistakes is treating migration as:

“Move everything to Intune immediately.”

A better approach is to understand:

• Current workload ownership
• Dependencies
• Application architecture
• GPO dependencies
• Security controls
• Network dependencies
• User experience
• Device lifecycle

Then migrate in stages.

Q49. A company has 5,000 existing PCs and 1,000 new PCs arriving every year. How would you manage the lifecycle?

I would separate new-device deployment from legacy-device modernization.

New devices

Use:

OEM
 ↓
Autopilot / modern provisioning
 ↓
Microsoft Entra join
 ↓
Intune

Existing devices

Use:

Configuration Manager
 ↓
Cloud Attach
 ↓
Co-management
 ↓
Gradual workload migration

Retirement

Use:

Device retirement
 ↓
Data protection
 ↓
Management removal/reset
 ↓
Asset disposal

This creates a sustainable device lifecycle instead of repeatedly rebuilding machines.

Q50. As a senior Intune administrator, how would you design the complete Windows endpoint architecture for an enterprise?

I would divide the architecture into lifecycle stages.

1. Procurement

OEM registers supported devices for Autopilot where appropriate.

2. Deployment

New Windows devices use modern cloud-based provisioning.

OEM
 ↓
Autopilot / Device Preparation
 ↓
Microsoft Entra
 ↓
Intune

3. Security

Use:

• BitLocker
• Defender
• Firewall
• ASR
• Compliance
• Device-risk signals

4. Access

Use Microsoft Entra Conditional Access to enforce access requirements.

5. Legacy management

Existing Configuration Manager devices can use:

• Tenant attach
• Co-management
• CMG
• Gradual workload migration

6. Monitoring

Monitor:

• Deployment success
• Compliance
• Application failures
• Device health
• Security status
• User experience

7. Troubleshooting

Use:

• Intune reports
• Autopilot reports
• ESP logs
• MDM diagnostics
• Intune Management Extension logs
• Configuration Manager logs
• Microsoft Entra sign-in logs

8. Lifecycle

Finally:

Procure
   ↓
Deploy
   ↓
Secure
   ↓
Manage
   ↓
Monitor
   ↓
Troubleshoot
   ↓
Repurpose
   ↓
Retire

That is the level of thinking expected from a senior endpoint administrator.

Important Commands and Troubleshooting Tools

Collect Windows MDM Diagnostics

mdmdiagnosticstool.exe -out "C:\Temp\MDMDiagReport.zip"

Generate Group Policy Report

gpresult /h C:\Temp\gpresult.html

Check Microsoft Entra Registration

dsregcmd /status

Important sections include:

AzureAdJoined
DomainJoined
WorkplaceJoined
DeviceAuthStatus
AzureAdPrt

Example:

dsregcmd /status

For troubleshooting hybrid/cloud identity and enrollment, this command is one of the most useful local diagnostic tools.

Intune Management Extension Logs

Typical location:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\

Useful logs include:

IntuneManagementExtension.log
AgentExecutor.log
AppActionProcessor.log

Real-World Production Decision Tree

When a Windows deployment fails, use this sequence:

                 Windows Deployment Failure
                           │
                           ▼
                 Is device registered?
                      /          \
                    No            Yes
                    │              │
             Fix Autopilot       ▼
             registration    Profile assigned?
                              /          \
                            No            Yes
                            │              │
                       Fix assignment     ▼
                                  Network connectivity?
                                     /          \
                                   No            Yes
                                   │              │
                              Fix network         ▼
                                           Enrollment works?
                                            /          \
                                          No            Yes
                                          │              │
                                    Identity/MDM       ▼
                                    troubleshooting   ESP
                                                     /   \
                                                   Fail  Pass
                                                    │     │
                                                    ▼     ▼
                                               Identify   Desktop
                                               policy/
                                               app/script
                                                    │
                                                    ▼
                                               Remediate

Quick Revision

Windows Autopilot

• Cloud-based Windows deployment technology
• Uses OEM Windows installation
• Reduces dependence on traditional imaging
• Supports deployment, reset and repurposing scenarios
• Can integrate with Intune and Microsoft Entra ID

User-Driven Deployment

OEM
 ↓
OOBE
 ↓
User authentication
 ↓
Microsoft Entra
 ↓
Intune
 ↓
Policies + Apps
 ↓
Desktop

Pre-Provisioned Deployment

OEM / IT
 ↓
Device preparation
 ↓
Device ESP
 ↓
End user
 ↓
User ESP
 ↓
Desktop

Device Preparation

• Windows 11
• Streamlined provisioning
• Enrollment-time grouping
• Application deployment
• PowerShell scripts
• Improved reporting
• Microsoft Entra join scenario

ESP Troubleshooting

Check:

• Application
• Detection rule
• Policy
• Script
• Network
• MDM diagnostics
• Registry
• IME logs

Co-Management

Configuration Manager
        +
      Intune
        ↓
  Co-managed Device

Co-management does not automatically move all workloads to Intune.

Cloud Attach

Primary capabilities include:

• Tenant attach
• Endpoint analytics
• Co-management

Migration

Never start with:

“Move everything immediately.”

Instead:

Assess
 ↓
Pilot
 ↓
Validate
 ↓
Move workload
 ↓
Monitor
 ↓
Expand
 ↓
Retire legacy dependency

Exam Answer Summary

1. What is Windows Autopilot?

Windows Autopilot is a cloud-based Windows deployment technology that configures OEM-installed Windows devices into business-ready corporate devices without requiring traditional custom imaging for the standard deployment workflow.

2. What is user-driven Autopilot?

It allows the end user to complete the Windows deployment while Intune and Microsoft Entra automatically apply the organization’s configuration.

3. What is pre-provisioned Autopilot?

It splits device provisioning between an IT/OEM/reseller technician phase and an end-user phase.

4. What is Windows Autopilot device preparation?

It is a Windows 11 provisioning technology designed to simplify deployment, improve deployment visibility and streamline the delivery of applications, scripts and configuration.

5. What is ESP?

Enrollment Status Page is the Windows provisioning experience that tracks important device and user setup operations during supported deployment scenarios.

6. What is co-management?

Co-management allows Windows devices to be managed concurrently by Configuration Manager and Intune, with supported workloads assigned to the appropriate management service.

7. Does enrolling a device into co-management automatically move all workloads to Intune?

No. Workload ownership is configured separately.

8. What is Tenant Attach?

Tenant Attach connects Configuration Manager devices to the Microsoft Intune admin center for cloud-based visibility and management capabilities.

9. What is Cloud Attach?

Cloud Attach is the broader Configuration Manager cloud integration model that includes capabilities such as Tenant Attach, Endpoint Analytics and Co-management.

10. What is CMG?

Cloud Management Gateway extends Configuration Manager management capabilities to internet-based clients.

11. How should an enterprise migrate from Configuration Manager to Intune?

Assess the existing environment, establish cloud readiness, pilot co-management, migrate workloads gradually, validate application and security dependencies, monitor the results, and retire unnecessary legacy dependencies only after successful migration.

Senior Interview Tip

If the interviewer asks:

“You have 10,000 Configuration Manager devices and management wants to move to Intune. What would you do?”

Do not answer:

“I would enroll all devices into Intune.”

A stronger senior-level answer is:

“I would first assess the existing Configuration Manager environment, including applications, GPOs, software deployment, Windows Update, security policies and on-premises dependencies. I would cloud-attach the environment where appropriate, establish a co-management pilot, and move workloads in controlled phases rather than attempting a big-bang migration. For new devices, I would use a modern cloud-native deployment model such as Windows Autopilot with Microsoft Entra join and Intune. I would monitor deployment success, compliance, application compatibility and user experience throughout the migration.”

That answer demonstrates understanding of architecture, migration strategy, risk management and lifecycle management, rather than simply knowing Intune portal options.

Completion Status: Microsoft Intune

Part 1

Intune Fundamentals, Enrollment & Device Management

Covered:

• MDM/MAM
• Enrollment
• Microsoft Entra Join
• Hybrid Join
• Device ownership
• Primary users
• Company Portal
• Windows enrollment
• Device management fundamentals

Part 2

Configuration Profiles, Settings Catalog, Security Baselines & Policy Troubleshooting

Covered:

• Configuration profiles
• Settings Catalog
• CSP
• OMA-URI
• Security Baselines
• Assignments
• Filters
• Applicability
• Conflicts
• Troubleshooting

Part 3

Application Management, Win32 Apps, Microsoft Store Apps & Troubleshooting

Covered:

• Win32 applications
• .intunewin
• Detection rules
• Requirements
• Dependencies
• Supersedence
• Installation context
• Return codes
• Intune Management Extension
• Microsoft Store applications
• Application troubleshooting

Part 4

Compliance, Device Security, BitLocker, Defender & Conditional Access

Covered:

• Compliance
• Actions for noncompliance
• Device risk
• Defender for Endpoint integration
• Conditional Access
• BitLocker
• TPM
• Recovery keys
• Defender Antivirus
• Windows Firewall
• ASR
• Security architecture
• Production security scenarios

Part 5

Windows Autopilot, Windows Deployment, Co-Management & Advanced Production Scenarios

Covered:

• Windows Autopilot
• User-driven deployment
• Pre-provisioned deployment
• Windows Autopilot device preparation
• Hardware registration
• Enrollment Status Page
• ESP troubleshooting
• Autopilot Reset
• Existing-device deployment
• Configuration Manager
• Co-management
• Workload ownership
• Cloud Attach
• Tenant Attach
• Cloud Management Gateway
• Configuration Manager → Intune migration
• Enterprise deployment architecture

Completed

Microsoft Intune interview preparation is now complete.

← Previous Part: [Part 4: Compliance, BitLocker, Defender & Conditional Access] | Complete Series: [Microsoft Intune Interview Questions & Answers – Complete Series]

The next interview should move to the next major enterprise technology area rather than repeating Intune concepts.

Official Microsoft Intune Documentation

For the latest Microsoft Intune documentation, supported capabilities and current configuration guidance, refer to Microsoft Learn.

Microsoft Intune Documentation:
https://learn.microsoft.com/en-us/intune/

Microsoft’s documentation is the authoritative source for current Intune capabilities because enrollment methods, supported platforms, policies and management features can change over time. (Microsoft Learn)