Creating an .intunewin file does not establish that an application is ready for deployment. The package must install in the intended context, identify the installed version accurately and remain manageable through upgrades and removal. Use this checklist when reviewing a new package or investigating an unreliable Intune deployment.
1. Establish installer behaviour before building the package
Start with a trusted source installer and record its version, architecture, licensing requirements and supported options. Verify the vendor’s silent installation and removal commands. Parameters copied from another product may have different meanings or no effect.
Separate application installation from settings that are better managed through policy. This reduces the need to rebuild an application package for every configuration change.
- Document installation and removal commands.
- Identify required runtimes, certificates, files and network access.
- Confirm supported architecture and operating system versions.
- Define what should happen if an application is open or a restart is required.
2. Test the actual installation context
A manual installation from an administrator session does not validate an installation running as SYSTEM. User profiles, mapped drives and network access can differ. Decide whether installation belongs at device level or user level before choosing the deployment behaviour.
A SYSTEM script that copies settings to the current user profile may write to the wrong location. Keep machine installation separate from configuration that must be applied for each user.
- Test through the intended Intune assignment, not just an elevated terminal.
- Launch the installed application as a standard user.
- Check file locations, registry view and user-specific settings.
- Test a second user when the device will be shared.
3. Design detection around the installed state
Detection tells Intune whether the application is present. A leftover directory is weak evidence of a successful installation. Use an appropriate MSI, file or registry rule, or a detection script when the application requires one.
Detection should inspect state rather than repair the installation. Decide whether an exact version is required or whether a newer version is acceptable, then validate that decision through the upgrade lifecycle.
- The application is absent: detection does not report it as installed.
- The intended version is correctly installed: detection recognises it.
- An older or incomplete installation is not accepted accidentally.
- After removal, leftover artefacts do not produce a false positive.
4. Include upgrades and removal in acceptance testing
Packaging problems often appear only on endpoints that already have an earlier release. Test what happens to settings, user data and shortcuts during an upgrade. Include interrupted installation and restart scenarios where relevant.
Dependencies and supersedence can coordinate application delivery, but they do not replace validation of the installer’s actual upgrade path. Document what is removed and what must be preserved.
- Clean installation and upgrade from the deployed production version.
- Removal without unintended loss of user data.
- Reinstallation after removal or a failed attempt.
- Correct reporting of return codes and restart behaviour in Intune.
5. Use PowerShell and PSADT for a defined requirement
PowerShell App Deployment Toolkit (PSADT) can help standardise logging, user interaction and deployment logic. It does not make an unreliable installer reliable on its own. Add only the logic required by the application and the organisation’s deployment standards.
Record the toolkit version and template used. Keep scripts readable and make failures visible in the logs. Suppressing every error can produce an apparently successful run even when a required operation did not complete.
What should a packaging handover include?
Hand over the source version, installation commands, detection logic, dependencies and test evidence alongside the package. Include known limitations, the application owner and how the next version should be maintained. These details turn a one-off installer into a manageable application.
TechLake supports Intune and SCCM application packaging, PowerShell and PSADT troubleshooting, and packaging backlogs for IT teams in Belgium. An existing package, a reproducible failure and a clear description of the expected behaviour help define a focused assignment.