Windows Required Apps: Hexnode Store apps not installing system-wideSolved

For this use case, deploy the applications as Windows Enterprise Apps rather than relying on the Hexnode Store package. Some Hexnode Store packages, including certain Slack builds, are packaged as per-user executables. A per-user installer is designed to install under the logged-in user profile, such as %LocalAppData%, and does not natively support machine-wide installation under the Windows SYSTEM context. Because of that, Hexnode UEM resets the “Install app at system level” option when the installer cannot support system-level scope.

For a silent machine-wide baseline, download the official vendor MSI or system-wide installer and add it from Apps > +Add Apps > Enterprise App > Windows. For example, use the Slack Machine-Wide MSI, Google Chrome Enterprise MSI, and the official 1Password MSI or system-wide EXE with the required silent parameters. Then add those Enterprise Apps to a Windows Required Apps policy.

Regards,
Isabel Lora
Hexnode UEM

That explains the Slack checkbox behavior. But can Hexnode Store apps be deployed through a Windows Required Apps policy at all? I only see the Hexnode Store tab as a catalog, and I don’t see checkboxes or an add button there. Under +Add Apps, “Store App” opens Microsoft Store search results, not the Hexnode Store catalog.

Hi @hugo_l ,

Hexnode Store apps cannot currently be added to Local Apps or deployed through a Windows Required Apps policy. There is no separate click path under +Add Apps to add a Hexnode Store app into the local app inventory, and this is not a subscription-tier or technician-role limitation.

The Hexnode Store tab operates separately from the central App Inventory. Hexnode Store apps are intended for deployment through Actions > Install Application, Automate > App Distribution, or the self-service App Catalog. If you see device counts for a Hexnode Store app, those installations may have been triggered by remote actions, enrollment automations, or user-initiated App Catalog installs, not by a Required Apps policy.

Regards,
Isabel Lora
Hexnode UEM

For a standard Windows baseline on newly enrolled devices, would you recommend a Required Apps policy targeted to a dynamic Windows device group, or Automate > App Distribution with an enrollment trigger? We want apps installed automatically, but we also want to avoid version loops later when apps update.

Hi @wyatt_simmons ,

Use a Required Apps policy targeted to a dynamic Windows device group when you need persistent compliance. For example, a dynamic group with Platform = Windows will automatically include newly enrolled Windows devices, and the Required Apps policy will reinstall an app if it is removed or becomes missing later.

Automate > App Distribution with an On Device Enrollment trigger is better for a one-time install during enrollment. It pushes the app once, but it does not continuously enforce the app afterward if a user removes it.

For a strict baseline where the app must remain installed, use Required Apps with Enterprise Apps.

For a baseline where Patch Management or the app’s own updater will manage versions afterward, a one-time automation or remote install can be cleaner.

Regards,
Isabel Lora
Hexnode UEM

How do updates work for Enterprise Apps added from MSI files? If I upload Chrome or 7-Zip as an Enterprise App, will Hexnode automatically check the vendor site for newer versions? Also, can Winget or Patch Management update the same apps without Required Apps pushing the older MSI again?

@hugo_l , Hexnode UEM does not automatically monitor vendor websites for newer MSI releases for Enterprise Apps. A Required Apps policy deploys the version stored in your App Inventory until you update that app record. Patch Management or Winget can be used to keep supported third-party apps updated.

If Winget updates an app to a newer version and the vendor package supports proper in-place upgrades, Hexnode UEM will not intentionally downgrade or overwrite the newer version just because the Required Apps policy contains an older installer. However, policy reporting may show version-related discrepancies if the compliance check expects a specific stored version. To avoid repeated reinstall or version-compliance issues, use one of these approaches:

• Keep the Enterprise App record updated when you want Required Apps to enforce a specific version, or
• Use Automate > App Distribution / Actions > Install Application for the initial install and let Patch Management handle ongoing updates.

If using “From Manifest URL,” replacing the MSI at the same URL helps new deployments fetch the updated package, but upgrades for already-enrolled devices still require the version in the Hexnode App Inventory record to be incremented.

Regards,
Isabel Lora
Hexnode UEM