Windows Device Provisioning & Lifecycle SOP

Microsoft Entra ID · Windows Autopilot · Microsoft Intune

Published

2026-04-23

Keywords

Windows, Autopilot, Intune, Entra ID, BitLocker, Zoom Rooms, Provisioning

Document classification: Internal — Xenter, Inc. IT Operations. Supersedes: N/A (first controlled release). Scope of change review: Any change to Autopilot profile, ESP, compliance policy, or the USB provisioning script requires a review of this SOP.

1 Executive Summary

This Standard Operating Procedure defines how the Xenter IT team issues, provisions, ships, supports, resets, reassigns, and retires Windows laptops and conference room devices. It is written for a remote-first IT team of two to four technicians who rarely touch a device after shipment. The procedure is grounded in the attached windows-provisioning repository (primary script Start-XenterProvision.ps1), current Microsoft Learn guidance, and the specific identity model in use at Xenter: Microsoft Entra joined, Microsoft Intune managed, classic Windows Autopilot. Two deployment modes are used within classic Autopilot: pre-provisioned deployment for user laptops (Technician Flow run by IT, User Flow run by the employee) and self-deploying mode for conference-room endpoints (the device signs itself in via TPM attestation; no user is assigned).

The document has two layers. The first is the current-state procedure — what the team does today with the USB-based OOBE script and the Intune portal. The second is a set of labelled recommendations that formalize the two classic Autopilot sub-scenarios Xenter uses, add conference-room-specific compliance baselines, and tighten validation gates before shipment.

The operating principle behind both layers is the same: every failure that reaches a remote end user is expensive. A 20-minute validation step in the IT room is almost always cheaper than a replacement shipment, a remote reset, or a support session with a user who is not at a desk. This SOP is optimized for that asymmetry.

ImportantNon-negotiable gates before any device ships
  1. Autopilot hardware hash is uploaded and the device is visible in Intune under Devices › Enrollment › Windows › Windows Autopilot Devices.
  2. Autopilot deployment profile is assigned to the device, not merely created.
  3. Hostname matches the corporate convention XMD-<serial>.
  4. BitLocker is either enabled with a recorded recovery key, or explicitly waived with a logged reason (VMs, missing TPM).
  5. The provisioning log at C:\ProgramData\Xenter\Provisioning\provision-<serial>.log is reviewed for warnings.

A device that fails any of these gates is held, not shipped.

2 Purpose

The purpose of this SOP is to:

  • standardize the provisioning, enrollment, and baseline configuration of Windows devices across both user-laptop and conference-room profiles;
  • reduce the volume and severity of post-shipment failures for remote employees;
  • give technicians explicit decision logic for the most common and most damaging failure modes (Autopilot registration, profile assignment, Intune enrollment, ESP timeout, broken user profile, BitLocker key escrow);
  • define a repeatable recovery and reassignment pathway that does not depend on physical access to the device;
  • establish the validation and documentation evidence required before a device is authorized to ship.

This SOP is the authoritative operational reference for Windows device provisioning at Xenter. It does not replace the Microsoft documentation it cites; it adapts that documentation into internal procedures specific to the Xenter environment.

3 Scope

In scope.

  • Windows 11 laptops issued to individual Xenter employees (user laptop profile).
  • Windows 11 small form factor desktops deployed as single-purpose Zoom Rooms endpoints (conference room profile).
  • All stages of the Windows device lifecycle: intake, provisioning, validation, shipment, first-boot support, ongoing management, reset, reassignment, and retirement.
  • Both the current-state USB-based OOBE workflow powered by Start-XenterProvision.ps1, and the future-state recommendations that formalize classic Autopilot pre-provisioned deployment for user laptops and self-deploying mode for conference-room devices.

Out of scope.

  • macOS and Linux endpoints (separate SOPs).
  • Mobile devices (iOS, Android) enrolled through Intune MAM/MDM.
  • On-premises Active Directory domain-joined devices or hybrid-join scenarios. Xenter devices are Microsoft Entra joined only.
  • Server operating systems (Windows Server, Azure VMs) — managed under a separate infrastructure SOP.
  • FedEx account administration beyond the shipment steps explicitly defined in Section 9.

4 Assumptions

The procedures in this document assume the following environment. Where any assumption is invalidated, the relevant step must be revisited before a device is shipped.

  1. Identity model. Devices are Microsoft Entra joined. Users authenticate with their @xenter.io (or equivalent) work account. No on-premises AD credentials are issued.
  2. MDM. Microsoft Intune is the sole MDM. Autopilot profiles, compliance policies, configuration profiles, apps, and update rings are all authored in Intune.
  3. Autopilot generation in use. Xenter uses classic Windows Autopilot in two sub-scenarios: pre-provisioned deployment for user laptops (Technician Flow at the bench, User Flow at first power-on) and self-deploying mode for conference-room endpoints (the device signs itself in via TPM 2.0 attestation; no user is assigned). Hardware hashes are uploaded per device via the USB script. Windows Autopilot Device Preparation (v2) is explicitly not adopted. Microsoft has confirmed classic Autopilot and Device Preparation will coexist and that the first release of Device Preparation does not include self-deploying or pre-provisioned deployment — the two modes Xenter depends on (Windows Autopilot device preparation overview, last verified 2026-04-23). See Section 17.1 for the full rationale.
  4. Device naming. Every device is named XMD-<serial>, where <serial> is the BIOS serial number read from Win32_BIOS. The 15-character NetBIOS limit is enforced by truncation inside Set-ComputerNameFromSerial.
  5. Bitwarden holds the FedEx corporate account credentials. Only members of the IT team with the “FedEx” Bitwarden collection share may initiate a shipment.
  6. USB provisioning media is prepared per the README.md in the windows-provisioning repository. The .env file at the USB root is populated before any device is touched.
  7. IT team has Intune Administrator (or a tightly scoped equivalent custom role) and the Cloud Device Administrator Microsoft Entra role at minimum, sufficient to register Autopilot devices, manage device objects, and retrieve BitLocker recovery keys.
  8. Compliance policy exists for user laptops. Conference room devices currently inherit the same compliance policy — this is an open gap documented as a Risk in Section 18.
  9. Network assumption during provisioning. The provisioning bench has wired Ethernet with outbound access to login.microsoftonline.com:443, graph.microsoft.com:443, and the Microsoft Update endpoints. Wi-Fi is not used on the bench; it is unreliable inside OOBE.

5 Definitions and Key Terms

Term Definition
Microsoft Entra ID Microsoft’s cloud identity directory (formerly Azure AD). The source of user, group, and device identity at Xenter.
Microsoft Intune The MDM service used to enforce configuration, compliance, apps, and updates on Xenter devices.
Windows Autopilot (classic / v1) The existing Autopilot deployment service. Requires a registered hardware hash per device. This is what the current Start-XenterProvision.ps1 script uses.
Windows Autopilot Device Preparation (v2) Re-architected Autopilot that removes the hardware hash upload step and uses Enrollment Time Grouping. Only supports Entra join and user-driven or Windows 365 automatic modes — does not support self-deploying or pre-provisioned deployment. Not adopted at Xenter; see Section 17.1. (Windows Autopilot device preparation overview, last verified 2026-04-23).
Self-deploying mode (classic Autopilot) Classic Autopilot deployment mode for kiosk, shared, and digital-signage devices. The device signs itself in via TPM 2.0 attestation; no user is assigned and no interactive sign-in is used during enrollment. Requires physical hardware with TPM 2.0 + device attestation and Microsoft Entra join. VMs are not supported. Used at Xenter for conference-room endpoints. (Windows Autopilot self-deploying mode workflow, last verified 2026-04-23).
Pre-provisioned deployment (classic Autopilot) Classic Autopilot deployment mode that splits enrollment into a Technician Flow (run by IT/OEM/reseller at the bench — installs device-targeted apps and policies, starts BitLocker, joins Entra) and a much shorter User Flow (run by the end user at first power-on — signs in, applies user-targeted apps and policies). Requires TPM 2.0 + device attestation, physical hardware, and an ESP profile. Used at Xenter for all user laptops. (Autopilot scenarios, last verified 2026-04-23).
Hardware hash A ~4 KB identifier derived from the device’s TPM, firmware, network, and CPU attributes. Used by classic Autopilot to recognize the device during OOBE. Collected by Get-HardwareHash in the current script via MDM_DevDetail_Ext01.
Autopilot deployment profile An Intune profile that tells Autopilot how to set up the device (user-driven, deployment mode, naming template, OOBE skip options). It must be assigned to the device — either directly or via a group — before OOBE starts, or the device will not pick it up.
ESP (Enrollment Status Page) The Windows screen that shows provisioning progress during first sign-in. Tracks device setup (policies, certs, Wi-Fi, apps) and account setup (user-targeted policies and apps). Default timeout is 60 minutes. (Set up the Enrollment Status Page, last verified 2026-04-23).
Group tag / OrderID Intune-managed metadata stamped onto the Autopilot device record. Maps to the Entra device devicePhysicalIds attribute as [OrderID]:<value>. Used for dynamic-group targeting. (Create device groups for Windows Autopilot, last verified 2026-04-23).
Device code flow OAuth 2.0 flow used by Get-GraphAccessToken when no CLIENT_SECRET is present — the IT technician authenticates on a second device using a code shown on the laptop screen.
Autopilot Reset An in-place “prepare for next user” reset. Removes personal files, apps, settings. Preserves Entra join, Intune enrollment, and a subset of device-targeted configuration. Does not format the drive. (Overview of Windows Autopilot, last verified 2026-04-23).
Wipe (Intune remote action) A true factory reset. Can optionally retain enrollment and the primary user. Causes the OS to redeploy. Appropriate for lost, stolen, or compromised devices. (Encrypt Windows devices with BitLocker using Intune, last verified 2026-04-23).
Fresh Start An Intune action that reinstalls Windows while optionally retaining user data. Removes Win32 apps and (by default) MDM policies. Rarely appropriate for Entra-joined Autopilot-managed devices. Use Autopilot Reset or Wipe instead in most cases.
Shared PC mode A Windows CSP that turns a device into a multi-user machine with aggressive profile cleanup. Candidate for conference room devices but only relevant if the room device supports personal user sign-in. Currently not the chosen model for Xenter Zoom Rooms (see Section 18).

6 Roles and Responsibilities

The team operating this SOP is small. Roles are defined as functional roles — one physical technician may hold several of them.

  • Provisioning Technician — receives devices, runs Provisioning.bat, validates output, records BitLocker recovery keys, packages and ships.
  • Intune Administrator — authors and maintains Autopilot profiles, compliance policies, configuration profiles, app assignments, ESP profiles, and update rings. Owns the Intune portal configuration that this SOP depends on.
  • Identity Administrator — manages the App Registration used by the provisioning script (see docs/azure-ad-app-registration.md), rotates CLIENT_SECRET on schedule, and maintains the dynamic security groups used for Autopilot and conference room targeting.
  • Remote Support Technician — first point of contact for a user whose setup fails. Owns Remote Help sessions, drives remote recovery, and decides when to escalate to replacement.
  • IT Lead / Escalation Owner — reviews incidents where a device is disqualified from shipment, a remote recovery has failed twice, or a compliance signal is lost for more than 24 hours.

6.1 RACI Matrix

Key: R = Responsible, A = Accountable, C = Consulted, I = Informed.

Activity Prov. Tech Intune Admin Identity Admin Remote Support IT Lead
Receive device and verify purchase order R I I I A
Run Provisioning.bat during OOBE R C I I A
Upload hardware hash to Autopilot R A I I I
Assign Autopilot profile I R/A I I I
Maintain Autopilot / ESP / compliance policies I R/A C I C
Validate pre-shipment checklist R C I I A
Package and ship via FedEx corporate account R I I I A
Support user first boot I C I R A
Remote reset / Autopilot Reset I C I R A
Full wipe / replacement decision I C I R A
Reassignment of returned hardware R C I C A
Quarterly SOP review C C C C R/A

7 Device Profiles and Supported Use Cases

Two Windows device profiles are in scope. Every device issued by Xenter IT must map to exactly one of them before it leaves the provisioning bench. The profile drives the Autopilot group tag, the Intune dynamic group membership, the compliance baseline, and the apps that land on the device.

7.1 User Laptop Profile

  • Hardware class. Business laptops (HP, Dell, Lenovo) with TPM 2.0, UEFI, and a supported Windows 11 Pro or Enterprise image preinstalled.
  • Assignment model. One user, one device, one primary assignment in Intune. The user is the primary user for OneDrive/Outlook cache sizing and for BitLocker self-service recovery.
  • Enrollment mode. Classic Windows Autopilot, pre-provisioned deployment (Microsoft Entra join). IT completes the Technician Flow at the bench; the user runs the shorter User Flow at first power-on. A user may optionally be pre-assigned to the Autopilot record for UPN pre-fill and greeting — this does not control which apps or policies deploy (User-driven Microsoft Entra join workflow, last verified 2026-04-23).
  • Baseline delivered by the USB script. Hostname, timezone, bloatware removal, Wi-Fi profile, wallpaper/lockscreen via PersonalizationCSP, OEM support info, BitLocker (XTS-AES 256, TPM + Recovery Password), Autopilot registration.
  • Baseline delivered by Intune after enrollment. Compliance policy, configuration profiles, required apps, Microsoft 365 Apps, Defender for Endpoint, update rings, BitLocker policy (for ongoing management and key rotation).
  • Expected first-boot experience. User selects “Work or school account,” authenticates, sits through the ESP for ~30–60 minutes, then arrives at the desktop with apps and policies applied.

7.2 Conference Room Profile

  • Hardware class. Small form factor desktops (Intel NUC and equivalents) mounted near a display or in a Zoom Rooms appliance kit.
  • Assignment model. No primary human user. Each device is bound to a room (e.g. “Boardroom-Salt-Lake”, “Huddle-02”) and runs Zoom Rooms as its single purpose.
  • Enrollment mode. Classic Windows Autopilot, self-deploying mode (Microsoft Entra join). The device signs itself in via TPM 2.0 attestation — no user account is assigned to the device and no interactive sign-in occurs during enrollment. Self-deploying mode installs apps, applies device policies, and uses the ESP during deployment (Windows Autopilot self-deploying mode workflow, last verified 2026-04-23). A dedicated Zoom Rooms service account is used after enrollment completes: a single-app kiosk configuration profile targets the device and auto-logon delivers the Zoom Rooms shell. The service account is a Microsoft Entra user with no interactive email access and MFA either exempted via Conditional Access or handled by an approved non-interactive method, since kiosk sign-in does not support interactive MFA (Users can’t log on to Windows 11 computers with multi-app kiosk profile assigned, last verified 2026-04-23). Self-deploying requires physical hardware with TPM 2.0 + device attestation; VMs are not supported.
  • Autopilot group tag. ConferenceRoom-<RoomName> (e.g. ConferenceRoom-Boardroom-SLC). This becomes the OrderID on the Entra device record.
  • Dynamic group membership. Devices automatically land in the Win-ConferenceRoom-Devices dynamic security group.
  • Operating model. Effectively a single-app kiosk with Zoom Rooms as the sole purpose. Not a shared PC in the multi-user sense — only the service account signs in, auto-logon is enabled, and the user experience is the Zoom Rooms interface.
TipDesign classification: conference room devices

The Xenter conference room profile is a single-purpose appliance: a classic Autopilot self-deploying device running Zoom Rooms as a single-app kiosk. Microsoft describes self-deploying mode as intended for kiosks, shared devices, and digital signage with little to no user interaction — this matches Xenter’s Zoom Rooms model exactly. The device is governed by a conference-room-specific compliance and configuration baseline; the Zoom Rooms service account signs in via auto-logon only after self-deployment completes. See Section 18 for the full design.

8 Prerequisites and Baseline Requirements

A device cannot be issued until all of the following are true. This is a pre-flight checklist — every item must be green before the provisioning bench session starts.

8.1 Prerequisites before any device is touched

  1. The .env file at the USB root contains a valid TENANT_ID, CLIENT_ID, and either a valid CLIENT_SECRET for silent authentication or a blank value that falls through to Device Code Flow (see Get-GraphAccessToken in Start-XenterProvision.ps1).
  2. The App Registration referenced by CLIENT_ID has the permissions documented in docs/azure-ad-app-registration.md: Device.Read.All and DeviceManagementServiceConfig.ReadWrite.All. Admin consent is granted.
  3. The corporate Wi-Fi profile XML exists at src/wifi-profile.xml. If absent, Install-WiFiProfile will skip silently with a warning — this is acceptable for bench use but not for user laptops that ship to remote users without a wired Ethernet option.
  4. The Assets\ folder contains wallpaper.png at minimum; lockscreen.png and xenter-logo.png are optional.
  5. There is a signed FedEx shipping label queued or ready to print, billed to the corporate account stored in Bitwarden.

8.2 Corporate baseline — what the current USB script delivers

The baseline below is extracted directly from Start-XenterProvision.ps1 and docs/what-the-script-does.md.

# Control Function / key Delivered by
1 Serial number read from Win32_BIOS Get-DeviceSerialNumber USB script
2 Entra ID name-conflict check for XMD-<serial> Test-DeviceNameConflict USB script + Graph
3 Hostname XMD-<serial> (15-char NetBIOS clamp) Set-ComputerNameFromSerial USB script
4 Timezone = Mountain Standard Time Set-CorporateTimeZone USB script
5 OEM bloatware removal (AppX + provisioned) Remove-OemBloatware, $Script:Config.BloatwareList USB script
6 Corporate Wi-Fi profile injected for all users Install-WiFiProfile, wifi-profile.xml USB script
7 Wallpaper + lock screen via PersonalizationCSP, Default User hive seeded Install-CorporateWallpaper USB script
8 OEM info (Manufacturer, Support URL, Phone, Hours, Logo) Set-OemInformation USB script
9 BitLocker (XTS-AES 256, TPM + Recovery Password), manage-bde -on C: Enable-CorporateBitLocker USB script
10 BitLocker key escrow attempt (best-effort, pre-enrollment) Invoke-BitLockerKeyEscrow USB script
11 Autopilot hardware hash upload via Graph API Register-AutopilotViaGraph, Wait-AutopilotImportStatus USB script
12 Fallback Autopilot registration via Get-WindowsAutopilotInfo -Online Register-AutopilotFallback USB script
13 Provisioning log at C:\ProgramData\Xenter\Provisioning\provision-<serial>.log Write-Log, $Script:Config.ProvisionLogDir USB script

8.3 Baseline controls not in the current script — delivered by Intune

These controls are part of the corporate baseline but are not applied by the USB script. They land on the device via Intune after Entra join and enrollment complete. Any failure at this layer is investigated in Section 11.

  • Compliance policy (BitLocker required, minimum Windows version, Defender signatures, firewall state).
  • Configuration profiles (Defender for Endpoint onboarding, Credential Guard, LAPS, Windows Hello for Business if used, Edge baseline).
  • Required apps (Microsoft 365 Apps, Microsoft Teams, Zoom client for laptops / Zoom Rooms client for conference rooms, any line-of-business apps assigned by group).
  • Windows Update rings (feature and quality update policies — see Section 13.2).
  • BitLocker CSP policy that takes ownership of ongoing key rotation and escrow enforcement.
WarningRisk: USB script does not deliver compliance baseline

The USB script ships a device that is Autopilot-registered and locally hardened, but compliance, apps, and most configuration land only after Intune takes over. If Intune enrollment fails, the device has the USB baseline only and nothing else. Validation at first boot (Section 14) is what catches this.

9 Current-State Operating Procedure

This section is the step-by-step workflow for issuing a new user laptop. Conference room deviations are called out inline and fully described in Section 18.

9.1 Step 1 — Intake (receive and verify)

  1. Open the shipping carton in the IT room. Inspect for physical damage. If damaged, stop and follow the procurement return process — do not provision a damaged unit.
  2. Record the device serial number and model in the IT Device Register (or the equivalent asset tracking sheet). Required fields: serial, model, manufacturer, PO number, date received, intended user or room, intended profile (User Laptop or Conference Room).
  3. Confirm the device is on the approved hardware list. If it is not, pause and consult the IT Lead before proceeding.

9.2 Step 2 — Prepare the USB provisioning media

  1. Confirm the USB has the layout defined in README.md:

    USB:\
  Provisioning.bat
  .env                     ← populated, not .env.template
  src\
    Start-XenterProvision.ps1
    wifi-profile.xml
    Assets\
      wallpaper.png
      lockscreen.png       (optional)
      xenter-logo.png      (optional)

  2. Open .env on the USB and verify TENANT_ID and CLIENT_ID are filled. If the team is using silent authentication, verify CLIENT_SECRET is still within its validity window (rotated per the Identity Administrator’s schedule).

  3. For conference room devices, set COMPUTER_PREFIX=XMD (unchanged) but note that you will need to add the ConferenceRoom-<Room> group tag to the Autopilot record post-upload. The USB script itself does not stamp a group tag.

TipRecommendation: two USB variants

Maintain two labeled USB sticks on the bench: “XMD-LAPTOP” and “XMD-ROOM”. They differ only in the .env file (different SUPPORT_PHONE, SUPPORT_HOURS) and potentially in which Wi-Fi profile is shipped. This removes a class of “wrong .env” mistakes.

9.3 Step 3 — Boot into OOBE and run the script

  1. Power on the device with wired Ethernet connected. Let it reach the first OOBE screen (“Choose your country or region” or “Let’s set things up”).

  2. Press Shift + F10 to open a Command Prompt.

  3. Identify the USB drive letter: diskpart, list vol, exit.

  4. Run the script:

    D:\Provisioning.bat

    where D: is the USB drive letter observed above.

  5. The script runs Phase 1 (Setup and Authentication):

    • Initialize-Console sets the window title.
    • Import-EnvFile loads .env overrides.
    • Test-NetworkConnectivity performs a TCP 443 check against login.microsoftonline.com (not HTTPS, by design — OOBE’s cert store is incomplete).
    • Initialize-Prerequisites installs NuGet and Get-WindowsAutopilotInfo from PSGallery.
    • Get-GraphAccessToken authenticates silently if CLIENT_SECRET is present; otherwise it displays a device code and URL for the technician to enter at https://microsoft.com/devicelogin on a second device.

  6. The script runs Phase 2 (Provisioning) in order: name-conflict check, hostname set, timezone, bloatware, Wi-Fi, wallpaper, OEM info, BitLocker, Autopilot.

  7. At the summary screen, record the BitLocker recovery key if it appears in red. This is printed once on screen, written to provisioning.log only if the key was already escrowed, and otherwise remains on the IT paper record until Intune escrows the key post-enrollment.

9.4 Step 4 — Assign the Autopilot profile and group tag

This step is performed from the Intune admin center while the device is still on the bench.

  1. In Microsoft Intune admin center, go to Devices › Enrollment › Windows › Windows Autopilot Devices.
  2. Confirm the device appears with the serial number collected in Section 9.1. If it does not appear within five minutes, investigate per Section 11.1.
  3. Select the device and set the Group Tag field:
    • User laptops: leave blank or set to Laptop (team standard).
    • Conference rooms: set to ConferenceRoom-<RoomName> — exact casing matters for dynamic groups.
  4. Save. Allow up to ~15 minutes for the Entra device devicePhysicalIds attribute to update and the Intune dynamic group membership to reflect the new tag (Create device groups for Windows Autopilot, last verified 2026-04-23).
  5. Verify the correct deployment profile is assigned to the device by checking Profile status on the device row:
    • User laptops → the pre-provisioned deployment profile (e.g. AP-Profile-Laptop-PreProvisioned).
    • Conference-room devices → the self-deploying profile (e.g. AP-Profile-Room-SelfDeploying).
    Statuses progress: Not assigned → Assigning → Assigned. Only ship when Assigned.
  6. For user laptops, optionally assign the user in Intune to pre-fill UPN on the User Flow. This is cosmetic — it does not control which apps or policies deploy (User-driven Microsoft Entra join workflow, last verified 2026-04-23). Conference-room devices must not have a user assigned (self-deploying does not support user assignment).
WarningRisk: devicePhysicalIds query syntax

The environment-stated dynamic group rule was written as (device.devicePhysicalIds -any _contains "[OrderID]:ConferenceRoom-"). The current Microsoft Learn documentation uses -eq for exact match or -startsWith for prefix match, not _contains (Create device groups for Windows Autopilot, last verified 2026-04-23). Recommendation: rewrite the rule as (device.devicePhysicalIds -any (_ -startsWith "[OrderID]:ConferenceRoom-")) and confirm membership updates as expected before shipping the next conference room unit.

9.5 Step 5 — Pre-shipment validation

Run the full checklist in Section 14 before moving to shutdown.

9.6 Step 6 — Shut down and package

  1. From an admin PowerShell on the device: shutdown /s /t 0.
  2. Remove the USB.
  3. Pack the device with:
    • Original power adapter.
    • A printed one-page “Getting Started” card (see Section 9.8) describing the first-boot flow.
    • A sealed envelope containing the BitLocker recovery key only if the key was not escrowed to Entra ID during provisioning. If the key was escrowed, do not include the paper copy.
  4. Seal the box. Initial and date the IT asset register entry.

9.7 Step 7 — Ship via FedEx

  1. Retrieve the FedEx corporate account credentials from Bitwarden › IT › FedEx Corporate. Never type the account number from memory.
  2. Create a label under the corporate account using FedEx Ship Manager. Use the recipient address from the employee record or onboarding ticket.
  3. Signature Required: Yes, Direct. Declared value: matches the device replacement cost.
  4. Update the IT asset register with the tracking number and shipment date.
  5. Send the tracking number to the user via email or the onboarding ticket. Include the “Getting Started” card as a PDF attachment so the user has the instructions even if the package is delayed.
  6. Finance reconciles the FedEx corporate account monthly — no per-shipment approval is required for standard laptop or room device shipments.

9.8 Step 8 — End-user setup (what the user does)

The “Getting Started” card tells the user to:

  1. Connect the laptop to wired Ethernet if possible, or a known Wi-Fi network.
  2. Power on. At the first setup screen, select Work or school account and sign in with their @xenter.io credentials.
  3. Wait through the Enrollment Status Page. It will run device setup, account setup, and optionally quality updates — expect ~30–60 minutes total.
  4. When the desktop appears, sign out and sign back in once. This forces wallpaper and user-context policies to apply cleanly.
  5. If anything fails or hangs for longer than 30 minutes on the same screen, follow the card’s “If setup fails” instructions: click Collect logs, then contact IT via the phone number or URL printed on the card.

For conference room devices, the “user” is the IT technician installing the unit in the room. See Section 18 for the on-site commissioning procedure.

9.9 Step 9 — Post-deployment validation

Within 24 hours of first successful sign-in, the remote support technician performs the checks in Section 14.3. This closes the loop on whether Intune-delivered baseline controls (compliance, apps, BitLocker escrow) actually landed.

10 Decision Logic and Business Rules

This section encodes the explicit if/then rules a technician must follow. Each rule is derived from an operational failure mode that has been observed or is foreseeable given the current toolchain.

10.1 Profile and shipment routing

  • If the device is a user laptop, then apply the User Laptop profile, use the Laptop group tag (or blank), validate against the user-laptop checklist, ship to the user directly.
  • If the device is a small form factor desktop intended for a conference room, then apply the Conference Room profile, set the group tag ConferenceRoom-<Room>, validate against the conference-room checklist, and ship to the on-site installer or room champion — not to a generic employee address.
  • If the hardware is not on the approved list, then hold the device and escalate to the IT Lead. Do not provision unknown hardware.

10.2 Hardware hash upload

  • If Register-AutopilotViaGraph returns a complete status (see Wait-AutopilotImportStatus in the script), then proceed.
  • If it returns error, then read the detail in $Script:Results.AutopilotStatus and follow Section 11.1. Do not proceed to shutdown.
  • If it returns timeout, then do not fail the device yet — wait 15 more minutes and re-query Intune manually. If still pending, follow Section 11.1.

10.3 Autopilot deployment mode selection

  • If the device is a user laptop, then the assigned Autopilot profile must be the pre-provisioned deployment profile (AP-Profile-Laptop-PreProvisioned).
  • If the device is a conference-room endpoint, then the assigned Autopilot profile must be the self-deploying profile (AP-Profile-Room-SelfDeploying).
  • If the hardware is a VM (bench testing or lab use), then self-deploying mode is not supported — fall back to user-driven for that VM only. Do not ship VMs to conference rooms.

10.4 Autopilot profile assignment

  • If at the pre-shipment gate the Autopilot Profile Status is Assigned, then proceed.
  • If it is Assigning, then wait 15 minutes. If still not Assigned, verify the profile itself is assigned to the correct device group in Intune (laptops → Win-Laptop-Autopilot-Devices, rooms → Win-ConferenceRoom-Devices).
  • If the profile is not assigned at all, then hold the device. Do not ship an unassigned Autopilot device — first boot will not present the corporate OOBE and the user will land in a partially configured state.

10.5 Intune enrollment

  • If the user completes OOBE and the device appears in Intune under Devices › All devices with “Last check-in” within 24 hours, then enrollment succeeded.
  • If the device shows in Entra but not Intune after the first 48 hours, then the MDM auto-enrollment scope is missing the user or there is a network or license issue. Escalate to the Intune Administrator.

10.6 ESP behavior

  • If ESP shows a progress bar and completes, then continue.
  • If ESP hangs on the same step for longer than the policy timeout, then check whether Allow users to reset the device if an installation error occurs is enabled in the ESP profile (Set up the Enrollment Status Page, last verified 2026-04-23). If yes, have the user click Reset device and retry. If the same failure occurs twice, switch to Section 12.
  • If an ESP timeout repeatedly coincides with a specific app, then that app is the primary suspect — see Section 11.6.

10.7 Broken or corrupt user profile

  • If the device completes OOBE but the user cannot sign in or the profile loads blank/temporary, then do not spend more than 15 minutes troubleshooting the profile. Initiate Autopilot Reset via Intune (see Section 12.1).
  • If Autopilot Reset fails or the same corruption recurs on the same hardware, then escalate to Wipe with enrollment retained (see Section 12.2).

10.8 Post-shipment failure

  • If the user cannot complete setup remotely, then the remote support technician starts a Remote Help session (Use Remote Help with Microsoft Intune, last verified 2026-04-23). If Remote Help is not reachable, fall back to Quick Assist.
  • If two Remote Help / Quick Assist sessions in a row cannot move the device past OOBE/ESP, then ship a replacement and schedule the failed device for return, inspection, and either re-provisioning or retirement.

10.9 Repeated failures on the same hardware

  • If the same serial number has failed two provisioning attempts after a full wipe, then disqualify the device from shipment. Quarantine it with a physical label and a ticket. It is a candidate for OEM warranty return or retirement.

10.10 Reassignment

  • If a returned user-laptop is in working condition, was Entra-joined, and is being handed to a new employee in the same org, then Autopilot Reset is sufficient in most cases. Verify the old user is unassigned in Intune first and assign the new primary user.
  • If reassigning or redeploying a self-deploying conference-room device, then delete the existing Intune device record first. Self-deploying mode cannot automatically re-enroll the same device after its initial deployment; the stale record must be removed before a second self-deployment will succeed (Windows Autopilot self-deploying mode workflow, last verified 2026-04-23).
  • If the device is coming back from a terminated employee, a legal/HR investigation, a recovered loss/theft event, or outside counsel, then always use Wipe (without retaining the user account). Autopilot Reset does not cryptographically erase the drive (Windows Autopilot Reset overview, last verified 2026-04-23), which is unacceptable for sensitive-return scenarios.

10.11 Conference room hardening

  • If the device is a conference room endpoint, then it must not have a user sign-in experience. The dedicated Zoom Rooms service account signs in via auto-logon, and no interactive end-user sign-in is permitted.
  • If Zoom Rooms is not installed within 2 hours of Intune enrollment completing on a conference room device, then the Zoom Rooms assignment is missing or scoped incorrectly. See Section 11.7.

11 Common Failure Scenarios and Responses

Each scenario below states the symptom, the most likely cause, and the defined response. A technician should be able to find their failure in this list and act without reading the rest of the SOP.

11.1 Hardware hash upload fails

Symptom. Register-AutopilotViaGraph returns error, or the device does not appear in Intune’s Autopilot Devices list within 15 minutes.

Likely causes.

  • Graph token was not obtained (see Get-GraphAccessToken output).
  • Tenant ID / Client ID mismatch in .env.
  • The App Registration lost consent or the secret expired.
  • Hardware hash was unreadable from WMI (rare — Get-HardwareHash reads MDM_DevDetail_Ext01).

Response.

  1. Inspect the summary screen: if AutopilotStatus says Import failed with an error code, copy it verbatim into the ticket.

  2. Re-check .env: TENANT_ID and CLIENT_ID are correct GUIDs. If CLIENT_SECRET is present, verify it is not expired.

  3. From a desktop with internet and an admin token, manually run:

    $env:Path += ";C:\Program Files\WindowsPowerShell\Scripts"
Get-WindowsAutopilotInfo -Online

    from the device itself once the bench session is complete. This is the documented manual fallback.

  4. If Graph-side consent has lapsed, escalate to the Identity Administrator to re-grant admin consent on the App Registration (docs/azure-ad-app-registration.md).

  5. Do not ship the device until the hash is visible in Intune’s Autopilot Devices list.

11.2 Autopilot registration fails end-to-end

Symptom. Both the Graph upload and the Get-WindowsAutopilotInfo -Online fallback fail.

Response.

  1. Confirm network: ping login.microsoftonline.com and graph.microsoft.com. TCP 443 must be reachable.
  2. Confirm the device’s TPM is healthy and unlocked (Get-Tpm). If the TPM is cleared or failed, BitLocker and Autopilot both degrade.
  3. If Graph-side rejection persists, capture the HTTP status code from Invoke-RestMethod and escalate. Most 4xx errors are permissions-related; 5xx errors are retryable after a wait.
  4. Held device outcome: do not ship. Move to manual OEM registration via vendor portal if the vendor supports it, or return the unit to inventory.

11.3 Missing or incorrect profile assignment

Symptom. Device appears in Autopilot Devices but “Profile Status” is stuck on Not assigned.

Response.

  1. Verify the Autopilot deployment profile’s Assignments tab in Intune includes either the all-Autopilot dynamic group or a narrower group that contains this device. A profile with zero assignments will never apply.
  2. Verify the device’s group tag (if targeting by tag) matches what the deployment profile expects. Typos in the OrderID are the most common cause.
  3. For conference room devices, also verify the conference-room Autopilot profile exists and is assigned to the conference room dynamic group (see the Risk in Section 9.4 about _contains vs -startsWith).
  4. Trigger a manual “Sync” on the device from Devices › Windows Autopilot Devices if available, or wait 15 minutes and re-check. Ship only when Assigned.

11.4 Intune enrollment fails during provisioning

Symptom. Device joins Entra ID but is missing from Intune, or shows Unknown MDM state.

Likely causes.

  • User is not licensed for Intune (EMS E3/E5, M365 Business Premium, or equivalent).
  • MDM user scope in Entra ID › Mobility (MDM and MAM) › Microsoft Intune excludes this user.
  • Device is over the per-user device cap.

Response.

  1. In Intune, go to Devices › All devices and filter by serial.
  2. If missing, check Entra ID Devices › All devices for the device and inspect “Activity”.
  3. In Identity › Mobility (MDM and MAM) confirm the user is in the MDM user scope.
  4. Confirm the user holds an Intune-eligible license.
  5. If all prerequisites are met, have the user run from Settings: Accounts › Access work or school › Info › Sync. If still no MDM handshake, escalate — the device may need a Wipe-and-reprovision.

11.5 ESP timeout or failure

Symptom. User sees the Enrollment Status Page hang on “Installing apps” or “Configuring device” past the timeout, or sees the red failure screen.

Response by decision.

  1. First pass: if ESP offers Try again or Reset device, the user tries each once in that order. ESP exposes these options only if the profile is configured to allow them (Set up the Enrollment Status Page, last verified 2026-04-23).
  2. Second pass: the user clicks Collect logs. Remote support retrieves the logs from the chosen destination (USB drive attached during OOBE, or uploaded to the support ticket) and inspects the IntuneManagementExtension.log and ESP registry keys under HKLM:\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking (Troubleshoot the Enrollment Status Page, last verified 2026-04-23).
  3. If the failing step is a specific required app, jump to Section 11.6.
  4. If the failing step is a configuration profile or certificate, re-target the profile to the correct group and retry. Increase the ESP timeout temporarily if a large Win32 app is genuinely taking that long.
  5. If two full resets cannot move the device past ESP on the same hardware, ship a replacement and quarantine the failed unit.

11.6 Required app installation failure

Symptom. ESP or post-enrollment shows a required app stuck at “Installing” or failed.

Response.

  1. In Intune, go to Apps › Windows › select the failing app › Device install status. Read the specific error for this device.
  2. Common causes: app requires reboot and ESP blocked it; install exit code is non-zero and mapped as failure; detection rule does not match what the installer actually produces.
  3. Fix the detection rule, add a required reboot exit code mapping, or correct the install command line. Redeploy.
  4. Consider marking the failing app as Available rather than Required until its deployment is stable, to unblock ESP for other devices.
  5. For Microsoft 365 Apps specifically, avoid mixing LOB and Win32 install triggers that fire concurrently in ESP — that combination is a documented cause of hangs (Troubleshoot the Enrollment Status Page, last verified 2026-04-23).

11.7 Zoom Rooms not installed on conference room device

Symptom. Conference room device has enrolled, but Zoom Rooms is not present or not launching as the shell.

Response.

  1. Confirm the device is in the Win-ConferenceRoom-Devices dynamic group (see Risk in Section 9.4 for correct query syntax).
  2. Confirm the Zoom Rooms app assignment targets that group as Required.
  3. Check Apps › Device install status for Zoom Rooms on this device.
  4. If the assignment is correct but the install has not fired, manually sync the device from Intune and wait 15 minutes.
  5. If Zoom Rooms installs but does not launch as the shell, verify the kiosk or assigned-access configuration profile is targeting the device and the Zoom Rooms service account is in the kiosk sign-in scope.

11.8 Broken or corrupt user profile created

Symptom. Windows logs the user in, but the profile loads as TEMP, desktop is missing, or apps are unavailable.

Response.

  1. Do not attempt profile repair on a remote device — the tooling is poor and the risk of making it worse is high.
  2. Initiate Autopilot Reset from Intune (Section 12.1). The user keeps the device but gets a clean OOBE.
  3. If Autopilot Reset fails or the issue returns, escalate to a full Wipe and re-enrollment.

11.9 Device shipped before validation was complete

Symptom. Device is in transit, tracking shows delivery imminent, and an unvalidated gate (e.g. Autopilot profile not assigned) was missed.

Response.

  1. Assign the missing Autopilot profile or configuration immediately, even while in transit. Autopilot pulls the profile at first boot, so a late assignment can still work as long as it is in place before the user signs in.
  2. Notify the user before they power on: tell them to wait X minutes after first connecting to the internet before clicking Work or school account. This gives Autopilot time to pick up the newly assigned profile.
  3. Document the miss in the post-mortem log. Adjust the pre-shipment checklist wording if the gate was ambiguous.

11.10 Device becomes noncompliant after deployment

Symptom. Intune shows the device as Not Compliant.

Response.

  1. Open the device in Intune and review the Compliance tab. Identify the failing setting (BitLocker off, Windows version behind, Defender signatures stale, etc.).
  2. For BitLocker failures, verify the recovery key is present in Entra ID. If not, deploy the proactive remediation script that runs BackupToAAD-BitLockerKeyProtector to force re-escrow (Intune BitLocker Recovery Key Missing in Entra ID, last verified 2026-04-23).
  3. For Windows version failures, confirm the device is in the correct update ring and the feature update policy has been received.
  4. If compliance cannot be restored remotely within the grace period configured on Conditional Access, the user will lose access to M365 until the device is fixed. Escalate to a full recovery path (Section 12) rather than leaving the user blocked.

11.11 Reassignment of previously issued hardware

Covered in Section 10 under “Reassignment” and procedurally in Section 12.1 and Section 12.2.

12 Recovery and Reprovisioning Procedures

This section defines the three recovery paths — Autopilot Reset, Wipe, and full re-provisioning — and when to choose each. All three are initiated from Intune and do not require physical access to the device.

12.1 Autopilot Reset

Use when the device is fundamentally healthy but the user profile, local cached state, or a small set of misconfigurations needs to be cleared.

  1. Intune admin center: Devices › All devices › select device › Autopilot Reset.
  2. Confirm the action. The device will reboot into a re-provisioning flow; the user is prompted to sign in again after completion.
  3. Note: Autopilot Reset removes all user profiles, personal files, and non-Microsoft apps, and reconstructs the OS; it preserves the Microsoft Entra join, Intune enrollment, and most device-targeted configuration. It does not cryptographically erase the drive (Windows Autopilot Reset overview, last verified 2026-04-23). Residual artifacts can persist. This is acceptable for standard reassignments within the same organization, but is unacceptable for sensitive-return scenarios (see Section 12.2). Autopilot Reset can be initiated locally by a device-admin user (Ctrl+Win+R at the lock screen) or remotely by an Intune Service Administrator; the remote variant clears the primary user and Entra owner on next sign-in — important for reassignment tracking in the IT Device Register.
  4. Best suited to: reassigning to a new employee in the same org, breaking a corrupt user profile, recovering from a stuck or misconfigured state where BitLocker, Entra join, and Intune enrollment are otherwise healthy.

12.2 Wipe (standard)

Use when the device must be returned to factory state with a clean OS reinstall.

  1. Intune admin center: Devices › All devices › select device › Wipe.
  2. Options:
    • Wipe device, but keep enrollment state and associated user account — faster, keeps the device in Intune. Use for proactive reprovisioning of a healthy-but-dirty device (Use wipe, retire, or manually unenroll devices in Intune, last verified 2026-04-23).
    • Wipe device (uncheck retain) — full factory reset, device returns to OOBE, will re-enroll via Autopilot if still in the Autopilot record.
  3. Continue even if device loses power — enable this for lost or stolen devices so the wipe resumes on next boot.
  4. Always Wipe without retain for:
    • Recovered lost/stolen devices.
    • Returns from terminated employees.
    • Returns flagged by HR, Legal, or Security.
    • Any device where the prior user’s data must be irrecoverable.
  5. After Wipe, the device can be reissued via Autopilot on next OOBE. The hardware hash is preserved in the Autopilot device record.

12.3 Fresh Start

Not the recommended recovery path for Xenter. Fresh Start removes Win32 apps and MDM policies and can create an inconsistent state on Entra-joined devices. The previous user’s cached data can also remain. Prefer Autopilot Reset (reassignment) or Wipe (return-to-factory).

12.4 Full re-provisioning (new user, same hardware)

  1. In Intune, Wipe the device with retain unchecked, or Retire the device and remove the Autopilot record if keeping the Autopilot registration is not desired.
  2. Reassign the device to a new user in Intune (Autopilot record → Assign user).
  3. Ship the device to the new user per Section 9.7, with a new “Getting Started” card.
  4. The new user signs in; Autopilot redeploys the corporate OOBE, ESP runs, apps and policies apply.

12.5 Replacement decision

The replacement threshold is two consecutive recovery failures on the same hardware. If a device requires a third recovery attempt within 90 days, it is pulled from service, documented in the quarantine log, and either returned under OEM warranty or retired.

13 Ongoing Remote Management Procedures

This section defines the day-two operational activities the team performs continuously on the deployed fleet.

13.1 Remote compliance monitoring

  • Cadence. The Intune Administrator reviews the Intune Compliance dashboard weekly and the Endpoint security dashboard at least monthly.
  • Alerting threshold. A device that is Not Compliant for more than 72 hours without being actively in remediation triggers a ticket.
  • Conditional Access coupling. Conditional Access policies that require compliant devices for Microsoft 365 access mean that non-compliance is self-surfacing — users lose access and file tickets. This is acceptable as a soft alerting mechanism for user laptops but not for conference room devices, which must be monitored via the Intune dashboard only (they rarely generate user tickets).

13.2 Remote patching via Intune Windows Update rings

Xenter uses Windows Update for Business, orchestrated by Intune, to deliver feature and quality updates (Windows Update Management Overview, last verified 2026-04-23).

Ring design.

Ring Audience Quality update deferral Feature update deferral
WU-Ring-Pilot IT team laptops + one room device 0 days 7 days
WU-Ring-Broad All user laptops 7 days 30 days
WU-Ring-ConferenceRoom All conference room devices 14 days 60 days

Rationale.

  • The pilot ring catches Microsoft-side regressions before they reach the broad fleet.
  • The broad user ring is aggressive enough to meet reasonable security expectations without catching every shipped regression.
  • The conference room ring is conservative — a mid-meeting restart driven by an unapproved update is a reputational cost that outweighs the security benefit of early patching.

Settings catalog values.

  • Automatic Update Behavior = Auto install and reboot without end-user control for conference rooms (during off-hours active hours); Auto install and notify to schedule restart for user laptops.
  • Active hours = 7 AM – 7 PM local (for conference rooms: 6 AM – 9 PM local, override per room if needed).
  • Feature update policy enforces the current supported Windows 11 version; update ring feature deferral is set to 0 to avoid conflicts (Configure Windows Feature Update Policies, last verified 2026-04-23).
NoteNote on Windows Autopatch

Windows Autopatch is the Microsoft-managed update orchestration layer that can replace self-managed rings. Licensing requirements are covered by M365 E3/E5, EMS E3/E5, or Windows 10/11 Enterprise E3/E5 (Windows Update Management Overview, last verified 2026-04-23). Recommendation: evaluate Autopatch adoption in the next fiscal quarter. It reduces the maintenance surface for the IT team but requires one-time ring migration and is a material change to the update model.

13.3 Intune application update and redeployment workflow

  1. App updates are delivered by replacing the app package in Intune and incrementing the detection rule version (for Win32 apps) or simply uploading the new MSIX/appx (for Microsoft Store apps).
  2. For Microsoft 365 Apps, use the built-in Microsoft 365 Apps (Windows 10 and later) app type and set the update channel (Monthly Enterprise Channel is standard for user laptops).
  3. For critical updates, use Required assignment with a deadline of 72 hours. For optional/productivity apps, use Available in Company Portal.
  4. Changes to required-app assignment trigger a device check-in within eight hours on a default-synced device. Force a sync from the device or from the Intune action to accelerate.

13.4 Remote lock / wipe for lost or stolen devices

  1. As soon as the loss/theft is reported, mark the user account as User risk: High if supported, and revoke all sessions in Entra ID.
  2. In Intune, select the device and issue a Wipe with:
    • Continue even if device loses power enabled (ensures resume across reboots).
    • Retain enrollment not checked (uncheck — full factory reset).
  3. Also run Retire as a secondary action if the device is unlikely to check in again; this removes it from Intune management records immediately.
  4. Revoke BitLocker recovery keys for this device object, and retrieve the last known BitLocker recovery key for forensic reference before deleting the device object.
  5. File a police report if required by policy. Update the IT asset register to reflect Lost/Stolen and close or reissue the asset as appropriate.

13.5 Remote password reset and user account unlock

  1. Password reset is performed in Entra ID, not on the device. Go to Identity › Users › select user › Reset password.
  2. Communicate the temporary password via an approved out-of-band channel (phone, approved messaging app — not the same email the user may have lost access to).
  3. For a self-service path, ensure the user has SSPR registered. This is the default preference; IT should only perform a manual reset when SSPR is unavailable.
  4. Account lockout driven by MFA fatigue or repeated failed attempts is resolved in Entra ID under Identity › Users › select user › Authentication methods — revoke and re-register the relevant method.

13.6 Remote troubleshooting access

  • Primary: Intune Remote Help, launched from Devices › select device › New remote assistance session (Remote Device Action: New Remote Assistance Session, last verified 2026-04-23). Remote Help is part of the Intune Suite and provides audit logging, RBAC scoping, and elevation — capabilities that Quick Assist lacks.
  • Fallback: Quick Assist, invoked when Remote Help is unavailable. Quick Assist does not support elevation, does not audit, and is not scoped by Intune RBAC (Use Quick Assist to help users, last verified 2026-04-23). Treat it as a convenience tool for view-only or non-privileged steps, not as a replacement for Remote Help.
  • RBAC guidance. Assign the built-in Help Desk Operator role only to the remote support technicians (Plan for Remote Help with Microsoft Intune, last verified 2026-04-23). Require MFA and a compliant admin device for Conditional Access on helper accounts.

13.7 Audit logging, retention, and compliance reporting

  • Intune audit logs. All admin actions (profile changes, policy changes, device actions) are logged automatically. Default retention is 1 year.
  • Entra audit logs. Sign-ins, role changes, and device registration events. Default retention varies by license; export to Log Analytics workspace if longer retention is required.
  • Remote Help session logs. Exposed in Intune under Tenant Administration › Audit Logs and inside the Remote Help session history.
  • Provisioning logs. Per-device logs live at C:\ProgramData\Xenter\Provisioning\provision-<serial>.log. These are on the device only and are not centrally harvested today. Recommendation: collect them via a scheduled Intune device diagnostics export for long-term archival.
  • BitLocker recovery key access. Every key retrieval from Entra ID is audited and logged. Review these logs monthly.

14 Validation Checklists

Use these checklists literally. Tick each item before moving on.

14.1 Pre-shipment (user laptop)

14.2 Pre-shipment (conference room)

14.3 Post-shipment (within 24 hours of first sign-in)

15 Documentation and Recordkeeping

Every device touched by this SOP generates a minimum record set. The record is not optional — it is the basis for audit, reassignment, and replacement decisions.

Mandatory records.

  1. IT Device Register row with: serial, model, manufacturer, PO, date received, profile, intended user/room, BitLocker recovery key location (paper or Entra), tracking number, shipment date, return date (if any), retirement date (if any), quarantine reason (if any).
  2. Provisioning log (provision-<serial>.log) retained on the device and copied to long-term storage if the device is being retired.
  3. Intune device object — preserved through the device lifecycle; deleted only at retirement.
  4. Entra ID device object — preserved; deleted only at retirement.
  5. Autopilot device record — retained unless the device is being permanently decommissioned. The Autopilot record is what allows reassignment to continue working.
  6. Ticket history — every recovery action, every Remote Help session, every replacement decision is recorded in the IT ticketing system and linked back to the asset register row.

Retention.

  • Device register rows: indefinitely (for the life of the company).
  • Provisioning logs: minimum 2 years from retirement.
  • Intune and Entra audit logs: minimum 1 year (default) or extended via Log Analytics export.
  • BitLocker recovery keys: never stored outside Entra ID or an approved secrets manager; never in email, chat, or wiki pages.

16 Escalation Criteria

Escalate to the IT Lead when any of the following is true.

  1. A device has failed two full recovery attempts within 90 days.
  2. A device is disqualified from shipment.
  3. A compliance failure affecting more than 5% of the fleet persists for more than 24 hours.
  4. An Intune or Entra configuration change is being proposed that affects the Autopilot deployment profile, ESP profile, compliance policy, BitLocker policy, or the App Registration used by the provisioning script.
  5. A BitLocker recovery key cannot be located for a device that requires recovery.
  6. A security event (suspected theft, MFA compromise, malware detection by Defender) is reported on a managed device.
  7. FedEx corporate account credentials are suspected compromised, expired, or unavailable.

Escalate to external support (Microsoft Premier, the reseller, or the OEM) when the IT Lead confirms that the issue is product-side and cannot be resolved internally within the SLA.

17 Recommended Improvements

The current-state process works, but it carries well-understood fragility. Every item below is a recommendation, distinct from current-state practice, and should be evaluated on its own merits.

17.1 R1 — Stay on classic Autopilot; do not adopt Device Preparation

  • Decision. Xenter remains on classic Windows Autopilot for both device profiles: pre-provisioned deployment for user laptops and self-deploying mode for conference-room endpoints. Windows Autopilot Device Preparation (v2) is not adopted.
  • Why. Device Preparation’s first release supports only user-driven Microsoft Entra join and Windows 365 automatic mode. It explicitly does not support self-deploying or pre-provisioned deployment (Windows Autopilot device preparation overview, last verified 2026-04-23). Both modes are core to Xenter: self-deploying is the documented Microsoft path for Zoom Rooms–class kiosk appliances, and pre-provisioning is the name for Xenter’s “IT pre-stages the device and ships it with most work complete” workflow. Device Prep does not cover either scenario.
  • Microsoft’s own guidance. Microsoft states that classic Autopilot and Device Preparation will coexist and that there is no requirement to migrate existing Autopilot profiles (Windows Autopilot device preparation overview, last verified 2026-04-23). Classic Autopilot remains fully supported.
  • Revisit criteria. Reconsider adoption of Device Preparation if Microsoft adds parity for self-deploying and pre-provisioned deployment, or if Xenter’s fleet composition shifts substantially away from kiosk/room and bench-staged laptop scenarios.
  • What this means operationally. The USB script’s hardware-hash upload and bench-side hardening steps remain. Intune profiles, ESP settings, and dynamic device groups continue to be authored against classic Autopilot. Dynamic device groups based on Autopilot OrderID / group tag remain supported in classic Autopilot — the group-type restriction that forbids dynamic groups is specific to Device Preparation’s target group and does not apply here (Create device groups for Windows Autopilot, last verified 2026-04-23).

17.2 R2 — Separate conference room compliance and configuration baseline

Current gap. Conference room devices inherit the user-laptop compliance policy. This is a risk because room devices never have an interactive user, never unlock BitLocker via user PIN, and have very different app and update expectations.

Recommendation. Create a dedicated set of Intune policies scoped to Win-ConferenceRoom-Devices:

  • Comp-Room-Windows — compliance policy: BitLocker on, minimum Windows version, Defender signatures, firewall; exclude user-context controls like “password required” since kiosk auto-logon handles sign-in.
  • Config-Room-Kiosk — settings catalog or custom profile enforcing single-app kiosk with Zoom Rooms as the assigned app and the Zoom Rooms service account as the assigned user.
  • Config-Room-Display — disable Cortana, disable notifications, disable sleep on AC power, set active hours to room usage, disable Wi-Fi if the device is wired.
  • WU-Ring-ConferenceRoom — update ring with conservative deferrals as described in Section 13.2.
  • Apps-Room-ZoomRooms — Required assignment of the Zoom Rooms client.

17.3 R3 — Make the pre-shipment validation machine-checkable

The current checklist is human-gated. A technician can miss a step. Move the checklist into a small PowerShell post-flight validator that runs on the bench after Provisioning.bat completes, reads the Graph to confirm Autopilot record + profile status, reads BitLocker escrow state, and prints a single green-or-red “SHIP / HOLD” verdict.

17.4 R4 — Centralize provisioning logs

Today, provision-<serial>.log only exists on the device. Add an Intune Win32 app or proactive remediation that copies the log to an Azure Storage container keyed by serial, on a schedule. This makes retrospective analysis possible for devices that have already reached the user.

17.5 R5 — Enforce the Autopilot group tag at provisioning time

The USB script does not stamp the group tag today — it is set manually in Intune after the fact. Add an AUTOPILOT_GROUPTAG variable to .env and pass it to the Graph upload as groupTag on the importedWindowsAutopilotDeviceIdentity payload. This closes a common miss (wrong or missing group tag) and aligns with the two-USB design in Section 9.2.

17.6 R6 — Rotate the App Registration secret on a calendar

CLIENT_SECRET is optional but widely used for silent auth. If it expires unexpectedly, every USB session fails at Get-GraphAccessToken. Rotate on a 180-day calendar, and add a bench test that verifies auth at the start of every work week.

17.7 R7 — Use Remote Help over Quick Assist as the default, with RBAC enforced

Remote Help is already the recommended tool per Section 13.6. The recommendation here is to make it the only supported remote tool for privileged actions (elevation, install/uninstall, configuration) and to tightly scope the Help Desk Operator role via Intune RBAC. Quick Assist remains available for view-only walkthroughs with non-privileged users.

17.8 R8 — Add BitLocker key-escrow proactive remediation

Deploy a proactive remediation script that runs BackupToAAD-BitLockerKeyProtector on every check-in, ensuring the recovery key is in Entra ID even if the original Intune BitLocker policy escrow failed (Intune BitLocker Recovery Key Missing in Entra ID, last verified 2026-04-23). This is safe to run repeatedly and acts as a net against silent escrow failures.

18 Conference Room Design: Detailed Analysis

Because the current environment has no conference-room-specific compliance baseline, this section defines what “conference room device management” should look like at Xenter and why.

18.1 Operating model classification

The four common Windows shared-space models are self-deploying, shared device (Shared PC), kiosk (single- or multi-app), and hybrid. The right fit for Xenter depends on whether real users sign in to the room device and on whether the enrollment itself is interactive.

Model Interactive user sign-in during enrollment? Autopilot mode Best fit for Xenter?
Self-deploying + single-app kiosk No — device self-enrolls; service account runs the kiosk shell via auto-logon after enrollment Classic Autopilot, self-deploying mode Yes. Microsoft documents self-deploying as intended for kiosks, shared devices, and digital signage — the exact Zoom Rooms use case.
User-driven + single-app kiosk Yes — service account signs in during enrollment Classic Autopilot, user-driven Secondary. Used only when self-deploying cannot be used (e.g. VM bench testing — self-deploying requires physical TPM 2.0 + attestation).
Shared PC Yes — many users Any user-driven No. Zoom Rooms does not expect end-user sign-in.
Hybrid (kiosk + occasional admin) Yes, restricted User-driven Fallback only if kiosk proves too restrictive for occasional on-site IT maintenance.

Decision. Treat conference-room devices as classic Autopilot self-deploying devices running Zoom Rooms as a single-app kiosk. Microsoft states that self-deploying mode does not support assigning a user to the device, is Microsoft Entra join only, and installs apps, applies device policies, and uses ESP during deployment (Windows Autopilot self-deploying mode workflow, last verified 2026-04-23). The Zoom Rooms service account signs in via auto-logon after self-deployment completes. This aligns with Zoom’s own deployment guidance for Windows-based Zoom Rooms, which requires a local account with administrative rights for the Zoom Rooms shell (Kiosk settings for Windows in Microsoft Intune, last verified 2026-04-23).

18.1.1 Caveats for self-deploying mode

  • TPM 2.0 + device attestation is required. Self-deploying mode relies on attestation to join Entra without an interactive user. VMs are not supported.
  • Cannot automatically re-enroll. Self-deploying mode cannot automatically re-enroll the same device after its initial deployment. To redeploy or reuse, delete the existing Intune device record first (Windows Autopilot self-deploying mode workflow, last verified 2026-04-23).
  • Dynamic device groups should target the Autopilot OrderID / group tag, not general post-enrollment Entra device attributes. Microsoft warns that using non-Autopilot attributes before provisioning can lead to unexpected behavior during OOBE (Create device groups for Windows Autopilot, last verified 2026-04-23).
  • Hostname template. The classic Autopilot device-name template supports %SERIAL%. Microsoft enforces a 15-character NetBIOS limit on the resulting name, so XMD-%SERIAL% is only valid when the serial is short enough — the USB script’s Set-ComputerNameFromSerial clamps to 15 characters.

18.2 Minimum apps and policies for room systems

  • Apps. Zoom Rooms (required). Microsoft Teams Rooms is not deployed on Zoom Rooms endpoints — they are a single-purpose device.
  • Kiosk profile. Single-app kiosk with Zoom Rooms as the shell. Note the known limitation with multi-app kiosk plus MFA — kiosk sign-in cannot prompt for MFA, so the Zoom Rooms service account is either exempt from MFA by Conditional Access (preferred for scoped service accounts) or uses a supported non-interactive method (Users can’t log on to Windows 11 computers with multi-app kiosk profile assigned, last verified 2026-04-23).
  • Configuration. Disable sleep on AC power, disable screen lock during active hours, disable notifications, disable Windows Update restarts during business hours.
  • Compliance. BitLocker on, Windows 11 current supported version, Defender signatures current, firewall on.
  • Update ring. WU-Ring-ConferenceRoom as defined in Section 13.2.

18.3 Grouping, naming, validation, reset, replacement

  • Grouping. Dynamic Entra security group Win-ConferenceRoom-Devices using the Autopilot-attribute query (device.devicePhysicalIds -any (_ -startsWith "[OrderID]:ConferenceRoom-")). Base membership on the Autopilot OrderID / group tag only; do not combine with general post-enrollment attributes (Create device groups for Windows Autopilot, last verified 2026-04-23).
  • Naming. XMD-<serial> same as user laptops. The Autopilot profile uses the %SERIAL% template; the USB script’s Set-ComputerNameFromSerial clamps the final hostname to the 15-character NetBIOS limit. Room identity lives in the group tag, not the hostname.
  • Validation. Per Section 14.2. Additional on-site step: physically confirm Zoom Rooms loads, mic/camera are functional, and the room is visible in the Zoom admin portal.
  • Reset. Autopilot Reset is the default for minor repair. For redeployment or reuse of a self-deployed device, delete the existing Intune device record first — self-deploying mode cannot automatically re-enroll a device after its initial deployment.
  • Replacement. Since conference room devices lack an interactive user to raise a ticket, the IT team monitors room health via the Zoom admin dashboard and the Intune compliance dashboard. Two missed daily check-ins triggers an investigation; a failed Autopilot Reset triggers a replacement ship.

18.4 Zoom Rooms availability validation

Before a conference room device is declared live:

  1. Sign in to the Zoom admin portal and confirm the room appears under the expected location.
  2. From a second device, schedule a test meeting in that room and join it; confirm video, audio, and content share all work.
  3. Record the validation in the IT asset register with the room ID, the test meeting ID, and the date/time.
  4. Only then remove the “Provisioning” label from the device record and mark it Live.

19 Technician Quick Reference Checklist

Printable one-page summary for the bench.

Before the device boots:

During OOBE:

At the summary screen:

In Intune before shipping:

Pack and ship:

First 24 hours after delivery:

When in doubt: hold the device. A held device is cheaper than a failed user.

20 Sources & References

All URLs last verified 2026-04-23 unless otherwise noted.

Internal references.

  • Start-XenterProvision.ps1 — OOBE provisioning script (src/Start-XenterProvision.ps1).
  • Provisioning.bat — USB entry point at USB root.
  • .env.template — runtime configuration surface (.env.template).
  • docs/azure-ad-app-registration.md — App Registration setup.
  • docs/configuration.md — environment variable reference.
  • docs/troubleshooting.md — script-level troubleshooting.
  • docs/what-the-script-does.md — step-by-step script behavior.

xenter · Confidential — Internal IT Operations Standard Operating Procedure Document ID SOP-IT-WIN-001 · Version 1.0 · Owner: IT Operations · Review cadence: Quarterly

Back to top