I85PREP
⌘ K
MD-102 study materials
MD-102 study resources

Superseding a Line-of-Business App That Keeps Reinstalling Itself

MD-102 · Put your knowledge to work in context.

All case studies

Superseding a Line-of-Business App That Keeps Reinstalling Itself

Fabrikam ships a line-of-business client called SalesTool that installs an HKLM service and writes a per-machine configuration file. The vendor distributes a 2.4 GB .intunewin package. v3.2 is on roughly 400 laptops and v3.4 must replace it. A required VPN client must be present before SalesTool will start, because the SalesTool launcher calls the VPN service. Forty percent of laptops are shared by shift workers and are wiped and re-imaged between shifts. 800 devices should get the companion app from the Microsoft Store. Several sites are on metered satellite links, and the same 300 devices reinstall SalesTool every single day. The current Win32 app uses a file-version detection rule pointing at a file under the user's profile.

1. Diagnose why SalesTool reinstalls daily and state the detection rule you would ship instead.

Read the worked answer

Diagnosis. A Win32 app is 'required' every day because Intune evaluates the detection rule on each agent cycle and concludes the app is absent. The rule points at a file under the user profile, and the Win32 app installs in SYSTEM context - SYSTEM has a different profile, so the file it just wrote is invisible to the check. Classic false negative.

Other causes worth ruling out before you change anything:

  • Registry/file checks hitting WOW6432Node because a detection script ran in 32-bit PowerShell.
  • Version string mismatch - checking 3.4.0.0 when the binary reports 3.4.
  • The MSI repairing itself because a per-user file was removed by the shift wipe.

Ship instead:

  • Primary: MSI product code detection with a version comparison operator - the product code is written to HKLM and survives any user context.
  • Fallback if there is no MSI: HKLM registry value plus a file-version check against the program files path.
  • Confirm with the Intune Management Extension logs (AppWorkload / AppDiscovery) on one affected device before and after the change; you want to see the detection go from NotDetected to Detected without a reinstall.

Do not paper over it by setting the install to 'not reinstall if detected' or by hiding the app - that leaves 300 laptops churning 2.4 GB a day.

2. Choose between dependencies and supersedence for the VPN client and for v3.4 replacing v3.2, and explain the risk if you get it wrong.

Read the worked answer

VPN client -> dependency of SalesTool. A dependency means 'install this other app first'. It enforces order and does nothing else; it will not upgrade or remove the VPN client later. That matches the requirement, which is purely 'must be present before SalesTool starts'.

v3.2 -> v3.4, use supersedence with uninstall. Mark v3.4 as replacing v3.2 with the uninstall option so the old version is actually removed rather than left side by side. Both apps must be assigned, with v3.4 targeted at the same group that has v3.2, and the supersedence direction must be set on the new app.

Risk if you get it wrong:

  • If you make v3.4 a dependency of nothing but leave v3.2 assigned as required, both versions remain targeted and the device fights between them - the older app's detection keeps failing and reinstalling it.
  • If you set supersedence before fixing the detection rule, the broken rule makes v3.4 look absent, so Intune uninstalls and reinstalls in a loop across 400 laptops.
  • Supersedence with uninstall must be rehearsed on the three test devices; some vendors leave registry keys behind that break the v3.4 installer.

Sequencing: fix detection -> pilot supersedence - > broaden, and remove the v3.2 assignment only once v3.4 reports installed everywhere.

3. How do you deliver a 2.4 GB package to metered satellite sites and to shared shift laptops without saturating the links?

Read the worked answer

Content path. Host the .intunewin in Intune; do not co-locate it at sites you cannot update. The package is downloaded by the Intune Management Extension, so the plan is about when and from where, not if.

Delivery Optimization profile:

  • Set download mode so peers help (LAN or group mode) rather than HTTP-only everywhere.
  • Use DO group IDs scoped per site so a satellite site shares chunks internally instead of pulling 2.4 GB per device across the link.
  • Cap background bandwidth on the constrained site groups, and keep foreground (user-initiated) uncapped so helpdesk fixes are not throttled.

Scheduling. Assign the app as required with an install deadline outside shift hours rather than 'as soon as possible'. Stagger site waves over several nights - 400 devices at 2.4 GB is close to a terabyte, and a 20 Mbps link cannot absorb that in one night.

Shared laptops. The app installs in system context, so it is installed once per device and applies to every shift user; do not ship a per-user variant, or each shift re-triggers the install. Because the devices are re-imaged between shifts, make sure the app is assigned to a dynamic device group (not a stale static list) so re-imaged devices pick it up automatically.

Store app. Use the Microsoft Store app type for the companion app: it is small and updates itself, so it should not consume the same bandwidth budget - keep it out of the same maintenance window.