Short introduction
This article explains how Workspace ONE UEM delivers applications to Windows endpoints, the prerequisites, the differences between Intelligent Hub and the App Deployment Agent, packaging options, detection approaches, assignment using Smart Groups, staged rollouts (deployment rings), verification techniques, and practical troubleshooting. It's written for Windows and Workspace ONE administrators who need a reliable, repeatable deployment process.
What Workspace ONE UEM does for Windows app deployment (overview)
Pushes installers and required configuration to managed Windows devices.
Supports multiple package delivery methods and package types (MSI, EXE, ZIP, and other supported formats).
Uses device-side components (Intelligent Hub or App Deployment Agent) to receive, trigger, and report on installs.
Uses detection criteria to determine whether an app is installed or requires remediation.
Applies assignments through Smart Groups so you can target users, devices, or deployment rings.
How Workspace ONE UEM deploys Windows apps (conceptual flow)
Administrator adds an application record in the Workspace ONE UEM console (either as a Native/Internal app in the Enterprise App Repository or via the Application File method).
Workspace ONE stores the artifact (or references it) and associates install/uninstall commands and detection rules with the app record.
Devices receive policy and assignment metadata via the management channel.
The device agent (Intelligent Hub or App Deployment Agent) evaluates detection criteria and, if needed, downloads and executes the installer commands.
The agent reports status back to the console for monitoring and troubleshooting.
Prerequisites
Devices must be enrolled and compliant with your Workspace ONE UEM policies.
The correct device-side agent must be installed and healthy (Intelligent Hub or App Deployment Agent; see next section).
Required network access to the repository or delivery point holding installers.
Administrative credentials and roles in Workspace ONE UEM to create and assign applications.
Application packages should be tested in a lab to confirm silent install/uninstall behavior and that detection criteria correctly reflect installation state.
Intelligent Hub vs App Deployment Agent — when to use each
Intelligent Hub
The primary Workspace ONE client installed on user devices.
Can receive app policies and initiate installs for many app types.
Preferred where you want unified endpoint management through a single agent.
App Deployment Agent (ADA)
A dedicated component focused on robust software distribution and complex install scenarios.
Useful when you need advanced delivery reliability, background delivery, or where the ADA’s delivery semantics are required.
Choosing between them
Use Hub for standard, user-driven installs and where a single agent experience is desirable.
Use ADA for heavier software distribution needs or when Omnissa documentation indicates ADA is required for specific package behaviors or delivery guarantees. (Consult your environment’s guidance for agent selection.)
Native/Internal apps vs Application File method
Native/Internal apps (Enterprise App Repository)
Managed inside the Enterprise App Repository.
Workspace ONE stores the application artifact and metadata centrally for distribution.
Best for curated, organization-owned installers and when you want repository-based lifecycle management.
Application File method
Uploads an application package file directly as part of an application record, or references an external file location depending on configuration.
Useful for single artifacts or when you prefer lighter-weight records for simple deployments.
Considerations
Use the Enterprise App Repository for repeated, managed enterprise deployments.
Use Application File for ad-hoc or one-off installs where repository lifecycle features aren’t required.
Supported package types
Workspace ONE UEM supports common Windows packaging formats. Administrators should verify specific support in the Omnissa documentation for the platform version in use, but generally supported types include:
MSI packages — preferred where possible due to standard Windows installer behavior and built-in silent options.
EXE packages — supported when they provide silent or unattended install switches.
ZIP or compressed bundles — supported when Workspace ONE or the device-side agent can extract and run the enclosed installer.
Other formats may be supported depending on product version and agent capabilities; check Omnissa documentation for details for your deployment.
Configuring install and uninstall commands
Purpose: The install/uninstall command fields tell the device agent what command line to run to perform the operation.
Conceptual steps:
Identify the silent/unattended switches for your installer file (MSI has standard switches; EXE may have vendor-specific switches).
Place the installer in the repository or make it accessible to devices.
In the application record, specify the command to run for install and uninstall — include any required working directory and elevated execution context if needed.
Configure timeouts and retry behavior as supported by Workspace ONE.
Important: Do not assume default installers are silent. Always verify silent/unattended parameters with vendor documentation and test them in a lab. The article intentionally avoids exact CLI examples; use the vendor-specified switches and the Omnissa console fields to configure commands.
Detection criteria options
Workspace ONE evaluates detection criteria to decide if an install/uninstall is needed. Common detection types (conceptual) include:
MSI product code — determines presence by Windows Installer product identifier.
File or folder existence — checks for a specific file path or folder created by the application.
Registry key/value presence — validates installation via registry entries (HKLM or HKCU).
Process or service presence — checks whether a specific process or Windows service exists/runs.
Custom script output — where supported, a script can return a success state indicating installation. (The user-supplied research disallows including granular detection scripts here — use them only when documented and tested.)
Best practice: Choose the simplest, most reliable detection that uniquely identifies the application with minimal false positives (for example, an MSI product code for MSI installs).
Assignment via Smart Groups
Smart Groups are dynamic groups defined by membership rules (device attributes, OS version, enrollment status, tags, etc.).
Use Smart Groups to:
Target devices by attributes (e.g., Windows 10/11, device model, OU).
Create deployment rings (test, pilot, broad) by tagging devices or using device attributes.
Process:
Create or update Smart Groups to reflect your deployment rings or target sets.
Assign the application to the Smart Group with the desired deployment type (Required, Available, or On-Demand).
Set scheduling, maintenance windows, or priority where supported.
Confirm that Smart Group membership evaluation happens on the expected cadence, and that devices have attributes required for membership.
Testing, deployment rings, and staged rollouts
Always stage deployments with rings:
Lab/Test ring — small number of devices under direct admin control.
Pilot ring — representative business users or machines.
Broad deployment — entire target population after confidence is achieved.
Use Smart Groups or tags to implement rings programmatically.
Staged rollout tips:
Start with Required = False (Available) in early rings to validate installation behavior before forcing installs.
Monitor logs and console reports closely after each ring.
Use rollback/uninstall assignments to a test group to validate uninstall behavior before wide rollout.
Schedule deployments during maintenance windows to reduce user impact.
Verification methods
Console reporting — check install status, success/failure counts, and device logs reported to Workspace ONE UEM.
Device logs — review client-side logs from Intelligent Hub or App Deployment Agent for error codes and detailed execution traces.
Endpoint verification — remote into a device or use scripting (where permitted) to check for files, registry keys, services, or MSI product codes that confirm installation.
User confirmation — for user-facing apps, confirm with pilot users that the application works as expected.
Automated health checks — incorporate detection criteria that can be re-run by the agent to verify on-device install state and allow Workspace ONE to remediate automatically.
Troubleshooting checklist
Enrollment/Agent health
Is the device enrolled and reporting to Workspace ONE?
Is the Intelligent Hub or App Deployment Agent installed and up to date?
Assignment and membership
Is the device a member of the correct Smart Group?
Does the assignment type and schedule allow installation now?
Package access and delivery
Is the installer accessible from the device (network path, repository permissions)?
Was the artifact uploaded correctly to the Enterprise App Repository or Application File?
Installer command and privileges
Are the install/uninstall commands correct and do they require elevation?
Is UAC or other security blocking silent installs?
Detection criteria
Are the detection rules accurate and not producing false positives/negatives?
Try a manual verification on a test device to confirm detection matches actual state.
Agent logs and server logs
Collect client logs (Hub/ADA) and server-side application event logs; search for error codes or timed-out operations.
Retry and timeouts
Has the agent reached its retry limit or timed out? Increase timeout in console if necessary for large installers.
Conflicting software
Check for locks on files, running processes, or vendor-specific uninstallers that interfere with install.
Rollback and re-deploy
If an install fails repeatedly, remove the package, clear detection artifacts on a test device, and re-deploy with modified commands or different package format (e.g., MSI vs EXE).
Best practices
Package preparation
Prefer MSI packages when possible for predictable silent installs and MSI detection.
Test all installers in a lab environment across representative OS builds.
Detection reliability
Use authoritative detection criteria (MSI product code or deterministic registry keys) rather than simple files that may change.
Deployment strategy
Implement deployment rings and never deploy to production directly.
Use phased rollouts and monitor each ring before progressing.
Agent considerations
Ensure devices run the recommended agent version; coordinate Hub and ADA updates during maintenance windows.
Permissions and access
Ensure device accounts have required network access and repository permissions to download artifacts.
Monitoring and alerts
Configure console alerts or regular reporting for failed installs so issues are addressed quickly.
Documentation and rollback
Document install/uninstall commands, detection logic, known quirks, and rollback steps for each application.
Security and compliance
Validate installers for integrity and sign where possible. Keep an inventory of application versions deployed.
Practical deployment checklist
Step 1 — Prepare and test the package
Confirm vendor silent install switches and compatibility.
Test installation and uninstallation on a clean test device image.
Determine authoritative detection criteria.
Step 2 — Create application record
Upload artifact to Enterprise App Repository or use Application File method.
Enter conceptual install/uninstall commands and configure timeouts.
Configure detection criteria (MSI code, registry, file existence, etc.).
Step 3 — Configure assignment and rings
Create Smart Groups for test/pilot/production rings.
Assign the app to the test Smart Group as Available first, then Required when ready.
Step 4 — Monitor and verify
Monitor console install success/failure counts for test devices.
Collect client logs from Hub or ADA on failures and resolve issues.
After success in test/pilot, progressively expand Smart Group assignments.
Step 5 — Full rollout and maintenance
Convert assignment to Required for production ring if desired.
Maintain documentation for future updates and provide rollback guidance.
Important limitations and warnings
Do not assume every third-party EXE supports the same silent parameters; vendor documentation and testing are required.
Detection rules that are too broad can cause inadvertent remediation loops; choose precise criteria.
Some installs may require user interaction or reboots; plan maintenance windows and define reboot behavior as supported by Workspace ONE.
If you need exact command-line templates or detection scripts, request or consult validated internal runbooks and the Omnissa documentation — do not invent commands.