Autopilot for a Split Hybrid and Cloud-Only Fleet Shipped to Home Users
Northwind Traders is replacing 900 laptops with Windows 11. 320 users still need Kerberos access to an on-premises ERP and file shares, so those devices must be Microsoft Entra hybrid joined; the other 580 will be cloud-only. Every device ships directly to the employee's home, and VPN is only available after the user has signed in. The on-premises team can host a Windows Server 2022 member server with outbound internet access. A pilot showed hybrid devices sitting on 'Please wait while we set up your device' for 45 minutes, and the static Autopilot device group had to be cleaned up manually after every re-image. Procurement puts a unique purchase-order number on each order, and that number is what lands in the Autopilot record's group tag field.
1. What must be built and verified so the 320 hybrid devices can complete Autopilot from home, and what is your first diagnostic step when one fails?
Read the worked answer
Build:
- At least two instances of the Intune Connector for Active Directory, on internal member servers, published so devices can reach them over HTTPS 443 (normally via a reverse proxy). Two gives you HA and throughput for 320 devices.
- A Domain Join profile (target OU, computer-name prefix) assigned to the hybrid devices only.
- Confirm the target OU is inside the Entra Connect sync scope and that the connector service account can create objects there.
Why this works with no VPN: the connector performs the offline domain join on the device's behalf. The laptop never needs line of sight to a domain controller; it needs the connector, and the connector needs LDAP/Kerberos to the DCs.
First diagnostic step: check whether a computer object was created in the target OU.
- No object -> connector unhealthy, connector unreachable from the internet, or OU permission problem.
- Object created but Entra join failed -> the device's own path, the deployment profile (cloud-only profile applied by mistake), or a stale record from a previous enrollment.
Also verify the connector shows Healthy in the portal and that no proxy is intercepting the connector URL.
2. Replace the manual Autopilot group with dynamic membership and explain what you would and would not assign to it.
Read the worked answer
Rule: group tag populates the OrderID value in devicePhysicalIds, so a dynamic device rule of the form (device.devicePhysicalIds -any _ -eq "[OrderID]:<tag>") makes the device join automatically.
Assign to this group: the Autopilot deployment profile, the Enrollment Status Page profile and the Domain Join profile. Those are the things that must apply during OOBE, and re-imaging then re-registering a device re-adds it with no manual cleanup.
Do not assign to this group: compliance policies, configuration profiles, apps and Conditional Access. The Autopilot group only describes how a device is deployed, it says nothing about what a device is. Keep those assignments on broader Entra groups (department, role, licensing) so policy survives the day the device is renamed, re-tagged, or deleted from Autopilot.
Judgement on timing: dynamic membership is not instant. For a 900-device wave, import the hardware hashes and let the group evaluate before you ship, otherwise the first boot finds no deployment profile and falls back to manual OOBE.
3. Choose Enrollment Status Page settings for home workers and justify the trade-offs you are making.
Read the worked answer
Settings:
- Block device use until only the small set of things that must exist before the user can work: the VPN client, the security agent, and any device certificate profile. Do not block on Office or optional LOB apps.
- Turn on Allow users to reset the device if installation fails, and set the timeout to something like 60 minutes rather than the default.
- Track device-targeted apps in the device phase and user-targeted apps in the account phase.
Trade-offs:
- Every app you add to the blocking list is a new way for a home worker with a slow link to hit a dead end. A 45-minute hang is usually one large required app in the blocking phase on a consumer connection.
- System-context (device-targeted) apps install before sign-in and can be tracked in the device phase; user-targeted apps cannot, because there is no user yet. Mixing them is the most common cause of an ESP that appears stuck.
- Do not set the timeout so low that a genuinely slow install triggers a reset loop; do not set it so high that a broken device sits at OOBE half the day. 60 minutes with reset enabled lets the user self-recover.
- Non-blocking failures still get reported on the ESP; use them for triage without blocking the user.