An application deployment can show a green result in an administrative console and still fail the person waiting to use it. Perhaps the executable installed but a dependency is missing, a detection rule mistakes an older release for the current one, or the app works only when an administrator signs in. Preparing for Microsoft MD-102 means understanding those differences. Intune is not simply a way to upload an installer and select a group. It is a system for declaring the desired software state, targeting the right devices, verifying that state and correcting failure without making an organization depend on manual intervention.
Consider an accounting firm replacing a legacy finance client across 2,400 Windows laptops. Some devices are recently provisioned, others have a previous version, and a third group connects only sporadically. An engineer has to select a suitable packaging method, express the prerequisites, decide whether the installation is mandatory and show that the correct version is usable. The hardest work happens before anyone presses Deploy. This case provides a useful frame for the application-management objectives in MD-102, particularly installation methods, assignments, updates, app configuration and protection.
Start with the real installation contract
Every installer has a contract, whether its vendor documents it well or not: operating systems and architectures it supports, permissions it needs, reboot behavior, prerequisite packages, uninstall behavior, and a verifiable installed result. Obtain those facts on representative hardware. A setup wizard that works during an interactive trial can fail silently in the SYSTEM context used by a managed install. A command that returns success before the installer finishes may give Intune an early success signal. An application that writes essential settings into the installing user’s profile may not be ready for a different user on the same machine.
Record an explicit install command and uninstall command, including quiet-mode switches and expected return codes. Treat reboot-required exit codes differently from genuine failures, because suppressing a necessary restart indefinitely leaves the device in a partial state. Test both first-time installation and upgrade, including what happens when an older user profile contains incompatible settings. The package must not depend on the packaging engineer’s mapped network drive, cached credentials or an undocumented download server accessible only in the office.
Match the Intune app type to the delivery model rather than forcing every package into the same workflow. Windows Win32 applications are a good fit for complex desktop installers with detection logic, dependencies and supersedence. Microsoft Store applications follow a different acquisition and servicing model. Microsoft 365 Apps have configuration choices tied to suites, channels and languages. Line-of-business packages and app-specific deployment methods have their own constraints. An examiner may present a straightforward Store app alongside a complex MSI-based desktop product; the management mechanism is part of the answer.
Requirements and detection solve different questions
A requirement rule asks whether this endpoint is eligible to attempt the deployment. Examples include supported architecture, operating system version, enough disk space or the presence of a specific prerequisite. A detection rule asks whether the desired application state is already present. Confusing the two produces recurring installations or persistent ‘not applicable’ states. In the finance-client example, Windows 11 and x64 might be requirements, while the presence of version 7.4 or later in a documented product location might be part of detection.
Use the strongest reliable signal. A mere executable’s existence can be misleading if a previous release left the file behind; a registry product identifier may be more useful for an MSI, while a file-version check can establish the current release for other installers. PowerShell-based detection can handle difficult applications but must be deterministic, return the correct success indication and avoid assuming a logged-on user. Evaluate 32-bit versus 64-bit registry and filesystem redirection before interpreting a mismatch. For compound detection, understand that configured checks can all be required; an unnecessarily strict combination can mark working software as absent.
The practical troubleshooting sequence is to identify the phase that failed. ‘Not applicable’ suggests requirements or targeting; an installation error points toward command execution, privileges or dependencies; repeated installation can implicate detection; ‘Installed’ with a broken user experience calls for post-install configuration testing. Intune’s app reporting and management-extension logs answer different questions. Neither should be replaced by speculation based only on the final status badge.
Assignments determine who gets which experience
Required and Available assignments represent different obligations. Required software is deployed automatically to a targeted population; Available software can be offered for user initiation through supported self-service channels. Uninstall assignments intentionally remove software. The organization must decide whether an app is part of a baseline, available by request, or being retired. These are separate business decisions, not merely technical checkboxes. Targeting also interacts with device and user groups, assignment filters, enrollment state and licensing.
For the finance client, a pilot might include twenty accounting devices across different office locations, connection types and user privilege profiles. Do not test only fast, freshly provisioned laptops. Include an older client, one machine with low free space, one rarely connected endpoint and one user without local admin rights. Use staged groups to reduce blast radius. Device-based assignments may suit shared workstations, while user-based assignments may make sense for software licensed to people; validate install context and permissions for each choice.
Dependencies and supersedence address different lifecycle problems. A dependency makes one Win32 app contingent on another, such as a runtime library that must be installed first. Supersedence describes an application that updates or replaces an earlier Win32 application, with a deliberate choice about whether the old version should be uninstalled. An update that preserves user configuration may need a different replacement strategy from a product migration that changes the application identity. Do not assume supersedence automatically fixes incompatible data or removes abandoned configuration. Test upgrade paths and the rollback plan, not just clean installations.
Application configuration is part of deployment quality
The installer is only one component of a working business application. Users may need environment selection, server URLs, certificates, allowed add-ins, browser integration or a consistent default file association. Intune configuration policies, app configuration settings and platform-specific management controls can help express those requirements, but they must be chosen for the app and operating system in question. The presence of an app icon proves almost nothing about whether the application can reach a backend securely or whether a user can sign in.
Configuration can also conflict with identity requirements. A device without compliant state may be unable to obtain a token for a protected service even though the binary installed successfully. Conversely, a user who can sign in may still lack an application license or a required role. Understand the interaction with Microsoft Entra Conditional Access while keeping app deployment, app authorization and device compliance conceptually distinct. This is particularly important in scenario questions that hide an identity problem behind the phrase ‘application is not working.’
On personally owned mobile devices, application protection policies may protect organizational data without requiring full device enrollment, depending on the supported app and platform. Managed app configuration is not interchangeable with application protection. Configuration influences how the app behaves; protection may restrict transfer of corporate content, require app-level access conditions or govern the corporate-data lifecycle. If an exam asks for protection of corporate information in a personal mobile app, enrolling every device and pushing a desktop installer is not necessarily the right design.
Diagnose failure from evidence, not intuition
Imagine that a new version is reported as installed on 96% of devices, but help-desk tickets surge. Break down the failure population before changing assignment globally. If installations fail primarily on devices with the older client, investigate upgrade and supersedence behavior. If remote users succeed only on VPN, the installer may fetch files from an internal dependency. If the application launches but cannot connect, test proxy paths, TLS trust and service permissions. If one business unit sees a different configuration, inspect policy scope and effective targeting.
An orderly investigation begins with the device record, app assignment and installation status, then moves into relevant endpoint logs and the installer’s own diagnostics. Capture exact product version, exit code, deployment context and timestamp. A user stating ‘nothing happened’ is not equivalent to Intune recording ‘not applicable’. Correlating those observations stops teams from repackaging an otherwise healthy installer. The broader MD-102 endpoint administration pathway becomes easier to understand when device management is treated as a set of interacting controls, not isolated portal blades.
Some failures are caused by rushed remediation. Repeatedly pushing an uninstall policy can remove a still-required app; disabling detection to make a dashboard green can conceal a broken endpoint. A safer rollback identifies a known-good package, tested supersedence reversal or alternate application path and the devices to which it applies. Put a stop criterion in the rollout: if critical transaction errors exceed a defined threshold, pause expansion and investigate rather than waiting for all devices to fail.
Maintain the software state after launch
The successful rollout is not the end of the application’s life. Versions age, vendors change signing certificates, security advisories require urgent patches and Windows platform updates alter dependencies. Build a process that records package provenance and installer hashes, determines who approves releases and identifies which devices remain on unsupported versions. Measure actual deployment completion, not only the number of assigned devices. A device offline for weeks should be reported as an operational exception, not silently counted as healthy.
When a vendor releases a high-priority security update, determine which devices can accept an in-place upgrade, which need an uninstall/reinstall path and which require a reboot. A staged deployment may use rings appropriate to the application’s business risk, while a critical exploit may justify faster rollout and enhanced monitoring. Applications supporting regulated processes require additional attention to change evidence, audit logs and user communications. The organization’s release calendar can matter as much as technical package validity.
Finally, separate installation control from privileges. App teams should have appropriate permissions to maintain packages, but broad access to modify all enrollment or security policies is not always justified. Administrative roles and role-based access control can constrain who modifies deployments, who approves exceptions and who reviews sensitive application data. A package-install capability can execute privileged code on thousands of devices; it deserves change control comparable to other high-impact administrative functions.
For MD-102, ask of every application scenario: what must be installed, who needs it, what prerequisites must hold, which mechanism verifies state, how will it be updated, and what evidence establishes success? This sequence turns unfamiliar app questions into solvable engineering decisions. The right answer is seldom ‘deploy the app’ alone; it is the design that makes the application secure, usable, maintainable and recoverable across real endpoint diversity.