Laptop Provisioning & Imaging Checklist Template

The platform and image answers on task 1 decide which Phase 2 tasks appear.

• Open the run and record platforms, the reason for it and the approver — Windows, Mac or both; new standard, new model, new OS version or scheduled review; and whether a custom Windows image is still in use
• List the role profiles the standard must cover — standard office, finance, developer, shared device; each extra profile is another build to test
• Pull the current standard and its change log — the version number and what changed since the last run
• Confirm the approved hardware models and their support end dates — a model past its end date should leave the list, not be re-tested
• Collect build problems raised since the last run — service desk tickets tagged as build issues are the first test cases

Tasks 1 and 2 appear for Windows, task 3 for Mac, and task 6 only when a custom Windows image is still in use.

• Confirm the Windows build path: Autopilot on the factory install or an image — an image is a second product to maintain, so keep one only for a stated reason
• Choose classic Autopilot or device preparation for each role profile — device preparation needs Windows 11 and Entra join; classic adds pre-provisioning and self-deploying mode
• Set the Mac build through Automated Device Enrollment — which Setup Assistant screens to skip, how the user account is created and how the managed admin is handled
• Pin the target OS version for each platform — the version you validate is the version you ship
• Set the minimum OS version a device must reach before it counts as built — factory stock arrives older or newer than the pinned version
• Refresh the custom image with current patches and drivers — and record the capture date, because an old image installs months of updates on first boot

• Define the core app set every laptop gets — browser, office suite, security agent, VPN or zero-trust client and the remote support tool
• Define the extra apps for each role profile — assigned by group, never installed by hand
• Mark which apps must finish during setup and which can follow — keep the blocking list short; each one adds time and a way for setup to fail
• Set configuration profiles for Wi-Fi, certificates, VPN and browser — certificate-based Wi-Fi means nobody types a shared password
• Apply the naming convention through a name template — a prefix plus serial number keeps names unique and traceable to the register
• Record serial, asset tag, order number and warranty end in the asset register — before the device leaves stock, not after the first fault

• Turn on disk encryption with recovery keys escrowed — BitLocker keys in Microsoft Entra ID, the FileVault personal recovery key in the MDM
• Remove standing local admin rights and manage the local admin password — Windows LAPS rotates it and backs it up; Macs get a managed admin account
• Turn on the firewall and stop users switching it off — set by profile on both platforms, not left at the factory default
• Install the endpoint detection and response agent — and confirm the device appears healthy in its console
• Apply the security baseline and resolve conflicts — a baseline that requires a TPM startup PIN stops BitLocker enabling silently
• Set screen lock, sign-in method and update rings — an idle lock of 5 to 15 minutes is a common default to tune

• Build one device of every approved model from out of the box — on a home-grade connection, because that is what a remote starter will have
• Time each build from power-on to desktop and log every failure — a model that takes twice as long as the rest has a driver or app problem
• Check firmware, drivers and security settings after the build — Secure Boot on, TPM present, firmware current
• Verify encryption, admin rights, security agent and compliance on each device — screenshot the compliant status as evidence
• Sign in as a test user and open every role app — a standard account, never an admin one, or permission problems stay hidden
• Reset one device and rebuild it without touching it — it should come back to the same state on its own

The approver named in Phase 1 records a decision on task 4, and the checklist halts until they do.

• Release the candidate build to a pilot group — IT plus a few willing staff from each role profile, for two to four weeks of real work
• Fix or formally accept every pilot issue — each with an owner and a note in the change log
• Write the build standard with a version number and change log — what every device gets, by role and model, and what changed
• Approve the build standard for release — the approver named in Phase 1 records Approved or Not approved; nothing is built to it until they do
• Retire the previous version and brief the service desk — what changed, what users will notice and how to spot an old build

• Confirm every spare is registered and pointed at the right profile — check by serial in Autopilot or Apple Business before it goes on the shelf
• Update spares that were built or unboxed more than a month ago — patches, apps and the standard all move on while a laptop sits in a cupboard
• Label each spare with model, build version and date checked — so the next person knows whether it needs touching
• Check stock against the reorder point for each model — weekly demand times supplier lead time, plus a buffer, is a sensible starting point
• Book the next re-validation and note what would trigger one early — a new model, a new OS version or a change to the security baseline