Mathieu Beaugrand's Blog

Azure Lab Services retirement - Choosing the right EUC platform for what comes next

Wed, 01 Apr 2026 00:00:00 +0000

The retirement of Azure Lab Services isn’t just another platform change. Azure Lab Services didn’t just provide infrastructure, it removed complexity. Its retirement doesn’t just remove a service. It puts that complexity back on you. It’s a forcing function to rethink how organisations deliver training environments, proof-of-concept platforms, and secure, repeatable desktop experiences.

For years, Azure Lab Services provided something rare in the cloud world: Simplicity with control.

Now, with its retirement scheduled for June 2027, that simplicity is gone, and organisations are being pushed toward new architectures and Microsoft acknowledges there is no like-for-like replacement.

Microsoft’s guidance is clear:

Move to Azure Virtual Desktop (AVD)
Complement it with tools like Nerdio for management

But here’s the real question: Are you replacing a service… or redesigning your entire EUC platform?

From simplicity to assembled solutions

Azure Lab Services abstracted complexity:

Provisioning was simple
Lifecycle was controlled
Environments were repeatable

In contrast, the recommended AVD + Nerdio approach is not a single solution. It’s a composition of Azure infrastructure, the AVD control plane, and a management layer like Nerdio, each solving part of the problem, but none owning the full experience.

The shift is subtle but significant: you move from consuming a platform to managing an ecosystem. This is where Omnissa Horizon Cloud differentiates itself, not as an add-on, but as a complete platform.

1. Application lifecycle: App packaging vs image sprawl

In AVD environments, application delivery typically relies on golden images, MSIX app attach (Low app compatibilty), and packaging pipelines, often resulting in image sprawl and complex update cycles.

With Horizon Cloud, App Volumes fundamentally changes the model. What App Volumes enables:

Real-time app attachment at app launch
Separation of apps from the golden image
Instant updates without recomposing desktops
Minimal golden image footprint (often 1–2 images)

This is architectural simplification, not just operational improvement. Nerdio can optimise image management. It cannot replace true application lifecycle.

2. User profiles: DEM vs profile containers

User state is one of the hardest problems in EUC, and one of the most visible when it goes wrong. Typical AVD approaches include:

FSLogix profile containers
Policies and scripting
Intune-based configuration

These provide persistence, but limited control. With Horizon Cloud, Dynamic Environment Manager (DEM) delivers:

Policy-driven user environment management
Context-aware configuration (device, location, role)
Granular application settings
Fast, consistent logon/logoff experiences

FSLogix stores profiles, DEM controls the user experience.

3. User experience: Performance + Access, not one or the other

User experience isn’t just about performance, it’s about how users connect, authenticate, and interact with their digital workspace. It’s defined by two equally important factors:

How users access their applications
How those applications perform once connected

Most platforms focus on one. A mature EUC platform delivers both. This is where Omnissa Horizon Cloud differentiates itself.

3.1 The access layer: A true digital front door

Before performance even matters, users need a simple, consistent way to access their workspace. In AVD environments, access is typically spread across:

Remote Desktop clients
Web portals
Multiple authentication entry points
Azure-native conditional access layers

While functional, this often leads to fragmented access experiences, multiple user journeys and increased login friction. With Horizon Cloud, Omnissa Access provides a unified digital front door, delivering:

A single portal for all apps and desktops
Consistent experience across browser, mobile, and desktop
Integrated authentication (including MFA and conditional access)
Unified access to SaaS, web, and virtual applications

This provides a unique user experience, offering one place to go for everything, fewer prompts and context switches and a consistent experience regardless of device, location and whether workloads are running in the cloud or on-prem.

Users don’t need to know where their apps live. They just know where to go.

3.2 The performance layer: Blast Extreme

Once connected, performance becomes the defining factor of user experience. AVD relies primarily on Remote Desktop Protocol (RDP). While it has improved, it still presents limitations:

Less adaptability in variable network conditions
Limited optimisation for multimedia and graphics workloads
Reduced control over protocol behaviour

Horizon Cloud introduces Blast Extreme, a purpose-built display protocol designed for modern workloads. Key advantages:

Adaptive transport (intelligent UDP/TCP switching)
Strong performance in high-latency or low-bandwidth conditions
Optimised for video, audio, and GPU-intensive workloads
Fine-grained tuning for bandwidth, quality, and responsiveness

3.3 Bringing it together: End-to-End user experience

Most solutions treat access and performance as separate concerns. Horizon Cloud integrates both into a single experience:

Omnissa Access → how users connect
Blast Extreme → how applications perform

By combining a digital front door with a high-performance protocol, Horizon Cloud helps:

Simplify how users connect
Optimise how applications perform
Deliver a consistent experience across any environment

The result is not just a working session. It’s a consistent, low-friction digital workspace experience.

4. Integrated stack vs layered tooling

With AVD + Nerdio, you are combining multiple layers:

Azure
AVD
Nerdio
FSLogix
Additional third party tooling for apps and policies

Each solves part of the problem. None own the full experience. With Horizon Cloud, everything is built-in:

App lifecycle (App Volumes)
User environment (DEM)
Protocol (Blast)
Brokering and access control
Image lifecycle

One platform. One control plane. One operational model.

5. Lab & training use cases: Where it all comes together

Azure Lab Services worked because it delivered:

Repeatability
Isolation
Simplicity

Recreating this with AVD requires:

Careful architecture
Multiple tools
Ongoing operational effort

Horizon Cloud enables:

Rapid provisioning from clean images
Stateless or semi-persistent desktops
Consistent environments across sessions
Simple reset and rebuild cycles

Much closer to the original Lab Services experience, without sacrificing enterprise capability.

6. Future-proofing your EUC strategy: Hybrid by design, not by exception

One of the most overlooked questions is: What happens when your requirements move beyond Azure? Because they will. AVD is inherently Azure-centric. If requirements evolve, whether due to data sovereignty, mergers, or edge use cases, organisations are often forced into redesign rather than extension.

For example, a University may run training labs in Azure today, but require on-prem deployment for research environments with sensitive data tomorrow.

6.1. Horizon Cloud: Built for hybrid from day one

Omnissa Horizon Cloud takes a different approach. It is inherently hybrid, allowing you to:

Deploy in Azure today
Extend to on-premises tomorrow
Expand into other cloud providers
Maintain consistency across all environments

This approach enables true flexibility, allowing workloads to run where they make the most sense, whether in Azure, on-premises, or across multiple clouds, while maintaining a consistent architecture and reducing dependency on a single provider.

6.2 The bottom line

Microsoft’s recommendation of AVD + Nerdio is logical from an ecosystem perspective. But it optimises for Azure alignment, not necessarily best-in-class EUC capability.

AVD + Nerdio:

Assembles a solution
Relies on multiple layers
Lacks depth in key EUC functions

Omnissa Horizon Cloud delivers those capabilities natively, within a single platform.

7. Final thought

Azure Lab Services didn’t just provide infrastructure. It delivered:

Simplicity
Control
Repeatability

Rebuilding that with AVD + Nerdio is possible, but it comes at the cost of:

Complexity
Fragmentation
Operational overhead

This is a moment to do more than replace. It’s a moment to rethink. Because the real decision isn’t “What replaces Azure Lab Services?” It’s “What EUC platform do we want to standardise on for the next 5 years?”

If you optimise for short-term alignment, AVD + Nerdio will get you there.

If you optimise for capability, consistency, and future flexibility, Horizon Cloud isn’t just an alternative. It’s the stronger long-term strategy.

So in short, if AVD + Nerdio is a solution you assemble, Horizon Cloud is a platform you standardise on.

Enhance your Google Chrome security with Chrome Enterprise

Thu, 15 Jan 2026 00:00:00 +0000

Today, the majority of enterprise applications are accessed through a web browser rather than a thick client. As a result, the browser has effectively become the new endpoint, making browser security more critical than ever.

In parallel, we’ve seen a growing adoption of Enterprise Browsers, driven by the need for improved visibility, control, and data protection, especially in hybrid and BYOD environments.

In this article, I’ll walk through how to configure Google Chrome Enterprise, the most widely used browser globally, to provide enterprise-grade security and management. Importantly, this approach works regardless of whether the device itself is corporate managed or personally owned.

The good news is that you don’t need to be a full Google Workspace customer to get started. Chrome Enterprise Core is completely free and provides strong foundational controls. For organisations requiring advanced security features such as malware scanning, Data Loss Prevention (DLP), and real-time URL protection, Chrome Enterprise Premium is available as an upgrade.

You can compare Chrome Enterprise Core and Premium features on Google’s official comparison page: https://chromeenterprise.google/intl/en_au/products/chrome-enterprise-premium/

1. Google Admin Console

1.1 Registration

If your organisation already uses Google services, access to the Google Admin Console likely already exists. In that case, contact your Google Workspace Super Admin to request access.

If your organisation is new to Google services, you’ll need to create a new Google Admin account.
It’s strongly recommended to use a shared mailbox or alias (ie. google.admin@yourdomain.com) rather than an individual account.

To register, visit the Chrome Enterprise sign-up page: https://enterprise.google.com/signup/chromeos/email?origin=ceutrial

1.2 Domain verification

Domain verification ensures no one else can register services using your organisation’s domain.

Login to your Google Admin Console
Go to Account > Domains > Manage Domains
Click Verify domain
- Copy the TXT record provided
Open a new browser tab and login to your domain registrar
- Add a new TXT record with the value copied earlier
Go back to your Google Admin Console tab and click Confirm

1.3 Licenses

To unlock Chrome Enterprise features:

Go to Billing > Subscriptions
Select Buy or upgrade

At a minimum, add:

Chrome Enterprise Core (Free)
Cloud Identity Free

For advanced security capabilities, add:

Chrome Enterprise Upgrade (Paid)

Some vendors bundle Chrome Enterprise Premium into their offerings. For example, Omnissa Secure Access Suite includes Chrome Enterprise Premium as part of the solution, so reach out to your Omnissa representative if you prefer to procure it that way. Buying the Omnissa Secure Access Suite instead of Chrome Enterprise Premium alone delivers secure browser access as part of a full, identity-driven Digital Workspace, including Hub Experience & Unified AppCatalog, modern VPN via Workspace ONE Tunnel, conditional access through Omnissa Access, and robust BYOD support. It also lays the foundation for an Autonomous Workspace journey, unifying security, access, and user experience under a single intelligent platform.

1.4 Services review

Before synchronising users, assess and restrict Google services to align with your security and governance requirements.

Navigate to:

Apps > Google Workspace > Service status, and
Apps > Additional Google services

Disable unnecessary services to reduce exposure and complexity.

2. User synchronisation

Google Workspace supports several ways to synchronise users, and the right approach depends on your identity provider. In this case, I’ll use SCIM provisioning from Entra ID to Google Workspace via the native integration in the Google Admin Console.

Note: At the time of writing, this integration is in beta. Alternatively, you can use the Google Cloud / G Suite Connector by Microsoft app from the Entra ID app gallery.

2.1 SCIM configuration

Login to your Google Admin Console
Go to Directory > Directory sync
Click Add Azure Active Directory
Give it a name then click Authorise and Save
You will get redirected to Entra ID for authentication
- Note that you will require to authenticate with a Global Admin account in order to authorise the integration
Accept the Google Directory Sync app creation in Entra ID

SCIM Add	SCIM Authorise

2.2 User sync

Under the User sync section, click Set up user sync
- User Scope
  - Use a user based Entra ID security group
    - Nested groups do not seem to work in this scenario
  - Copy the name of your Entra ID group and paste it into the field
  - Click Verify
- Organizational unit (OU) selection
  - Select Place users in a specific OU
  - Click on Select organizational unit
  - Then select the top level OU of your domain
- User attribute mapping
  - Map the user attributes as per your requirements
    - Common user attribute mappings
- Account activation
  - Select Don’t send activation email
- Deprovisioning
  - Click Suspend user in Google Directory
- Safeguards
  - Set the safeguard as per your requirements

User scope	OU	User attributes

User activation	User decommission	User safeguard

2.3 Group sync

Under the Group sync section, click Set up group sync
- Synchronising groups will allow you to assign different Chrome policies based on user groups (ie. Executives vs Staff)
- Group scope
  - Select Sync selected groups
  - Copy the name of your Entra ID group and paste it into the field
  - Click Verify
  - Note that for a group to sync, the group must be a mail-enabled security group (see required group attributes below)
- Required attributes
  - Leave the default values
- Deprovisioning
  - Click Delete group in your Google Directory
- Safeguards
  - Set the safeguard as per your requirements

Group scope	Group attributes	Group decommission	Group safeguard

3. Single Sign-On (SSO) and federation

Now that Google accounts are in place, the next consideration is user authentication. Fortunately, Google Workspace supports federation with most Identity Providers (IdP) using SAML or OIDC, allowing users to sign in using SSO rather than remembering another password. If you’re using Microsoft Entra ID as your primary IdP, this is even easier, as Google Workspace is natively federated with Entra ID via the pre-built OIDC profile.

If using another IdP:

Navigate to Security > Authentication > SSO with third-party IdP
Create an SSO profile
Assign it to an OU or user group

4. Google Chrome configuration

4.1 Chrome Enterprise Core

Now let’s look at the foundation of your Chrome configuration.

4.1.1 Reporting

Go to Chrome browsers > Settings
Select your top OU
Under the User & browser settings tab search for report
Configure the following reporting policies:
- Managed browser reporting: Enable managed browser cloud reporting
- Event reporting: Enable event reporting
- Managed profile reporting: Enable managed profile reporting for managed users
- Managed browser reporting upload frequency: 4 hours
- Device token management: Delete token

4.1.2 Safe browsing

Under the User & browser settings tab search for safe browsing
Configure the following Safe Browsing policies:
- Safe Browsing protection: Set the “Safe Browsing Protection Level” configuration to enhanced mode
- Disable bypassing Safe Browsing warnings: Do not allow users to bypass Safe Browsing warning
- Allow download deep scanning for Safe Browsing-enabled users: Enable Safe Browsing download deep scans
- Download restrictions: Block malicious downloads

4.1.3 Third party device trust connector (optional)

If your Identity Provider (IdP) supports device trust signals, integrating Google Chrome Enterprise enables context-aware access decisions based on browser trust. Chrome provides device signals such as managed browser status and disk encryption posture, allowing your IdP to enforce conditional access policies accordingly.

Note: The Chrome Enterprise Device Trust integration enables security posture verification for ChromeOS, Windows, and macOS devices.

In this example, I’ll walk through the integration using Omnissa Access as the IdP. Google Chrome Enterprise also supports integrations with other identity providers that offer device trust capabilities.

Login to your Omnissa Access tenant
Go to Integrations > Authentication Methods
Click on Google Chrome Enterprise Device Signals adapter
Enable the authentication method
Copy the URLs matcher & IDP service account
- You will need those details later on in the Google Admin console
Configure the device signals as per your requirements

Note: Device signals that can be collected via Managed browser or Managed profile include:

Disk Encryption: This signal checks whether the device's hard drive or SSD is encrypted. Only devices with an active main disk encryption will be granted access.
Firewall Status: This signal checks whether the device firewall is enabled. Devices will not be granted access if their firewall is in a disabled state.
Screen Lock Secured: This signal checks whether the device's screen lock is secured. Only devices with an enabled screen lock will be granted access.

Auth Methods	Chrome adapter

Configure the device trust connector in the Google Admin console:

Login to your Google Admin Console
Go to Chrome browser > Connectors
Click + New provider configuration
Find your IdP, then click Set up
Paste the URLs matcher and service account details copied from Omnissa Access
Click Add configuration
Assign the connector configuration to the appropriate OU

Connector	Config	Assign

Configure your conditional access policy:

Login to your Omnissa Access tenant
Go to Resources > Policies
Create a new policy or edit an existing one
Configure the policy based on your access requirements
- Device type: Windows 10+ or macOS or Chrome OS
- Add Google Chrome Enterprise Device Signals as a second authentication method

With this configuration in place, Chrome will continuously send device trust signals to Omnissa Access during authentication. These signals can then be evaluated in real time to enforce access controls.

For example, you could:

Allow access to your CRM or SaaS applications only from managed Chrome browsers (managed browser & managed profile)
Block access from unmanaged browsers, even if the user credentials are valid
Combine browser trust with other signals such as user, network, or risk level

4.2 Chrome extensions

Managing browser extensions effectively is essential to maintaining a secure browser environment, as extensions can introduce significant security and data exposure risks if left unmanaged.

Go to Chrome browsers > Apps & extensions
Under the Users & browsers tab
Select the appropriate OU or Group for assignment
Add and configure the Chrome extensions as per your requirements, for example:
- Endpoint Verification extension
  - Click the “+” icon and select Add Chrome app or extension by ID
  - Extension ID: callobklhcbilhphinckomhgkigmfocg
  - Installation policy: Force install + pin to browser toolbar
- Secure Enterprise Browser extension:
  - Click the “+” icon and select Add Chrome app or extension by ID
  - Extension ID: ekajlcmdfcigmdbphhifahdfjbkciflj
  - Installation policy: Force install + pin to browser toolbar

Once you have visibility into which extensions are being used across your environment, you can make an informed decision on how to manage them moving forward—typically by enforcing either an allowlist or blocklist using the settings below.

Go to Chrome browsers > Apps & extensions
Under the Settings tab
Select the appropriate OU or Group for assignment
Click on the Allow/block mode policy
- Play store: Block all apps, admin manages allowlist
- Chrome Web Store: Block all apps, admin manages allowlist, users may request extensions

4.3 Chrome Enterprise Premium

Chrome Enterprise Premium provides a wide range of advanced configuration capabilities. In this section, I’ll focus on establishing a small set of foundational policies, but you’re encouraged to explore the 500+ additional policies available to further tailor the solution to your requirements.

Go to Chrome browsers > Settings
Select the appropriate OU or Group for assignment
Under the User & browser settings tab search for connector
Configure content connector and URL check policies:
- Upload content analysis: Chrome Enterprise Premium
- Additional settings
  - Delay file upload: Delay the transfer until the analysis is complete
    - Block file transfer on failure: Enabled
  - Check for sensitive data: On by default, except for the following locations
    - User justifications to bypass: Enable
  - Check for malware: On by default, except for the following locations
    - User justifications to bypass: Disable
  - Password protected files: Allow
  - Files larger than 50MB: Allow

Repeat the above process for the following connector policies:

Download content analysis
Bulk text content analysis
- Minimum character count: 30
Print content analysis
Real time URL check

Enable advanced data protection features:

Go to Security > Access and data control > Data protection
Under the Data protection settings section
- Data insights scanning and report: On

5. Deployment models

Chrome supports two management modes:

Managed browser	Managed profile
Device-level management	User-based management
Ideal for corporate managed devices	Ideal for unmanaged devices and contractors
Policies apply even without user sign-in	Activated when the user signs in to Chrome

More information: https://support.google.com/chrome/a/answer/15591684

5.1 Managed browser

5.1.1 Enrolment token

To configure the managed browser option, you need to download the configuration file from your Google Admin Console.

Go to Chrome browsers > Managed browsers
Select the devices OU
Click Enroll
Copy and/or download your token

5.1.2 Windows deployment

Deploy the enrolment token using your PCLM/UEM solution. In this instance I am leveraging Workspace ONE to deploy the configuration file.

Login to your Workspace ONE console
Go to Resources > Profiles
Click ADD then Add Profile
Select Windows then Device Profile

Select the Custom Settings payload

Target: Workspace ONE Intelligent Hub

Install Settings:

  <wap-provisioningdoc id="1164DF07-F217-449B-95F8-FB85A34D3CA5" name="customprofile">/
  <characteristic type="com.airwatch.winrt.registryoperation" uuid="4fa91319-eac0-4a16-9d10-093ba845b698">
   <parm RegistryPath="HKLM\SOFTWARE\Policies\Google\Chrome" Action="Replace">
     <Value Name="CloudManagementEnrollmentToken" Data="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" Type="String" />
     <Value Name="CloudManagementEnrollmentMandatory" Data="1" Type="DWORD" />
   </parm>
  </characteristic>
  </wap-provisioningdoc>

Remove Settings:

  <wap-provisioningdoc id="1164DF07-F217-449B-95F8-FB85A34D3CA6" name="customprofile">/
  <characteristic type="com.airwatch.winrt.registryoperation" uuid="4fa91319-eac0-4a16-9d10-093ba845b698">
   <parm RegistryPath="HKLM\SOFTWARE\Policies\Google\Chrome" Action="Remove">
     <Value Name="CloudManagementEnrollmentToken" Data="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" Type="String" />
     <Value Name="CloudManagementEnrollmentMandatory" Data="1" Type="DWORD"/>
   </parm>
  </characteristic>
  </wap-provisioningdoc>

Save and Publish
Custom settings details are documented here

5.2 Managed profile

No additional configuration is required for Chrome managed profiles, as management is automatically enabled when users create a Chrome profile and sign in with their managed Google account. Users simply need to:

Create a Chrome profile
Sign in with their managed Google account

5.3 Confirm enrolment

On your test device, restart the Chrome browser to trigger synchronisation. You can confirm successful enrolment in the Google Admin Console under Chrome browsers > Managed browsers and/or Chrome browsers > Managed profiles. To verify that policies are applied on the device, open a new Chrome tab and navigate to chrome://policy.

6. User experience

7. Additional resources

Chrome Enterprise training: https://edu.exceedlms.com/student/collection/1771555

Workspace ONE Launcher with CICO, MSAL & KAM

Wed, 19 Nov 2025 00:00:00 +0000

I was recently invited to present at a Samsung Expert training event to demonstrate how solutions from Omnissa seamlessly integrate with and enhance the capabilities of Samsung Knox. To support this presentation, I built a full demo environment showcasing how KME (Knox Mobile Enrollment), KSP (Knox Service Plugin), and KAM (Knox Authentication Manager) when combined with Workspace ONE create a powerful, end-to-end solution uniquely positioned to address frontline workforce needs.

This solution is made up of several key components, each playing a critical role in enabling secure, efficient, and scalable device operations. Once configured, workers can simply “check out” a device at the start of their shift by login in, automatically receive the apps, policies, and permissions assigned to their role. When the shift ends, “checking in” the device clears personal data and returns it to a clean, ready-for-the-next-user state. This reduces device sprawl, ensures consistent user experiences, and maintains strong data privacy.

The section below provides a high-level overview of the components making up the solutions, while the remainder of this blog will dive deeper into the configuration details.

Identity
- On-premises Active Directory (AD) synchronised to EntraID via cloud sync
- AirWatch Cloud Connector (ACC) deployed on-premises to synchronise users to Workspace ONE UEM
- Access Cloud Connected deployed on-premises to synchronise users to Omnissa Access
- Note that SCIM 2.0 can also be configured for cloud only deployment
Knox
- KME used to auto enrol devices to the designated Organisation Group (OG)
- KAM used to simplify login experience
  - Auto populate username/password
- KSP used to pre-configure settings
Workspace ONE
- Launcher used to create consistent experience and restrict access
- Shared device mode with CICO (Check-in/Check-out)
  - Clear data and cache on logoff
- Workspace ONE UEM integrated with EntraID for device compliance and MSAL
- Omnissa Access integrated with UEM and federated with EntraID
- Workspace ONE Assist for remote view/control
Mobile Threat Defense (not documented in this blog post)
- Activated within Hub automatically
- Phishing and Content protection enforced
  - Blocking website categories such as Gambling, Violence…
Horizon (not documented in this blog post)
- Horizon Cloud on Azure virtual desktops
  - Can be used for back office tasks
- Samsung DeX for simplified access to Windows 11 from a single device

1. Knox Mobile Enrollment (KME)

Knox Mobile Enrollment (KME) is a zero-touch provisioning service that streamlines the deployment of Samsung devices at scale. It allows IT teams to automatically enrol devices into Workspace ONE the moment they’re powered on, with minimal manual setup, staging, or user intervention required.

Workspace ONE supports a number of enrolment flags in addition to what KME offers, typically used to enhance and speed up the enrolment process.

To create your KME profile, login to the Samsung Knox Admin portal, in the KME blade, select Profiles and Create profile.

KME Profile	EMM info	DPC extra

Additional flags used in the KME profile:

{"groupid":"your-groupid","useUEMAuthentication":"true","un":"your-staging-username","pw":"your-staging-pwd"}

With this configuration, the Samsung device automatically enrols into the designated OG using a multi-user staging account, and it authenticates through the Workspace ONE UEM authentication flow rather than Omnissa Access.

2. Knox Service Plugin (KSP)

Knox Service Plugin (KSP) extends the capabilities of Samsung devices by exposing the full range of advanced management APIs available within the Samsung Knox framework. Delivered as a lightweight app, KSP allows Workspace ONE to configure and enforce deep device-level policies, such as hardware restrictions, security controls, app management, and kiosk behaviours, without requiring custom integrations or complex scripting.

To create your KSP config, login to your Workspace ONE UEM console, go to Resources > Native Apps > Public. Locate the KSP app (or import it via Google Managed Play if needed), Select it and click Assign.

Assignment: select-your-smart-group
Delivery: Auto
Restrictions - Managed Access: Enabled
Create an AppConfig
- Knox license: add-your-knox-license
- Device-wide policies
  - Enable device policy controls: Enable
  - Application management policies
    - Enable application management controls: Enable
    - Battery optimization allowlist: com.airwatch.androidagent, com.airwatch.lockdown.launcher, com.airwatch.tunnel, com.samsung.android.knox.kam
    - Force Stop Blocklist: com.samsung.android.knox.kam
    - Package name for auto-launch: com.samsung.android.knox.kam/com.samsung.android.knox.kam.ui.SplashScreenActivity
    - Clear Cache Block List: com.samsung.android.knox.kam, com.samsung.android.knox.kpu
    - Clear Data Block List: com.samsung.android.knox.kam, com.samsung.android.knox.kpu
    - Enable Permission controls: Enable
- Permission Controls
  - Permission Policy: ALL, Package: com.airwatch.lockdown.launcher/com.airwatch.lockdown.launcher
  - Permission Policy: ALL, Package: com.airwatch.androidagent/com.airwatch.androidagent
  - Permission Policy: ALL, Package: com.airwatch.tunnel/com.airwatch.tunnel
  - Permission Policy: ALL, Package: com.airwatch.contentlocker/com.airwatch.contentlocker
  - Permission Policy: ALL, Package: com.airwatch.rm.agent.cloud/com.airwatch.rm.agent.cloud

App Assign	Distribution	Restrictions

AppConfig	Device Policy	Permission controls

With this configuration in place, KSP ensures that KAM remains running at all times and that its app data is preserved during the check-in (log-off) process. It also prevents essential system applications from being put to sleep by Android’s battery optimisation features, maintaining a consistent and reliable user experience. Finally, it pre-configures required app permissions, reducing unnecessary notification prompts during device staging and speeding up the overall provisioning workflow.

3. Knox Authentication Manager (KAM)

Knox Authentication Manager (KAM) is a managed, Android autofill service for shared, fully managed Samsung devices. Knox Authentication Manager offers multi-user facial biometrics to speed-up shared device sign-ins, eliminates authentication friction by saving and automatically filling user credentials for any productivity app that requires manual sign-in, and securely syncs users’ profiles across shared devices.

To create your KAM config, login to your Workspace ONE UEM console, go to Resources > Native Apps > Public. Locate the KAM app (or import it via Google Managed Play if needed), Select it and click Assign.

Assignment: select-your-smart-group
Delivery: Auto
Restrictions - Managed Access: Enabled
Create an AppConfig
- Knox license: add-your-knox-license
- Customize KAM home screen
  - Title: add-your-company-name
  - Description: add-a-description
  - Show device Serial: Enable
  - Admin PIN: create-an-admin-pin
- Manage sign in controls
  - UEM being used: Omnissa Workspace ONE with launcher sign in screen
  - Main sign in method: PIN+Face
  - Notice description: Yes
  - PIN Length: select-your-pin-length
- Manage sync controls
  - Enable syncing: Enable
  - Sync Org ID: add-your-company-name
  - Sync devices by: Group ID
  - Sync Group ID: create-a-groupid
  - Sync Group Key: create-an-encryption-key
    - To create the encryption key, run the following command on your computer: openssl rand -base64 24
  - Sync send UDP port: 49158
  - Sync receive UDP port: 49159
  - Sync TCP port: 7788
- Manage KAM behavior
  - Leave un-configured

App Assign	Distribution	Restrictions

AppConfig	Configure	Sync controls

4. The Microsoft Authentication Library (MSAL)

The Microsoft Authentication Library (MSAL) is a modern authentication framework developed by Microsoft that enables apps to securely sign in users. By enabling Microsoft SSO for shared Android devices, your shift workers can seamlessly sign into mobile applications when they check-out (sign-in) a shared device. This feature enables single sign-on into:

Many first-party Microsoft apps, such as Microsoft Teams.
- A list of first-party Microsoft apps that support this mode of single sign-on can be found here.
Any other application that supports Microsoft’s shared device mode using the Microsoft Authentication Library (MSAL).

4.1 Configure Microsoft SSO

To configure Microsoft SSO, login to your Workspace ONE UEM console, go to Groups & Settings > All Settings > System > Enterprise Integration > Directory Services.

Azure AD Integration: Enabled
- Directory ID: add-your-entraid-tenantid
- Azure AD for Identity Services: Enabled
- ms-DS-ConsistencyGuid: ms-DS-ConsistencyGuid
- Mapping Attribute Data Type: Binary
- Automatically revoke user tokens when wiping devices: Enabled
- Android Shared Device Checkout: Enabled
- You will be redirected to Microsoft Entra. Log in with an administrator account for your Microsoft Entra tenant and authorise Workspace ONE UEM to obtain information about your directory users.
Confirm that Workspace ONE UEM MSAL SSO is listed in Entra ID Console > Enterprise Applications
Azure Active Directory
- Tenant Name: add-your-entraid-tenantname
- Use compliance data in Azure conditional access policies: Enabled
- Use compliance data in Azure conditional access policies for iOS, Android, and macOS: Enabled
- Perform a Sync

EntraID integration	Compliance integration

4.1.1 Additional steps for hybrid setup

The following steps are only required if your have synchronised your users from on-premises Active Directory to Workspace ONE UEM via AirWatch Cloud Connector (ie. Your are not using Omnissa Identiy Services).

Login to your Workspace ONE UEM console, go to Groups & Settings > All Settings > System > Enterprise Integration > Directory Services > Users tab. Under Advanced select Sync Attributes. This will pull the Immutable ID for users into Workspace ONE UEM.

Then login to Microsoft Entra admin center, go to Enterprise Applications and select Workspace ONE UEM MSAL SSO.

Open the Single sign-on menu
Select Edit next to Attributes & Claims
Select Add New Claim
- Name: on-premises-immutable-id
- Source: Attribute
- Source attribute: user.onpremisesimmutableid

Next, you’ll need to create a signing key to securely issue the custom claim (Immutable ID). This signing key is made up of three components, a public key file, a private key file, and the password used to decrypt that private key. To generate the certificate, download the PowerShell script provided by Omnissa called: Set Custom Signing Key - Microsoft SSO.

Run the below PowerShell script, and replace the placeholder attributes with your tenant details.

./setCustomSigningKey.ps1 -CertFriendlyName "create-cert-friendlyname" -Password "create-a-pwd" -TenantId "add-your-entraid-tenantid" -ApplicationObjectId "msal-app-object-id" -SelfSigned “Y”

Tip: The script provided seem to only works on Windows, so if you are using macOS or Linux, make sure to run this script from a Windows VM.

Once completed, the script will generate two certificate files (.cer and .pfx). Keep them in a safe place in case you need them in future. Note that the signing certifcate is only valid for 1 year, so you will need to renew it before its expiration .

4.2 Microsoft Authenticator

When configured in shared device mode, Microsoft Authenticator enables a secure and streamlined sign-in experience on devices used by multiple frontline workers. Instead of treating the device as personally owned, shared mode binds the authentication flow to a single, shift-based user session.

To create your MS Authenticator shared device mode config, login to your Workspace ONE UEM console, go to Resources > Native Apps > Public. Locate the MS Authenticator app (or import it via Google Managed Play if needed), Select it and click Assign.

Assignment: select-your-smart-group
Delivery: Auto
Restrictions - Managed Access: Enabled
Create an AppConfig
- Shared Device Mode: Enable
- Prefill UPN in Shared Device Mode: Leave this field blank
- Shared Device Mode Tenant Identifier: add-your-entraid-tenantid
- Shared Device Mode Registration token: {SharedDeviceRegistrationToken}
- Suppress camera consent for QR code: Enable

Tip: If you are using an Android Restrictions profile, ensure the setting Allow adding/deleting accounts is set to Enable.

4.3 Intelligent Hub settings

The last configuration item for the MSAL integration is to configure Intelligent Hub to support it.

Login to your Workspace ONE UEM console, go to Groups & Settings > All Settings > Devices & Users > Android > Intelligent Hub Settings.

Register as Shared Device with Azure for Conditional Access: Enabled
Global sign-in/sign-out using MSAL: Enabled

5. Workspace ONE UEM

5.1 Authentication settings

Workspace ONE UEM supports several authentication workflows. In this setup, I’ve configured Workspace ONE UEM to use Omnissa Access as the authentication source. This in turn allows for Workspace ONE Launcher to use SAML for authentication instead of Active Directory. Omnissa Access is then federated with EntraID, so any authentication for device enrolment or Intelligent Hub will leverage EntraID conditional access policies.

Also you need to make sure that your Google integration is set to:

Management Mode: Work Managed
Account Generation: Device-Based
Management Source: Custom DPC

EMM Registration	Enrollment

5.2 Multi-user staging account

Workspace ONE UEM supports several staging workflows. In this setup, I’ve configured a multi-user staging account so that each device only needs to be staged once. Thereafter, frontline workers simply sign in at the start of their shift and sign out when they finish. At logoff, user specific data is cleared and the device returns to its clean, staged state, ready for the next worker.

To configure a mutli-user staging account, login to your Workspace ONE UEM console, go to Accounts > Users and click Add User.

Complete the necessary fields
- This staging account could either be a Directory or Basic account
In the Advanced tab, expand the Staging section
- Enable Device Staging: Enabled
- Single User Devices: Disabled
- Multi User Devices: Enabled
- Android Shared Device Mode: Launcher

5.3 Shared device settings

Next you need to ensure that the shared device settings in Workspace ONE UEM are configured to align with your use case. In this setup I’ve configured the shared device settings as per below.

Grouping	Logout

5.4 Intelligent Hub SDK

If you want to enhance the user experience and remove the welcome and privacy sreens when signing into Hub or any Workspace ONE SDK enabled apps, I recommend using the below custom SDK settings.

Login to your Workspace ONE UEM console, go to Groups & Settings > All Settings > Apps > Settings and Policies > Settings

Custom Settings: Enabled
Paste the below json code

{
"PolicyAllowFeatureAnalytics": 0,
"DisplayPrivacyDialog": 0,
"PrivacyPolicyLink": "https://www.omnissa.com",
"mtdSettings":{"isEntitled":true},
"CaptureDEXData": true
}

Tip: Only use mtdSettings and CaptureDexData if you are licensed for those add-ons.

5.5 Workspace ONE Launcher

Now onto the last piece of the puzzle, configuring Workspace ONE Launcher to customise the device layout.

Workspace ONE Launcher is a customisable Android home screen to give organisations tighter control over corporate and frontline devices. By replacing the standard Android launcher, it allows IT teams to present only approved apps, apply kiosk settings, and lock down system settings to ensure a secure, task-focused environment. This creates a simpler experience for workers, reduces distractions, strengthens security, and ensures devices stay consistent and compliant. With flexible branding options Launcher is an ideal solution for retail, logistics, field services, and any scenario where devices need to stay focused, secure, and easy to use.

To create a Launcher profile, login to your Workspace ONE UEM console, go to Resources > Profiles & Baselines > Profiles, click Add and Add Profile.

Platform: Android
Management Type: Custom DPC
Profile Name: create-profile-name
Scroll down the list and ADD the Launcher payload
Configure the settings as per your use case requirements
- KAM requirements:
  - Enable App Data/Cache Clearing: Enable
  - Excluded Package Names
    - com.samsung.android.knox.kam
    - com.samsung.android.knox.kpu
  - Allowlist Activities on Check-in Check-out Screen: Enable
    - Provide the KAM Package Names and Class Name as per KAM documentation
  - Allowlist specific Android Activities: Enable
    - Provide the KAM Package Names and Class Name as per KAM documentation
Click on Configure Layout
- Customise the device layout as per your use case requirements

Launcher config 1	Launcher config 2	Launcher config 3	Launcher config 4

Launcher config 5	Launcher config 6	Launcher config 7	Launcher config 8

Launcher canvas	Launcher hidden apps	Launcher layout	Launcher for you

User experience

Bulk create EntraID users via PowerShell

Wed, 05 Nov 2025 00:00:00 +0000

Creating users in Microsoft Entra ID (formerly Azure AD) is a common task for tenant onboarding, lab builds, trials, or Proof of Concept (POC) engagements. When dealing with multiple users, automating the process can save significant time and ensure consistency. This PowerShell approach gives you flexibility to automate the user creation, licenses assignment and setup the prefered MFA method directly via Microsoft Graph.

This post walks through how to:

Create Entra ID users in bulk from a CSV file
Assign Microsoft licenses automatically
Configure user’s MFA method using either Mobile Phone or Temporary Access Pass (TAP)
Reset user passwords in bulk if required

Create a CSV file

Start by creating a CSV file that contains the users you want to create. This file will act as the input source for the scripts below. Save the file locally on your machine.

UserPrincipalName,FirstName,LastName,DisplayName,UsageLocation,Mail,MailNickname,Password,MobilePhone
Testuser1@beaugtech.com,Test,User 1,Test User 1,AU,Testuser1@beaugtech.com,Testuser1,Password123!,+61 123456789
Testuser2@beaugtech.com,Test,User 2,Test User 2,AU,Testuser2@beaugtech.com,Testuser2,Password123!,+61 123456789

Tip: Ensure each column header exactly matches the script variable names. For production use, avoid storing plaintext passwords in CSV files. Consider using Temporary Access Pass (TAP) or prompting users to set their own password.

Bulk create users with mobile phone MFA - Option 1

The following script:

Connects to Microsoft Graph
Creates users from the CSV
Assigns a Dev E5 license
Adds the mobile phone number as an MFA method

Connect-MgGraph -Scopes `
    "User.ReadWrite.All",
    "UserAuthenticationMethod.ReadWrite.All"

# Import CSV
$users = Import-Csv -Path "~/Downloads/EntraID-User-Create-Bulk.csv"

# Get Microsoft License SKU
$e5Sku = Get-MgSubscribedSku -All |
    Where-Object SkuPartNumber -eq 'DEVELOPERPACK_E5'

foreach ($user in $users) {

    # Password profile from CSV
    $passwordProfile = @{
        ForceChangePasswordNextSignIn = $false
        Password = $user.Password
    }

    try {
        # Create user
        $newUser = New-MgUser `
            -DisplayName $user.DisplayName `
            -GivenName $user.FirstName `
            -Surname $user.LastName `
            -UserPrincipalName $user.UserPrincipalName `
            -UsageLocation $user.UsageLocation `
            -Mail $user.Mail `
            -MailNickname $user.MailNickname `
            -MobilePhone $user.MobilePhone `
            -PasswordProfile $passwordProfile `
            -AccountEnabled:$true

        Write-Host "User created: $($user.UserPrincipalName)" -ForegroundColor Green

        # Assign license
        Set-MgUserLicense `
            -UserId $newUser.Id `
            -AddLicenses @{ SkuId = $e5Sku.SkuId } `
            -RemoveLicenses @()

        # Give Entra time to finalize user provisioning
        Start-Sleep -Seconds 15

        # Add MFA mobile phone method
        if ($user.MobilePhone) {
            New-MgUserAuthenticationPhoneMethod `
                -UserId $newUser.Id `
                -PhoneNumber $user.MobilePhone `
                -PhoneType "Mobile"

            Write-Host "MFA mobile phone added: $($user.MobilePhone)" -ForegroundColor Yellow
        }
        else {
            Write-Host "No mobile phone provided - MFA skipped" -ForegroundColor DarkYellow
        }
    }
    catch {
        Write-Host "Failed for $($user.UserPrincipalName): $_" -ForegroundColor Red
    }
}

Bulk create users with Temporary Access Pass (TAP) - Option 2

If you prefer using Temporary Access Pass (TAP) instead of mobile phone MFA, the script below creates users and generates a TAP for each one. The TAP values are exported to a CSV file for secure distribution.

Connect-MgGraph -Scopes `
    "User.ReadWrite.All",
    "UserAuthenticationMethod.ReadWrite.All"

# Import users
$users = Import-Csv -Path "~/Downloads/EntraID-User-Create-Bulk.csv"

# Output file
$outputPath = "~/Downloads/EntraID-User-TAP-Export.csv"
$tapResults = @()

# Get Microsoft License SKU
$e5Sku = Get-MgSubscribedSku -All |
    Where-Object SkuPartNumber -eq 'DEVELOPERPACK_E5'

foreach ($user in $users) {

    $passwordProfile = @{
        ForceChangePasswordNextSignIn = $false
        Password = $user.Password
    }

    try {
        # Create user
        $newUser = New-MgUser `
            -DisplayName $user.DisplayName `
            -GivenName $user.FirstName `
            -Surname $user.LastName `
            -UserPrincipalName $user.UserPrincipalName `
            -UsageLocation $user.UsageLocation `
            -Mail $user.Mail `
            -MailNickname $user.MailNickname `
            -MobilePhone $user.MobilePhone `
            -PasswordProfile $passwordProfile `
            -AccountEnabled:$true

        # Assign license
        Set-MgUserLicense `
            -UserId $newUser.Id `
            -AddLicenses @{ SkuId = $e5Sku.SkuId } `
            -RemoveLicenses @()
        
        # Give Entra time to finalize user provisioning
        Start-Sleep -Seconds 15

        # Create Temporary Access Pass (TAP) for MFA
        $tap = New-MgUserAuthenticationTemporaryAccessPassMethod `
            -UserId $newUser.Id `
            -TemporaryAccessPass @{
                IsUsableOnce        = $false       # Allow reuse
                LifetimeInMinutes  = 480           # 8 hours expiry
            }

        # Capture results
        $tapResults += [PSCustomObject]@{
            UserPrincipalName = $user.UserPrincipalName
            TemporaryAccessPass = $tap.TemporaryAccessPass
            ExpiresInMinutes = 480
        }

        Write-Host "User created + TAP issued: $($user.UserPrincipalName)" -ForegroundColor Green
    }
    catch {
        Write-Host "Failed for $($user.UserPrincipalName): $_" -ForegroundColor Red
    }
}

# Export TAPs
$tapResults | Export-Csv -Path $outputPath -NoTypeInformation -Force

Write-Host "`nTAP export completed:" -ForegroundColor Cyan
Write-Host $outputPath -ForegroundColor Yellow

Bulk password reset

Occasionally, you may need to reset user passwords, the following script updates user passwords in bulk using the same CSV file.

# Connect to Microsoft Graph with required permissions
Connect-MgGraph -Scopes `
    "Directory.AccessAsUser.All",
    "User.ReadWrite.All"

# Import the CSV file (ensure it has a column for UserPrincipalName or Id)
$users = Import-Csv -Path "~/Downloads/EntraID-User-Create-Bulk.csv"

foreach ($user in $users) {
    # Set new password profile
    $PasswordProfile = @{
        ForceChangePasswordNextSignIn = $false
        Password = $user.Password
    }

    # Update the user's password
    Update-MgUser -UserId $user.UserPrincipalName -BodyParameter @{
        passwordProfile = $PasswordProfile
    }

    Write-Host "Updated password for user:" $user.UserPrincipalName
}

Migrating Omnissa DEM from AD mode to No-AD mode

Wed, 24 Sep 2025 00:00:00 +0000

Overview

Omnissa Dynamic Environment Manager (DEM) is a robust solution for managing user profiles and personalization across Windows virtual desktops and applications. It enables IT teams to deliver a consistent, tailored experience to users while maintaining centralized configuration control.

Traditionally, DEM has relied on Active Directory (AD) and Group Policy Objects (GPOs) for configuration delivery. With the rise of cloud-first and hybrid architectures, Omnissa introduced No-AD mode, removing the dependency on AD and simplifying deployment.

By following a staged migration plan, you can ensure minimal disruption and maintain full control over the user experience.

Key steps include:

Preparing a valid NoAD.xml
Reinstalling FlexEngine with the correct MSI switches
Verifying policy application
Rolling out in batches/rings

AD vs. No-AD mode

AD mode

Uses Group Policy Objects (GPOs) for configuration
Requires Active Directory for targeting and policy delivery
Best suited for traditional on-premises environments

No-AD mode

Uses a NoAD.xml config file stored on the configuration share
No dependency on AD or GPOs
Ideal for cloud-based or hybrid deployments
Configuration is driven by FlexEngine using the NOADCONFIGFILEPATH MSI property

Why migrate to No-AD mode?

Migrating to No-AD mode offers several advantages:

Simplified management – No more GPO administration or AD filtering
Cloud readiness – Supports cloud-only and hybrid environments
Faster deployment – File-based configuration is easy to replicate, and logins are typically faster since GPO processing is reduced
Improved flexibility – Ideal for modern workspace use cases

Change considerations

What changes

FlexEngine configuration mechanism:
In No-AD mode, FlexEngine reads settings from a NoAD.xml file instead of GPOs.
Installation method:
FlexEngine must be installed using the NOADCONFIGFILEPATH MSI property.

What doesn’t change

Your existing configuration remains fully compatible:

Configuration share
Profile archive share
Personalization settings
User Environment settings
Predefined/Default settings

Co-existence

FlexEngine in No-AD mode ignores DEM GPO settings, enabling staged rollout by pool or OU.
You do not need to remove GPOs immediately.

Migration steps

1. Create a `NoAD.xml` configuration file

Use the sample provided by Omnissa to create your NoAD.xml file and place it on your DEM configuration share.

2. Enable No-AD mode on client machines

Reinstall the DEM agent in No-AD mode on your gold image or test ring devices:

msiexec /i "Omnissa Dynamic Environment Manager x64.msi" /qn /l*v %TEMP%\DEM-NoAD.log NOADCONFIGFILEPATH=\\FileSrv\DEMConfig$\General

This enables No-AD mode.
FlexEngine will now read NoAD.xml from the specified path.

3. Verify policy application

Confirm Personalization and User Environment settings apply correctly
Validate behavior across different user scenarios

4. Roll out in batches or rings

Reinstall FlexEngine with the NOADCONFIGFILEPATH property on all target devices
Since No-AD clients ignore DEM GPOs, GPOs may remain during migration
Once all clients are migrated, unlink or disable DEM GPOs

5. Rollback (If needed)

If rollback is required:

Uninstall FlexEngine
Reinstall without the NOADCONFIGFILEPATH property
Re-enable DEM GPOs

Since configuration and profile archives are unchanged, rollback is quick and low-risk.

Final Thoughts

Migrating DEM from AD to No-AD mode is a strategic step for organizations moving toward cloud-first or hybrid models. It simplifies configuration management, reduces dependency on legacy infrastructure, and aligns with modern IT operations.

Before full deployment, ensure thorough testing in a staging environment and validate all Personalization and User Environment configurations.

Uninstall Windows applications silently with PowerShell

Tue, 24 Jun 2025 00:00:00 +0000

When deploying Windows devices using Autopilot, unwanted Win32 or AppX apps can clutter user experience or cause security risk. Below is a PowerShell script you can run in SYSTEM context to silently uninstall these apps as part of the Out-of-Box Experience (OOBE).

This PowerShell script:

Runs silently in the background without user interaction
Handles Win32 (MSI / EXE) and AppX applications
Supports exact or partial application name matching

Gathering the application list

Before uninstalling anything, you need to know what’s installed. The following sections show how to list traditional desktop apps (Win32/MSI/EXE) from the registry and modern UWP/AppX packages using PowerShell. If you already know which applications you want to remove, you can skip this section. Otherwise, use the scripts below to identify installed applications on a Windows device.

List installed Win32 applications

Run the following script to list all Win32 (MSI / EXE) applications installed on the device.

$RegistryPaths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

foreach ($Path in $RegistryPaths) {
    Get-ItemProperty -Path $Path -ErrorAction SilentlyContinue |
    Where-Object {
        $_.DisplayName -and
        $_.UninstallString
    } |
    Select-Object `
        DisplayName,
        DisplayVersion,
        UninstallString
}

Make a note of the applications you want to remove. These names (exact or partial) will be used in the uninstall script later.

List installed AppX applications

To list all removable AppX applications installed for all users on a Windows device, run:

Get-AppxPackage -AllUsers |
Where-Object { $_.NonRemovable -eq $false } |
Select-Object Name, Version, PackageFullName

Make a note of the applications you want to remove. These names (exact or partial) will be used in the uninstall script later.

Uninstall script

The script below takes an array of application display names (exact or wildcard) and:

Discovers matching Win32 apps from the registry
Discovers matching AppX packages for all users
Executes silent uninstall or removal actions accordingly
Safely exits if no matching applications are found

Tip: The script must be run in SYSTEM context

# Define an array of app names (exact or partial match). For partial match use '*' symbol.
$DisplayNames = @(
    "AppName1",
    "AppName2*",
    "*AppName3*"
)

# Registry paths for Win32 apps
$RegistryPaths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

# Collections
$FoundApps    = @()
$FoundAppx    = @()
$SeenMSIs     = @()
$MatchedNames = @()

# Discover Win32 apps
foreach ($Name in $DisplayNames) {
    foreach ($Path in $RegistryPaths) {

        Get-ItemProperty -Path $Path -ErrorAction SilentlyContinue |
        Where-Object { $_.DisplayName -like $Name } |
        ForEach-Object {
            if ($_.UninstallString -match "\{[A-F0-9\-]{36}\}") {
                $ProductCode = $matches[0]
                if ($SeenMSIs -notcontains $ProductCode) {
                    $SeenMSIs += $ProductCode
                    $FoundApps += [PSCustomObject]@{
                        DisplayName = $_.DisplayName
                        Type        = "MSI"
                        ProductCode = $ProductCode
                        Command     = $null
                    }
                }
                $MatchedNames += $Name
                return
            }

            if ($_.QuietUninstallString) {
                $FoundApps += [PSCustomObject]@{
                    DisplayName = $_.DisplayName
                    Type        = "EXE"
                    ProductCode = $null
                    Command     = $_.QuietUninstallString
                }
                $MatchedNames += $Name
                return
            }

            if ($_.UninstallString) {
                $FoundApps += [PSCustomObject]@{
                    DisplayName = $_.DisplayName
                    Type        = "EXE"
                    ProductCode = $null
                    Command     = "$($_.UninstallString) /S /norestart"
                }
                $MatchedNames += $Name
            }
        }
    }
}

# Discover AppX apps
foreach ($Name in $DisplayNames) {
    Get-AppxPackage -AllUsers |
    Where-Object { $_.Name -like $Name -or $_.PackageFullName -like $Name } |
    ForEach-Object {
        $FoundAppx += [PSCustomObject]@{
            DisplayName = $_.Name
            PackageName = $_.PackageFullName
        }
        $MatchedNames += $Name
    }
}

# Log missing apps
$MatchedNames = $MatchedNames | Select-Object -Unique
$MissingApps  = $DisplayNames | Where-Object { $_ -notin $MatchedNames }

foreach ($App in $MissingApps) {
    Write-Host "Application not found: $App" -ForegroundColor Yellow
}

# Exit if nothing found
if ($FoundApps.Count -eq 0 -and $FoundAppx.Count -eq 0) {
    Write-Host "No applications to uninstall." -ForegroundColor DarkYellow
    exit 0
}

# Uninstall Win32 apps silently
foreach ($App in $FoundApps) {
    Write-Host "Uninstalling Win32 app: $($App.DisplayName)"
    if ($App.Type -eq "MSI") {
        Start-Process -FilePath "msiexec.exe" `
            -ArgumentList "/x $($App.ProductCode) /qn /norestart" `
            -Wait -WindowStyle Hidden
    } else {
        Start-Process -FilePath "cmd.exe" `
            -ArgumentList "/c `"$($App.Command)`"" `
            -Wait -WindowStyle Hidden
    }
}

# Uninstall AppX apps
foreach ($Appx in $FoundAppx) {
    Write-Host "Removing AppX package: $($Appx.DisplayName)"
    try {
        Remove-AppxPackage -Package $Appx.PackageName -AllUsers -ErrorAction Stop
    } catch {
        Write-Host "Failed to remove AppX package: $($Appx.DisplayName)" -ForegroundColor Red
    }
}

exit 0

List biometric devices on Windows via PowerShell

Thu, 13 Feb 2025 00:00:00 +0000

Run: System context

$biometricDevices = Get-CimInstance -ClassName Win32_PnPEntity | Where-Object { $_.PNPClass -eq 'Biometric' -and $_.Present }

$devicesArray = New-Object System.Collections.ArrayList

if ($biometricDevices) {
    foreach ($device in $biometricDevices) {
        [void]$devicesArray.Add($device.Description)
    }
    $output = $devicesArray -join ","
    Write-Output $output
} else {
    Write-Output "No biometric devices"
}

Disable Microsoft Office macros

Sun, 24 Nov 2024 00:00:00 +0000

Have you been asked to disable Office macros for all or most users to reduce your threat attack surface?

I have built Workspace ONE UEM scripts to achieve this and thought I would share the details here.

Windows configuration

Script

In Workspace ONE UEM console, create a script and paste the below code into the code field.

Name: Disable VBA for Office
Run: System context

# Disabling VBA for all office apps
# Define VBA variables
$keyPath1 = "HKLM\SOFTWARE\Policies\Microsoft\Office\16.0\Common"
$valueName1 = "vbaoff"
$valueData1 = 1

# Check if the registry key exists
if (Test-Path "Registry::$keyPath1") {
    Set-ItemProperty -Path "Registry::$keyPath1" -Name $valueName1 -Value $valueData1
    Write-Host "Registry key '$valueName1' has been set to '$valueData1'."
} else {
# Create the registry key if it doesn't exist
    New-Item -Path "Registry::$keyPath1" -Force | Out-Null
    Set-ItemProperty -Path "Registry::$keyPath1" -Name $valueName1 -Value $valueData1
    Write-Host "Registry key '$valueName1' has been created and set to '$valueData1'."
}

To enhence user experience, you might also want to disable the notification that could appear in Office.

In Workspace ONE UEM console, create a script and paste the below code into the code field.

Name: Disable VBA notifications for Office
Run: User context with admin right

# Define the registry key path for each Office application
$officeApplications = @{
    "Excel" = "HKCU\Software\Policies\Microsoft\Office\16.0\Excel\Security"
    "Word" = "HKCU\Software\Policies\Microsoft\Office\16.0\Word\Security"
    "PowerPoint" = "HKCU\Software\Policies\Microsoft\Office\16.0\PowerPoint\Security"
    "Access" = "HKCU\Software\Policies\Microsoft\Office\16.0\Access\Security"
    "Outlook" = "HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Security"
    "Publisher" = "HKCU\Software\Policies\Microsoft\Office\16.0\Publisher\Security"
    "Visio" = "HKCU\Software\Policies\Microsoft\Office\16.0\Visio\Security"
}

# Define the registry value name and data
# 1=Enable VBA macros, 2=Disable VBA macros with notification, 3=Disable VBA macros except digitally signed, 4=Disable VBA macros without notification
$valueName = "VBAWarnings"
$valueData = 4

# Loop through each Office application and set the registry value
foreach ($app in $officeApplications.GetEnumerator()) {
    $keyPath = $app.Value
    $appName = $app.Key

# Check if the registry key exists
    if (Test-Path "Registry::$keyPath") {
        Set-ItemProperty -Path "Registry::$keyPath" -Name $valueName -Value $valueData
    } else {
# Create the registry key if it doesn't exist
        New-Item -Path "Registry::$keyPath" -Force | Out-Null
        Set-ItemProperty -Path "Registry::$keyPath" -Name $valueName -Value $valueData
    }

    Write-Host "Disabled macros notifications for $appName."
}

Reporting

Report on Microsoft Office VBA macros status on Windows via a PowerShell script.

In Workspace ONE UEM console, create a sensor and paste the below code into the code field.

Name: win_office_vbamacros_status
Run: System context

# This script checks the status of the vbaoff setting on Windows
# Define the registry key variables
$keyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Office\16.0\Common"
$valueName = "vbaoff"

# Check if the registry key path exists
if (Test-Path $keyPath) {
# Get the value of the registry value
$value = Get-ItemProperty -Path $keyPath -Name $valueName -ErrorAction SilentlyContinue
# Check if the value is not null (i.e., the value exists)
if ($value -ne $null) {
# Check if the value is set to 1
    if ($value.$valueName -eq 1) { Write-Output "Disabled" }
    else { Write-Output "Enabled" }
}
else { Write-Output "Not set" }
}
else { Write-Output "Not set" }

macOS configuration

Profile

In Workspace ONE UEM console, create a custom profile and paste the below code into the custom settings field.

Configuration reference: https://learn.microsoft.com/en-us/deployoffice/mac/set-preference-macro-security-office-for-mac

<dict>
	<key>PayloadDisplayName</key>
	<string>Microsoft Office settings</string>
	<key>PayloadIdentifier</key>
	<string>com.microsoft.office.4164F689-9190-4094-A869-CE04C288947B</string>
	<key>PayloadType</key>
	<string>com.microsoft.office</string>
	<key>PayloadUUID</key>
	<string>4164F689-9190-4094-A869-CE04C288947B</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
	<key>VisualBasicEntirelyDisabled</key>
	<true/>
	<key>VisualBasicMacroExecutionState</key>
	<string>DisabledWithoutWarnings</string>
</dict>

Reporting

Report on Microsoft Office VBA macros status on macOS via a Bash script.

In Workspace ONE UEM console, create a sensor and paste the below code into the code field.

Name: macos_office_vbamacros_status
Language: Bash
Response: String

current_user=$(ls -l /dev/console | awk '{print $3}')
vba_disabled_value=$(sudo -u $current_user defaults read "/Library/Managed Preferences/com.microsoft.office.plist" | grep "VisualBasicEntirelyDisabled" | awk '{sub(/;/, ""); print $3}')

if [ -z "$vba_disabled_value" ]; then
    echo "Not set"
elif [ "$vba_disabled_value" -eq 1 ]; then
    echo "Disabled"
else
    echo "Enabled"
fi

Terraform scripts to build Azure prerequisites for HCoA

Wed, 06 Nov 2024 00:00:00 +0000

Scripts to build the required Azure infrastructure components to support a deployment of Horizon Cloud on Azure (HCoA) next-gen. It uses Terraform to create the Azure resources needed for the deployment of the Horizon Edge (AKS).

Tested with azuread 3.0.2 and azurerm 4.0.1 providers on macOS 14.7.

The Terraform workflow will do the following in Azure:

Create a single Resouce Group in your Azure subscription
Create a VNet in this Resource Group
Create three (3) Subnets in this VNet:
- Management Subnet
- DMZ Subnet
- Desktop Subnet
Create either a Route Table or NAT Gateway, based on the connectivity type selection in the variable file
- Route Table
  - Create a default route in the Route Table
  - Assign the default route to the Management subnet
- NAT Gateway
  - Create a Public IP for a NAT Gateway
  - Create a NAT Gateway
  - Assign the NAT Gateway to the Management Subnet
Assign the DNS Server settings to the VNet
Create two (2) Custom Roles:
- Service Principal Role with minimum capabilities needed for the Service Principal used by Horizon Cloud
- Azure Compute Read-Only role with permissions on to Read on Azure Compute Resources
Create a User Managed Identity
Assign to the Managed Identity the Network Contributor & Managed Identity Operator built-in roles.
Create an Enterprise Application.
Create a Service Principal, Client ID and Client Secret for the Enterprise Application.

Before you begin

Ensure you have the following softwares installed on your computer:
- PowerShell
- AZ module (Install-Module -Name Az)
- Azure Command Line Tools
- Terraform
Ensure your Entra ID account has the Azure Owner role assigned on your Azure susbcription

Download the Terraform template

Terraform scripts and templates are located here.

Instructions:

1. Register the required Azure Service Providers via PowerShell for Horizon Cloud. List of providers are documented here.

Connect-AzAccount

$resource_providers_list = @(
    "Microsoft.Authorization",
    "Microsoft.Compute",
    "Microsoft.ContainerService",
    "Microsoft.KeyVault",
    "Microsoft.MarketplaceOrdering",
    "Microsoft.ResourceGraph",
    "Microsoft.Network",
    "Microsoft.Resources",
    "Microsoft.Security",
    "Microsoft.Storage",
    "Microsoft.ManagedIdentity"
)

$resource_providers_list | ForEach-Object {
    Write-Host "Registering Resource Provider: $_" -ForegroundColor Cyan
    Register-AzResourceProvider -ProviderNamespace $_ -ErrorAction Stop
}

2. Edit the terraform.tfvars file and adjust the variables to suit your environment.

3. Open your preferred terminal and browse to your Terraform deployment folder:

cd ~/Downloads/Terraform_HCoAdeploy

4. Log in to your Azure environment and select your Azure subscription where you want to deploy Horizon Cloud

az login
az account set --subscription "Your Azure Subscription Name"

5. On the very first run, you need to get the Terraform Providers.

terraform init

6. Test your config using

terraform validate

7. Now you will be able to deploy against your settings:

terraform plan -out HCoADeploy
terraform apply HCoADeploy

8. Copy and save the output details once the script finishes, you will need those details when deploying the Horizon Edge. In addition, run the below commands to reveal the sensitive values.

terraform output service_principal_pwd_id
terraform output service_principal_pwd_key

9. Implement the reminder of the pre-requisites for Horizon Cloud as per the documentation.

Changelog

2024-12-06: Ability to add additonal application owners to the service principal.
2024-11-25: Removed Azure Resource Providers registration from Terraform workflow. Resource Providers registration is now done via PowerShell instead to avoid (1)registration errors if already resgisterred and (2)retain registration during Terraform destroy.
2024-11-19: Added the option to select connectivity type for the management subnet (NAT vs Route).
2024-11-06: Initial release.

Omnissa POC templates

Mon, 01 Jul 2024 00:00:00 +0000

Over the years, I’ve helped customers deploy a wide range of EUC solutions, whether as paid projects, trials, or full Proof of Concept (POC). One of the most common challenges I see is getting started with the prerequisites. Vendor documentation is often extensive, scattered, and sometimes confusing, which can make the initial setup harder than it needs to be.

To streamline this process, I began developing my own templates and tools to help customers capture the required information, track their progress, and accelerate deployment. Over time these resources have proven valuable across many engagements, so I decided it was finally time to share them with the wider community.

Success criteria

Success criteria are often overlooked or left until later in a project, yet they are critical for defining what a successful trial or POC looks like. Many customers find it difficult to start from a blank page, so I created a template to make this easier and guide the discussion from day one.

Omnissa-success-criteria.xlsx

Logical diagrams

To help clients better understand how the Omnissa platform components interact, I created a set of simple, easy-to-consume logical diagrams. These diagrams provide a clear overview of the architecture and help support planning and stakeholder discussions.

UEM	Horizon	UEM + Horizon 8

UEM.drawio	Horizon.drawio	UEM+Horizon8.drawio

Network diagrams

During a Proof of Concept, network diagrams help bridge the gap between design assumptions and real-world implementation. The following diagrams illustrate the high-level architecture, key integration points, and data flows involved in the Omnissa platform. They are intended to validate design decisions, highlight dependencies, and serve as a reference during testing and issue resolution.

UEM	Horizon 8

UEM-ACC-Connector-UAG-PowerShell.drawio	Horizon8-CS-AppVol-UAG.drawio

Prerequisites workbook

I’ve also created a comprehensive prerequisites spreadsheet that captures all technical requirements in one place. It allows customers to record key configuration details as they work through the checklist. Once complete, the same document can be used as an as-built record, reducing duplication and saving time.

Omnissa-prerequisites.xlsx

Mathieu Beaugrand's Blog

Azure Lab Services retirement - Choosing the right EUC platform for what comes next

From simplicity to assembled solutions

1. Application lifecycle: App packaging vs image sprawl

2. User profiles: DEM vs profile containers

3. User experience: Performance + Access, not one or the other

3.1 The access layer: A true digital front door

3.2 The performance layer: Blast Extreme

3.3 Bringing it together: End-to-End user experience

4. Integrated stack vs layered tooling

5. Lab & training use cases: Where it all comes together

6. Future-proofing your EUC strategy: Hybrid by design, not by exception

6.1. Horizon Cloud: Built for hybrid from day one

6.2 The bottom line

7. Final thought

Enhance your Google Chrome security with Chrome Enterprise

1. Google Admin Console

1.1 Registration

1.2 Domain verification

1.3 Licenses

1.4 Services review

2. User synchronisation

2.1 SCIM configuration

2.2 User sync

2.3 Group sync

3. Single Sign-On (SSO) and federation

4. Google Chrome configuration

4.1 Chrome Enterprise Core

4.1.1 Reporting

4.1.2 Safe browsing

4.1.3 Third party device trust connector (optional)

4.2 Chrome extensions

4.3 Chrome Enterprise Premium

5. Deployment models

5.1 Managed browser

5.1.1 Enrolment token

5.1.2 Windows deployment

5.2 Managed profile

5.3 Confirm enrolment

6. User experience

7. Additional resources

Workspace ONE Launcher with CICO, MSAL & KAM

1. Knox Mobile Enrollment (KME)

2. Knox Service Plugin (KSP)

3. Knox Authentication Manager (KAM)

4. The Microsoft Authentication Library (MSAL)

4.1 Configure Microsoft SSO

4.1.1 Additional steps for hybrid setup

4.2 Microsoft Authenticator

4.3 Intelligent Hub settings

5. Workspace ONE UEM

5.1 Authentication settings

5.2 Multi-user staging account

5.3 Shared device settings

5.4 Intelligent Hub SDK

5.5 Workspace ONE Launcher

User experience

Bulk create EntraID users via PowerShell

Create a CSV file

Bulk create users with mobile phone MFA - Option 1

Bulk create users with Temporary Access Pass (TAP) - Option 2

Bulk password reset

Migrating Omnissa DEM from AD mode to No-AD mode

Overview

AD vs. No-AD mode

AD mode

No-AD mode

Why migrate to No-AD mode?

Change considerations

What changes

What doesn’t change

Co-existence

Migration steps

1. Create a NoAD.xml configuration file

2. Enable No-AD mode on client machines

3. Verify policy application

4. Roll out in batches or rings

5. Rollback (If needed)

Final Thoughts

Uninstall Windows applications silently with PowerShell

1. Create a `NoAD.xml` configuration file