# User-driven Mode vs. Self-deploying Mode ### **User-driven mode** - Devices with this profile are associated with the user enrolling the device, and user credentials are required to enroll the device. That user becomes the primary user, which is what enables self-service features later (BitLocker key recovery, “reset my PIN,” etc.). - Supports **both** Microsoft Entra join and Microsoft Entra hybrid join — the hybrid-join path being relevant if you’re still tied to on-prem AD for anything, though Microsoft recommends deploying new devices as cloud-native using Entra join rather than hybrid join going forward. - Full OOBE customization is available — language, privacy settings, EULA, “change account” visibility, etc. all remain configurable. - The Account Setup (User ESP) phase runs, because there’s an actual user to authenticate and set up — this is the phase where your Okta federation comes into play, since that’s where the user’s credential prompt happens. ### **Self-deploying mode** - No user is associated with the device and no user credentials are required — the device provisions itself with zero human interaction beyond powering it on and connecting to a network. In the deployment profile UI, this shows up as most OOBE options being greyed out because there’s no user-facing sign-in to customize. - Requires **no interaction from user or admin/OEM/reseller**, but in exchange it has hard requirements: it only works on physical devices with a supported TPM 2.0 and device attestation capability — it does not work in VMs, even with a virtual TPM, since a real hardware TPM attestation is required. - **Only supports Microsoft Entra join** — it explicitly doesn’t support Microsoft Entra hybrid join devices. If any of your machines need to stay hybrid-joined to on-prem AD (for legacy file share auth, GPO holdovers, etc.), self-deploying is off the table for those. - Because there’s no assigned user, the User ESP phase doesn’t run at all — only the device-level provisioning phases execute. - Intended for kiosks, digital signage, and shared/lab devices — not for a machine that will have one dedicated owner. ## For Our Setup Given you’re migrating staff/faculty machines off Altiris and identity runs through Okta, **user-driven is almost certainly your default** for anything with a dedicated primary user — that’s the mode where Okta’s federated sign-in actually gets exercised during OOBE, and it’s what gives end users self-service recovery options later. Self-deploying only makes sense for a narrow slice: shared lab computers, kiosks in common areas, or any machine that’s genuinely not tied to one person — and even then, only if those machines are staying Entra-joined rather than hybrid-joined, and have a real TPM 2.0 chip (which any reasonably modern device should). # Verify Test Device and Set a Group Tag The very first thing to do is **confirm it, then tag it**, so everything downstream (dynamic group → deployment profile) can actually find it. #### **Step 1: Verify the device and set a Group Tag** 1. Sign into the Microsoft Intune admin center. 2. **Devices → Windows → Enrollment** (under “Device onboarding”) **→ Devices** (under the Windows Autopilot section). 3. In the search box, look up `CLHL7C3` (or its serial number) and confirm it shows up in the Autopilot devices list. This is a separate confirmation from “hash upload succeeded” — you want to actually see it as a registered object here, since occasionally there’s a lag between upload and the device appearing. 4. Select the device, open its properties pane, and set a **Group Tag** — something like `pilot-test` or `autopilot-pilot` works fine for a one-off test machine. Save it. >[!question] Why this is the **right** first move: >Group Tags map to the device’s `OrderID` attribute in Entra ID, which is exactly what a dynamic device group query matches against — so this tag is what determines whether your test device lands in a group that has anything (deployment profile, apps, policies) assigned to it. Skip this step and the device just sits registered with nothing happening to it when you boot it. #### Step 2: Create a dynamic device group targeting the `pilot-test` (or some other) tag 1. In the Intune admin center, go to **Groups → New group**. 2. Configure: - **Group type:** Security - **Group name:** something clear, e.g. `Autopilot - Pilot Test (pilot-test)` (etc.) - **Microsoft Entra roles can be assigned to the group:** No - **Membership type:** Dynamic Device 3. Click into the **dynamic membership rule** editor and use this rule: ```bash (device.devicePhysicalIds -any (_ -eq "[OrderID]:pilot-test")) ``` - This matches on the Group Tag you just set — Group Tags map to the device’s `OrderID` attribute in Entra ID, which is what this query is reading. 4. Save the group. Give it a few minutes to evaluate membership — dynamic group rules aren’t instant. Once it’s created, we’ll go check that `CLHL7C3` (or whatever your machine is called) actually shows up as a member before moving on to assigning your deployment profile to this group. Once you can see the device in the group . . . #### Step 3: Assign your deployment profile to this group If you do not yet have a deployment profile to use, we need to build one. #### Step 1: Start the profile and fill in Basics 1. In the Intune admin center: **Devices → Windows → Enrollment → Deployment Profiles**. 2. Click **Create profile → Windows PC**. 3. On the **Basics** page: - **Name:** something clear and reusable, e.g. `SEU - Pilot User-Driven` (naming it by scenario now saves confusion later when you have several profiles) - **Description:** optional, but worth a line like “Test profile for Altiris migration pilot” 4. Click **Next**. You’ll land on the **Out-of-box experience (OOBE)** page next — that’s where the user-driven vs. self-deploying decision and the “Convert all targeted devices to Autopilot” setting live, which we’ve already talked through. We’ll fill that in as the next step once Basics is saved. ![[Pasted image 20261028165136.png]] ***Worth considering:*** **Apply device name template: No** — currently off. This is worth thinking about for your production rollout (a template like `SEU-%SERIAL%` keeps device names consistent and searchable in Intune later), but for this one pilot machine it’s not important — leave it off for now since `CLHL7C3` already has a usable name. Go ahead and click **Next** to move to the **Assignments** tab, and let me know what you see there — that’s where we’ll point this profile at your `pilot-test` group #### Step: Assign the profile to your pilot group 1. Under the assignment section, you’ll see an option to include groups — something like **“Select groups to include”** (there’s usually an “Add group(s)” or similar control). 2. Select the dynamic group you created earlier — the one built on the `pilot-test` Group Tag rule (the one you confirmed `CLHL7C3` is a member of). 3. Leave **Exclude** empty — nothing to exclude for a single-device pilot test. **A couple of things worth checking on this screen before you move on:** - If there’s an assignment type toggle (some tenants show options like targeting **all devices** vs. specific groups), make sure you’re on the “assign to selected groups” path rather than “all devices” — you don’t want this test profile accidentally scoped tenant-wide. - Double check you’re selecting the right group by name if you have multiple similarly-named groups floating around from earlier steps. Once your pilot group is added under Included groups, click **Next** to land on **Review + create**, where we’ll do a final sanity check of everything (Basics + OOBE + Assignment) before you hit Create. ![[Pasted image 20261028165355.png]] **After it’s created**, here’s what to expect and check next: 1. It can take a little while for Intune to actually push the profile assignment down to the device — this isn’t instant. The assignment time varies depending on Entra ID group membership evaluation, the device’s hash record, and sync timing between Intune and the Autopilot service. 2. Once it’s had time to process, go back to **Devices → Windows → Enrollment → Devices**, find `CLHL7C3`, and check the **Profile status** column — it should flip from “Not assigned” to something like “Assigning” and eventually “Assigned.” That’s your confirmation the profile actually reached the device record before you go attempt an OOBE run on the physical machine. ***What to actually check now:*** Go back to **Devices → Windows → Enrollment → Devices**, search for `CLHL7C3`, and look at the **Profile status** column. Right now it’ll most likely still show **“Not assigned”** or maybe **“Assigning”** — that’s expected and fine. Don’t attempt an OOBE reset on the physical machine yet. Give it a bit — could be a few minutes, could be longer depending on your tenant’s sync cadence — and check back periodically. Once it flips to **“Assigned,”** that’s your green light to actually boot/reset the physical device and walk through OOBE for real. **Once the device's *Profile Status* flips to *Assigned*, that's the green light to actually boot/test the physical device and would through OOBE.** At some point during the OOBE process, you should be able to enter your *work/school email address*. **What should happen next:** 1. After you type the email and hit next/continue, since your identities are federated through Okta, you should get **redirected away from the generic Microsoft sign-in box to an Okta-branded login page**. 2. Log in there with your normal Okta credentials, and complete MFA if prompted (Okta Verify push, code, etc.) — this is worth paying attention to, since it’s one of the trickier moments in this flow to get right. 3. Once Okta authenticates you, it hands control back to the Windows setup process to finish Entra join and kick off MDM enrollment into Intune. **Step: Confirm enrollment on both sides** 1. **On the physical device:** open **Settings → Accounts → Access work or school**. You should see your university account listed there as connected, with something like “Connected to [tenant] Azure AD.” Click it and select **Info** — there should be a “Sync” button and details showing it’s managed. 2. **Back in the Intune admin center**, pull up that same Autopilot device record we were checking earlier (**Devices → Windows → Enrollment → Devices**, search `CLHL7C3`). Compare it to before — a few fields should now be populated that were previously blank: - **User:** should now show your account instead of “unassigned” - **Enrollment state:** should now say something like “Enrolled” instead of “Not enrolled” - **Associated Intune device:** should now show an actual device entry instead of “N/A” 3. Also worth a quick look at **Devices → All devices** (the general Intune device list, not the Autopilot-specific one) — `CLHL7C3` should show up there too now, with a compliance state and last check-in time. ![[Pasted image 20261028165932.png]]