# 1. Define "Basic Staff Machine" **STEP 1:** Pull together a concrete list of what Altiris was pushing to a standard fac/staff machine. Check existing Altiris application/package jobs and software delivery policies for the baseline set - things like: - Browser(s) beyond the built-in one (Chrome, Firefox) - Office suite/M365 apps (if not already handled via a different channel) - PDF reader, Zoom/Teams, endpoint security/antivirus agent, VPN client - Any university-specific line-of-business apps (LMS clients, printing software, etc.) - Baseline configuration Altiris applied outside of “apps” per se — things like default printer setup, mapped drives, registry tweaks, or local security settings This matters because *each item on the list will map to a different deployment mechanism in Intune,* and knowing the full list upfront avoids rebuilding your approach halfway through. ***Broadly, things will fall into:*** - **Win32 apps** - most traditional MSI/EXE installers (this’ll be the bulk of it) - **Microsoft Store apps** — anything available via the Store for Business/new Store integration - **Windows apps (winget)** — increasingly viable for common software - **Configuration profiles** — not an “app” at all, but the settings/registry/policy pieces Altiris used to push as configuration rather than installers ***Why is this the right first move rather than jumping straight to packaging?*** Intune's Win32 app tooling requires you to prep and upload the `.intunewin` package for *each individual app* - it's more manual per-app effort than Altiris' broader imaging/job model. Knowing your full target list before you start means you package once, correctly, rather than discovering three more required apps after you’ve already built out detection rules and assignments for the first batch. *Once you've got the list . . .* --- **STEP 2:** Download the [**Microsoft Win32 Content Prep Tool (GitHub)**](https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool) and package the first app into `.intunewin` format - Requires `.NET` **Framework 4.7.2** (on Windows machines) *Sample **Content Prep Tool** commands:* ```bash IntuneWinAppUtil -c <setup_folder> -s <source_setup_file> -o <output_folder> <-q> ``` - Generates the `.intunewin` file from the specified folder and setup file - For `MSI` setup file, this tool will retrieve required info for Intune - If `-a` is specified, all catalog files in that folder will be bundled into the `.intunewin` file - If `-q` is specified, it will be in quiet mode If the output file already exists, it will be overwritten - Also, if the output folder does not exist, it will be created automatically ```bash IntuneWinAppUtil ``` - If no parameter is specified, this tool will guide you to input the required parameters step by step. >[!warning] WARNING! >Everything on campus that we officially support should, at minimum, be a machine on Windows 11 on x patch --- >[!danger] YouTube Resource >[How to Create an Intune Win32 App Package (.intunewin) - Step-by-Step Guide](https://youtu.be/yILrSTjYQQs?si=jqCCH6JLpViHij8r) --- # Linux Alternatives for Creating `.intunewin` There are two different Go CLI apps that can create `.intunewin` files for your Intune apps: [LetsGoIntunePackager (GitHub)](https://github.com/michelbragaguimaraes/LetsGoIntunePackager) [Intunewin (GitHub)](https://github.com/kenchan0130/intunewin) ## Other Jesse says that we do not need to worry about AD login with machines and Intune. Only the OOBE Okta SSO, and the Microsoft Account sign in once you boot into Windows and have been logged in.