Administration changes for Workspace ONE UEM Modern SaaS Architecture

Overview

As we proceed with the rollout of the highly anticipated Modernized UEM SaaS Architecture, we are committed to ensuring our customers experience a smooth transition to the new system. In preparation, we have identified important changes that may affect how UEM administrators carry out their daily operations using Workspace ONE UEM 2406 and later.

It is crucial to understand how these changes will occur behind the scenes, as they will directly impact the provisioning of resources and communication between UEM and devices, as well as how you support end users and troubleshoot devices.

Purpose of This Article

In this article, we provide detailed information about the changes made with the modern UEM SaaS architecture that administrators need to be aware of when managing devices through Workspace ONE UEM.

Audience

This tutorial is intended for IT (Information Technology) professionals and Workspace ONE UEM administrators of existing production environments where modern UEM SaaS architecture is enabled.

Checklist for Enabling Modern UEM SaaS Architecture

Certain functionalities may not behave the same way in modern architecture as they did in the legacy system. To ensure a smooth transition, maintain data consistency, and safeguard added resources, it is essential to complete the actions outlined in this section before enabling the modern architecture in your environment.

App and Profile Management Restricted to Customer and Partner Organization Groups or Below

Management of applications and profiles will only be allowed at the following qualifying Organization Group hierarchies with modern SaaS architecture:

• Customer Organization Group (or levels beneath it).
• Partner Organization Group (or levels beneath it).

See below examples of non-qualifying vs qualifying Organization Group.

• ✅ qualifying Organization Group hierarchy - Applications and Profiles can be created or managed here.
• ❌ non-qualifying Organization Group hierarchy - no Applications or Profiles can be added or managed here.

After enabling Modern SaaS architecture in your Workspace ONE UEM environment:

1. New applications and profiles can only be created at qualifying Organization Group hierarchies.
2. Applications and profiles that are either existing or being managed at non-qualifying Organization Group hierarchies will be uninstalled from devices if they were previously installed.
3. Management of applications or profiles from non-qualifying Organization Group hierarchies will no longer be possible.

If there are any applications or profiles in your environment currently existing or being managed outside the qualifying Organization Group hierarchies, reconfigure them within the qualifying Organization Group hierarchy before enabling modern architecture.

For more information, refer the KB article Application and Profile management restricted to Customer Organization Group (and Partner Organization Group) or below in Modern SaaS architecture enabled UEM environments (6000196).

Exclusions Now Managed at Version Level for Internal Apps

Your UEM environment may have devices excluded from receiving internal applications by excluding specific smart groups when creating or editing internal app version assignments (refer below image).

Figure 1: Defining exclusions for smart group assignments

In Workspace One UEM legacy (pre–modern SaaS architecture) environments, exclusions were enforced at the application level based on the bundle ID (a unique identifier shared by all versions of an app, for example com.google.android.apps.maps). If a device was excluded from one version of an application, it was automatically excluded from all versions, regardless of the exclusion configuration for other versions.

However, with the modern SaaS UEM enabled environments, exclusions are enforced at the version level. A device excluded from one version will still be eligible to receive other versions that are not excluded.

Example

Let's consider the below two scenarios where Google Maps app has 2 versions uploaded to UEM.  

Figure 2: Scenarios comparing application exclusion on legacy and modern architecture

In Scenario 1, a device is excluded from version 2, but not from version 1. In legacy UEM, the device will be excluded from installing either of the versions because both versions have the same bundle ID. However, the device will receive version 1 with Modern SaaS UEM architecture because device is not excluded from Version 1. In Scenario 2, a device is excluded from both versions of the app. In such a case, the device will not receive either of the versions under either Legacy or Modern SaaS Architecture.

Therefore, upgrading to a Modern SaaS UEM architecture may result in devices that were previously excluded from receiving any versions of an application now receiving specific versions, depending on the exclusion configuration.

If this behavior is not desirable, we recommend ensuring that devices are excluded from all versions of the internal applications. This can be achieved by updating the same exclusion smart groups across all versions of the affected internal applications before enabling Modern SaaS Architecture in your environment.

     For more information on this topic, refer the KB article Smart Group exclusions now managed at version level in modern SaaS architecture enabled Workspace ONE UEM Environments (6000662).

Invalid Smart Groups

Your UEM environment might have smart groups with invalid criteria, an invalid smart group means it has at least one of the following invalid criteria.

1. Tags are added as criteria in the smart group, but no tags are currently on the selected list.
2. Organization Group is added as criteria in the smart group, but no specific Organization Group was added to the list, nor is any currently present.
3. User Group is added as criteria in the smart group, but no specific User Group was added to the list, nor is any currently present

These invalid smart groups could see deviations in the devices assigned after migrating to the Modern SaaS UEM architecture. This could lead to discrepancies in the resources installed on these devices.

To resolve this issue, we have created a script to ensure consistency in the existing smart group states by adjusting the smart group criteria to retain devices currently assigned to them. Additionally, we have highlighted the invalid smart groups for correction. This script will be executed across all UEM SaaS environments and if your UEM environment has smart groups with the prefix “__Invalid_” in the name, it is impacted.

Please follow the resolution steps outlined in the knowledge article Managing invalid Smart Groups in UEM (6000174) if your environment is impacted.

Resource Delivery and Tracking

The modern architecture introduces new concepts that changes how applications and profiles are managed and delivered by UEM. In this section, we will provide information about key changes, focusing specifically on how they affect the delivery and tracking of applications and profiles in a modern UEM environment. For more in-depth information about Resource Delivery and tracking installation status, check out the Omnissa Workspace ONE Platform Modernization topic part of the Resource Delivery Optimization and Deployment Tracking article.

Consistent Device State Management with Modern SaaS Architecture vs. Legacy UEM

In legacy UEM environments, install or uninstall commands for applications or profiles are triggered by specific events, such as creating or updating assignments, modifying smart group rules, updating critical device attributes, automated workflow actions, and admin actions in the console, among others. As a result, the installation or uninstallation of an application or profile depends on these specific triggers impacting the device.

In contrast, the Modern SaaS Architecture brings devices to their desired state more consistently and automatically, often without requiring a specific trigger. During each device check-in (at least every 4 hours), the device is evaluated against its desired state. Installation or uninstallation instructions are then provided, ensuring the device is updated accordingly without waiting for a specific event.

This means that if an end user manually removes a UEM-managed resource from the device, it will be automatically reinstalled within the next 4 hours (provided the device is not offline). In legacy UEM environments, this would have required a device-specific event to trigger the reinstallation. As a result, you will notice that devices are more consistently, automatically, and quickly brought to their desired state under the Modern SaaS Architecture.

Fast Lane Deployment

In various business scenarios, timely delivery of resources to devices and immediate enforcement of desired state management are crucial for seamless operations. For instance, during device onboarding, shared device check-in/check-out use cases, urgent installation or uninstallation of resources on VIP devices, compliance-driven actions, or testing resource deployments in UAT environments on a small fleet of devices, waiting for devices' regular check-in cycle to bring them to the desired state may not meet business needs. These scenarios require faster responses to ensure devices reach the desired state promptly.

Below are some of the key use cases where Modern SaaS Architecture accelerates resource delivery.

1. Publishing Resources - Fast Lane Deployment is triggered when an application or profile resource, with a total assigned device count lower than 2,000 devices, is published. We are actively working on enhancing this device count limit to a much higher number in one of our future UEM releases. Stay subscribed to this article for updates as soon as the enhanced device count limit becomes available.

Figure 3: Scenario where total assigned devices is less than 2000

Figure 4: Scenario where assignment count increases or decreases

2. Admin actions to install or uninstall resources on a specific device - Fast Lane deployment is initiated when an admin triggers installation or removal of a resource on a device from the Device Details page, or the Deployment Tracking page of the resource, or through the APIs.

Figure 5: Fast Lane deployment invoked when admin forces app install

Figure 6: Example how admin can force app installation from UEM Console

3. End user actions through Hub - A Fast Lane deployment is initiated when an end-user triggers removal or installation of a resource via Intelligent Hub on a device.
4. Device Enrollment - A Fast Lane deployment is initiated to instantly deliver resources to a freshly enrolled device.

Figure 7: Enrollment flow when delivering resources

5. Freestyle Workflow actions - A Fast Lane deployment is initiated when resources are to be installed or removed through Intelligence automations or Freestyle workflows.

Figure 8: Workflow execution and Fast Lane deployment flow when provisioning resources

6. Compliance Policy triggered actions - A Fast Lane deployment is initiated when either resource(s) must be removed, or a compliance profile must be installed on a device based on Compliance policy evaluation on the device.

Figure 9: Fast Lane deployment triggered to deliver compliance policy actions

7. Check in check out of a shared device – When an end-user checks out a shared device, resources assigned to that user are delivered to the device immediately. Similarly, all resources assigned to the user are removed from the device when the user checks-in the device.

Figure 10: Resources delivered through Fast Lane deployment when end-user checks out a shared device

8. Immediate enforcement of device to desired state - A device can be brought to its desired state with respect to all resource installations or uninstallations immediately through the following actions,
   1. An admin performing a “Query” or “Sync Device” action from the UEM Console.
   2. An end user performing a “Sync device” operation from the Intelligent Hub app.

Exclusion behavior change for Internal Applications

Previously, the legacy UEM excluded smart groups from internal app assignments based on the application bundle ID. This meant that if a smart group was added to the exclusion criteria for any version of an internal app, devices in that group would not receive any version of the app. In contrast, the modern UEM evaluates smart group exclusion criteria for each internal app version independently. As a result, if a device is excluded from one version of an internal app but not from another, it will still receive the version it is not excluded from. For more details, please refer section Exclusions Now Managed at Version Level for Internal Apps.

Smart Group Membership Updates in Modern SaaS Architecture

What is changing?

With the introduction of the Modern SaaS Architecture, there are notable changes in how smart group memberships (i.e. determining the smart groups to which a device belongs) are updated. In the legacy UEM architecture, these memberships were updated immediately after changes such as smart group rule modifications, changes to a device attribute, addition or removal of tags to a device, or when a device was moved to a different Organization Group.

In the Modern SaaS Architecture, smart group memberships are only updated during the device’s next scheduled check-in. At that time, the system evaluates the device’s desired state and takes the necessary actions to install or remove resources.

Which use cases are being impacted?

These changes might impact the timing and flow of resource provisioning, such as installation and removals (ex: apps, profiles), for some use cases that may have required immediate resource delivery in response to changes such as adding or removing a Tag. Omnissa engineering team is actively working to fix this experience and will release an update to improve this functionality in an upcoming UEM release.

Example of resolution for tag use cases

Recognizing that tagging operations are essential for many administrators managing their device fleets, it is important to understand how to handle resource provisioning and de-provisioning when Tags are added or removed. In certain scenarios, immediate action is needed, particularly for user break-fix scenarios or similar remediations.

Immediate Resource Updates Post-Tagging

For situations where administrators require immediate changes to resource provisioning/de-provisioning based on Tag changes, until the out-of-the-box solution is released we recommend the following two workarounds,

1. Manual Query Device: After a tagging operation (add/remove tag), administrators can manually trigger a Query Device to force an immediate check-in and resource update. This can be done via the Query button in the Device Details view.
2. Automated Query Device in Workflows: For Intelligence Freestyle Workflows that are configured to tag devices based on specific trigger events (e.g., automatic triggers), administrators can add a Query Device step immediately following the Add/Remove Tag step. This ensures the tagged devices receive the necessary resource updates in real-time.

While the manual or workflow-triggered Query Device option can provide immediate resource updates, it is important to use this approach judiciously. Overusing the Query Device action can negatively impact performance, especially when handling a large number of devices.

When to rely on the pull-based model:

• For bulk tagging operations involving many devices (either via the UEM Console or API).
• For scheduled or manual workflows that perform tagging operations on large device groups.

In these cases, we strongly recommend allowing devices to process the changes during their next scheduled check-in rather than forcing immediate updates via Query Device. This approach leverages the efficiency of the pull model, ensuring smoother performance.

Device Troubleshooting Event Logging

Device troubleshooting events are essential for administrators to diagnose and resolve issues, especially when resource delivery to a specific device encounters a problem.

The modern UEM architecture generates two types of actions to manage delivery of applications and profiles: Install and Remove. A range of events are generated, each with different statuses, to track the progress of these actions. An admin can find these events under the ‘Troubleshooting’ section on Device Details page.

Refer to the following flow chart to understand a typical flow of actions and events generated when an application is required to be installed on a device.

The following flow illustrates the application removal actions and events:

Note that the events remain the same, regardless of the source from which they are triggered - whether it's install or uninstall actions initiated by admins, end users, or APIs, compliance-driven actions, automated workflow triggers, or during scenarios like enrollment and check-in/check-out.

Below is a comprehensive list of all device events generated by Modern SaaS Architecture-enabled UEM environments to track delivery of applications and profiles.

Known Issues

We have identified areas for improvement in the migration to the Modern UEM SaaS Architecture and have recommended temporary workarounds until permanent fixes are available. Below is a list of the current known issues.

• Modern Stack Device-Based Events are not exported via Syslog Integration.
• Evaluated device count higher than Assigned count in Deployment Tracking for Modern SaaS Architecture enabled UEM Environments
• Known Issue with Sorting Applications on Device Details Page with Modern SaaS Architecture Enabled UEM Environments
• Profiles Assigned Through Freestyle Workflows Installed on Unintended Devices
• Profile List View crashes when Android AMAPI profile is configured with 'Custom Messages' payload
• Product Profiles Listed on Device Profiles List View

Summary and Additional Resources

 This article provides an overview of key changes and considerations for administrators transitioning to the new Modernized UEM SaaS Architecture in Workspace ONE UEM (version 2406 and later). It focuses on how modern architecture affects resource delivery, device management, and troubleshooting.

Key topics include:

• Checklist for Enabling Modern Architecture: Steps to prepare for a smooth transition, including reconfiguring application and profile management at qualifying Organization Group hierarchies.
• Smart Group Exclusion Changes: In the modern system, exclusions are managed at the app version level rather than the application bundle ID level, meaning devices may receive different version of the same app depending on exclusions.
• Resource Delivery and Sync Frequencies: The modern architecture improves resource delivery, with devices automatically reaching their desired state during frequent check-ins (every 4 hours), unlike the legacy system, which required device sync triggers.
• Fast Lane Deployment: Allows immediate device check-ins for critical updates, such as VIP devices or time sensitive use cases.
• Device Troubleshooting Event Logging: Enhanced event tracking provides better visibility into resource installation and removal actions on devices.

Additionally, administrators are advised to review and resolve invalid Smart Groups that could lead to discrepancies after migration.

The changes aim to optimize UEM management, offering more consistent device states and faster resource deployments.

Additional Resources

 To learn more about the Workspace ONE UEM Modern SaaS Architecture and most recently released features that leverage this architecture, checkout the following resources:

• UEM New Architecture: User and Device Experience
• Security Posture of the UEM Modern Architecture
• Resource Delivery Optimization and Deployment Tracking
• Omnissa Community

Changelog

The following updates were made to this guide:

About the Author and Contributors

This document was written by:

•  Andreano Lanusse, Staff Architect, Technical Marketing, Omnissa.
• Shambhavi Chaugule, Senior Product Manager, Omnissa.
• Sivapratap Reddy Chintam, Director of Product Management, Omnissa.

Feedback

Your feedback is valuable.

To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.