0

Automating your Windows Golden Image with WorkspaceONE UEM’s Onboarding Workflows and Enterprise App Repository

The opportunity hiding in plain sight

Many organizations are migrating to Workspace ONE UEM to manage their modern workplace. Policies, scripts, applications, and workflows all find their place there. It becomes the single platform for managing devices and delivering software to end users.

Yet when it comes to building a Golden Image for your Omnissa Horizon VDI environment, legacy tooling often stays in place. Separate packaging solutions, dedicated image build servers, scripts maintained in a different location — all kept alive specifically for the image build process. The result is that applications and scripts end up living in multiple places, updates need to happen in more than one system, and tooling that might otherwise be decommissioned stays on the radar.

It got me thinking: does it really have to be that way?

I started exploring what it would look like to build a Omnissa Horizon Windows 11 Golden Image using HashiCorp Packer and Workspace ONE UEM — with minimal effort and no legacy tooling involved. This post is the result of that exploration. Not a production blueprint, but a demonstration of what is possible. It might give your organization some ideas on how to simplify the image build process by making better use of what you already have.

One command starts the build. No one logs in. Around 60 to 90 minutes later, a fully optimized, agent-installed vSphere template is ready to use.

Why lean on UEM for image building?

Before diving into the technical details, it is worth explaining why UEM is the right tool for this.

1. Reduce tooling overhead

If applications, scripts, and configurations already live in UEM for device management, it makes sense to reuse that investment for image building as well. No separate packaging tool, no additional hosted file shares, no duplicate maintenance. What is defined once in UEM works for both the image build and ongoing device management.

2. The Enterprise App Repository changes the packaging equation

Omnissa UEM now includes the Enterprise App Repository, a catalogue of over 9,500 pre-packaged applications delivered via Winget. Instead of downloading an installer, wrapping it, hosting it, and keeping it up to date, you simply select the application from the catalogue. UEM handles the rest.

For image building this is a significant time saver. Standard runtimes like .NET and Visual C++ redistributables — which every VDI image needs — are available out of the box, always up to date, and require zero packaging effort. That is time and energy you no longer spend.

3. Freestyle Orchestrator Onboarding Workflows are purpose-built for this

The Onboarding Workflow within Freestyle Orchestrator is triggered immediately after a device enrolls in UEM — exactly once, in a fixed order, and never again for that device. This makes it ideal for image builds where you need:

  • A guaranteed execution order (runtimes before agents, agents before optimization)
  • Single execution (the OSOT finalize and shutdown must not run on production devices)
  • No user interaction required

Regular app assignments in UEM do not offer these guarantees. The Onboarding Workflow does, out of the box.

Architecture overview

The pipeline splits into two clean phases.

Phase 1 — Packer creates the VM in vSphere, installs Windows 11 fully unattended, installs VMware Tools, and enrolls the machine in Omnissa UEM. Once the Workspace ONE Hub is active and the device is enrolled, Packer steps back and waits.

Phase 2 — UEM Onboarding Workflow takes over completely. It runs a conditional check to confirm this is a Packer build VM, then installs runtimes, agents, and default applications in order — and finally runs the OSOT script to optimize, finalize, and shut down the VM. Packer catches the shutdown, takes a snapshot, and converts the VM to a vSphere template.

Phase 1: Packer

VM configuration

The Packer configuration uses the vsphere-iso builder. A few notable choices:

  • EFI-Secure boot + vTPM — required for Windows 11
  • PVSCSI controller + VMXNET3 — optimal VM performance in vSphere
  • IDE cdrom — needed for reliable EFI boot from ISO
  • WinRM communicator — Packer connects via WinRM once Windows is up
  • shutdown_timeout = "3h" — Packer waits patiently while UEM does its work
source "vsphere-iso" "win11" {
  firmware  = "efi-secure"
  vTPM      = true
  CPUs      = 2
  RAM       = 4096

  shutdown_command = "echo 'VM shuts itself down via UEM finalize script'"
  shutdown_timeout = "3h"

  create_snapshot     = true
  snapshot_name       = "final-optimized"
  convert_to_template = true
}

Packer mounts a virtual CD labeled PACKER containing the AirwatchAgent.msi, the enrollment script, setupcomplete.ps1, and the OSOT XML optimization profile for Windows 11.

Unattended installation (autounattend.xml)

The autounattend.xml handles the complete Windows installation without any user interaction. In the windowsPE pass, diskpart creates a GPT layout with an EFI partition, MSR, and Windows partition. In the specialize pass, files from the PACKER CD are copied to C:\Temp and SetupComplete.cmd is created:

<Path>cmd /c echo powershell -ExecutionPolicy Bypass -File F:\setupcomplete.ps1> C:\Windows\Setup\Scripts\SetupComplete.cmd</Path>

Windows calls this automatically at the end of OOBE — without anyone ever logging in.

SetupComplete (setupcomplete.ps1)

Once OOBE completes, setupcomplete.ps1 does three things:

  1. Reconfigures WinRM so Packer can connect
  2. Installs VMware Tools by detecting the correct CD drive letter automatically
  3. Schedules enrollment via RunOnce so the enrollment script runs at the next autologon
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" `
  -Name "EnrollWS1" `
  -Value "PowerShell.exe -ExecutionPolicy Bypass -File C:\Temp\enroll-ws1.ps1"

Enrollment (enroll-ws1.ps1)

The enrollment script installs the Workspace ONE Intelligent Hub silently and enrolls the machine directly into the correct Organizational Group:

$msiArgs = @(
    "/i", $HubInstaller, "/qn", "/norestart",
    "ENROLL=Y",
    "SERVER=$Server",
    "LGName=$GroupID",
    "USERNAME=$Username",
    "PASSWORD=$Password",
    "ASSIGNTOLOGGEDINUSER=N"
)

After installation the script waits up to 15 minutes for the AirwatchService to become active. Once it does, Packer’s job is essentially done — UEM takes over completely.

Phase 2: Omnissa UEM — Freestyle Orchestrator Onboarding Workflow

This is where the real work happens, and where this approach differs most from traditional image building.

The workflow condition

The very first thing the Onboarding Workflow does is evaluate a condition:

  • ComputerName contains PACKER-WIN11
  • AND the registry path HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName exists with a value containing PACKER-WIN11

Only if both conditions are true does the workflow proceed. This is the safety mechanism that ensures the workflow never runs on a real user device — even if that device ends up in the same Organizational Group. The Packer build VM is identified by name and registry, and nothing else triggers this workflow.

Runtimes via the Enterprise App Repository

The first real steps install the prerequisites: .NET Runtime 3.1 and both x64 and x86 Visual C++ 2008 Redistributables. All three come from the Enterprise App Repository — no packaging required, no hosted files, no version maintenance. You select them from the catalogue in the UEM console and they are delivered via Winget during the build.

Each runtime installation is followed by a Restart-Computer, initiated by a PowerShell script delivered via UEM rather than a native UEM reboot action. This gives more control over timing and logging.

The order is deliberate: runtimes first, because the Horizon Agent and other components depend on them being present.

Agents as internal apps

The three Omnissa agents — Horizon Agent, DEM Agent, and App Volumes Agent — are not available via Winget, so they are uploaded as traditional internal apps in UEM and installed silently. This is a small exception to the “no packaging” approach, but unavoidable for vendor-specific agents.

After the agents are installed, another Restart-Computer fires to let Windows settle before the next phase.

Default applications via the Enterprise App Repository

Once the agents are in place, a grouped step installs the default application set:

  • Microsoft 365 Apps (Business Retail, Dutch, x64, current channel)
  • Notepad++
  • Omnissa Horizon Client
  • Workspace ONE Assist

All of these come from the Enterprise App Repository. For a standard VDI image, this covers the baseline application set without a single MSI wrapper or hosted package file. The catalogue handles sourcing, delivery, and keeps versions current.

OSOT: optimize, finalize, and shutdown

The final step in the workflow is a UEM-delivered PowerShell script that does everything needed to close out the image build. OSOT is being delivered as an internal Application, the .EXE is copied to C:\temp and will be triggered by a PowerShell script.

#Optimize OS with nOmnissaHorizonOSOptimizationTool
& "C:\Temp\OmnissaHorizonOSOptimizationTool-x86_64-1.2.2603.23605577104.exe" -o -t "C:\Temp\Windows_11.xml"

#Finalize OS with nOmnissaHorizonOSOptimizationTool and shutdown
& "C:\Temp\OmnissaHorizonOSOptimizationTool-x86_64-1.2.2603.23605577104.exe" -f 0 4 5 6 10 -shutdown

 

The Windows_11.xml profile was placed on C:\Temp by the Packer CD during the initial setup. It contains hundreds of registry tweaks, scheduled task adjustments, and service configurations tuned for VDI workloads — disabling the Content Delivery Manager, animations, autologgers, and more.

When the VM shuts down, Packer wakes up, takes the final-optimized snapshot, and converts the VM to a vSphere template. The build is complete.

In the Workspace ONE UEM console this looks like:


Variables and secrets

All environment-specific values — vCenter address, credentials, datastore, network, and ISO path — live in a separate .pkrvars.hcl file that should never be committed to version control.

packer build -var-file="variables.pkrvars.hcl" win11-25h2.pkr.hcl

In a CI/CD pipeline, use a secrets manager or vault for credentials instead of a flat file.

 

Conclusion

The combination of HashiCorp Packer and the Omnissa UEM Freestyle Orchestrator Onboarding Workflow produces a clean separation of concerns. Packer does what it does best: create a VM, install Windows, and enroll the device. UEM does what it does best: deliver software in the right order, to the right device, exactly once.

The Enterprise App Repository removes the biggest pain point of traditional image building — application packaging. Over 9,500 applications available out of the box means that runtimes, productivity tools, and utilities no longer need to be packaged, hosted, and maintained separately. The only exceptions are vendor-specific agents that are not yet in the catalogue.

The Onboarding Workflow within Freestyle Orchestrator provides the execution guarantees that regular app assignments cannot: fixed order, single execution, and immediate triggering on enrollment. For image building, these guarantees are not nice-to-haves. They are requirements.

The end result is a fully hands-off process. From packer build to a ready-to-use vSphere template in 60 to 90 minutes, with no manual steps and no one logging in.

Packer Configuration, Scripts, AutoUnattend.xml etc are available for reference: https://github.com/roderikdeblock/Packer-WorkspaceONE-Onboarding-Workflow/tree/main

The views, thoughts, and opinions expressed in this article are solely my own and do not represent those of any employer, client, organization, or other group or individual. All content published here is based on my personal experience, research, and perspective at the time of writing and is provided for informational purposes only.

Roderik de Block

Leave a Reply

Your email address will not be published. Required fields are marked *