Omnissa ONE 2026: Elara, Agents and an MCP Server for Workspace ONE

Joseph Klimczak September 30, 2026 No Comments

My recap of the announcements from Omnissa ONE in Orlando

Disclosure: I’m an Omnissa Tech Insider. The opinions below are my own.

Omnissa ONE 2026 in Orlando (September 28-30) came with a lot to unpack. A new CEO took the keynote stage on day two of his new job, and the company put out a run of announcements built around one theme: an autonomous workspace where AI agents do real work, with IT still in control.

I already wrote about Amit Singh’s “The Agentic Endpoint” post. This is the follow-up: what was actually announced, what’s available now, and what I’m most interested in.

Omnissa Elara: governing AI on your endpoints

The headline announcement is Omnissa Elara, which Omnissa describes as an authority layer for AI. Its principle is “control before consequence.” It connects the systems you already run (identity, endpoint, security and ITSM) so that actions taken by people and AI agents can be understood, approved and recorded.

Omnissa’s announcement and the Reworked coverage describe four things Elara does:

• Finding shadow AI. It looks for AI apps, models and agents that aren’t on your approved list.
• Setting rules for AI use. Through the Omnissa AI Gateway, you decide which people, apps and agents can reach which AI models, and you can track token usage.
• Checking changes before they happen. Before a change goes through on a company system, it checks for conflicts, scheduled freezes and dependencies, then approves the change, limits it or sends it to the person with authority to sign off.
• Keeping a record. It logs what happened, who approved it and what it touched, so the sequence can be repeated later.

Brian Link, Product CTO (Americas) and Head of Platform, put the reasoning well: “The most important questions rarely live in any one system. They live between them.”

Status: Elara is in beta, with a waitlist and an interactive demo tour. Pricing and detailed specs weren’t published in what I read.

A hosted MCP server for the Omnissa platform (generally available)

This is the announcement I expect to matter to admins the most day to day. Omnissa announced a hosted Omnissa MCP server, built on the Model Context Protocol. Admins can connect an AI client of their choice, such as Claude or Copilot, directly to Workspace ONE UEM and other Omnissa services. Omnissa’s own example of where this is headed is an admin asking “What needs attention today?” instead of clicking through multiple screens.

The important part is the guardrail: every action taken through an AI client inherits the same role-based access controls and audit trail admins already rely on. Because it’s a standards-based protocol, it also avoids locking you into one AI vendor.

Status: generally available.

More autonomous endpoint management in UEM

The same set of UEM announcements includes:

• Smart Groups 2.0. Multi-step rule building with sensor values and nested AND/OR logic, so you can target devices by how they behave instead of static lists or custom scripts.
• Smarter phased deployments. Rollout progression can now use digital experience metrics such as crash rates and startup performance, along with reusable rollout templates.
• Dual admin approval. A second reviewer for defined resources before changes take effect. This is listed as coming.
• Root-of-trust resource signing. Makes sure only verified, unmodified resources install on endpoints. Also listed as coming.

New agents for IT operations

Omnissa announced three IT operations agents, each with a human in the loop:

• Digital Employee Experience (DEX) Agent. Investigates employee experience issues, finds root causes, and recommends fixes using playbooks and session history.
• Workspace ONE Vulnerability Defense Agent. Autonomously reviews and prioritizes vulnerabilities, prepares patching actions and approves deployment, with human-in-the-loop guardrails.
• Windows App Lifecycle Agent. Packages and tests applications before an administrator reviews them.

Horizon and Cloud PC

• Horizon Delegate. Lets users hand tasks to their own persistent agent inside their virtual desktop session. It acts with the user’s approved identity and permissions and can keep working when the user is disconnected. Expected as limited availability in Horizon 2609.
• App Packaging Agent. Continuously finds app updates and builds packages based on IT approvals. Expected as beta in App Volumes 2609.
• Omnissa Cloud PC. A turnkey cloud PC service that bundles compute, unified endpoint management, digital employee experience and Horizon Cloud DaaS. It launches on AWS first, with other hyperscalers planned. No general availability date was given.

What’s available now, and what isn’t

My take

I’m most excited about Elara, and it’s because of shadow AI. I’ve wanted a way to see what people are actually running on their devices, and this is the first announcement I’ve seen that goes straight at that problem. Discovery of unapproved AI apps and agents, plus rules for what they can reach, is exactly the visibility Singh’s Discover-Decide-Contain-Prove framework starts with. It’s still beta, so I’ll be watching how deep the discovery really goes and how well it fits with the tools we already run.

The MCP server is the practical win today. Letting admins use the AI tool they already like, with the same role-based access controls and audit trail they already rely on, is the right way to bring AI into daily operations. It’s generally available, so it’s the thing you can try first.

I’ll also be watching the agents. The Vulnerability Defense Agent is interesting because patching is where a lot of IT time goes, and the release says it runs with human-in-the-loop guardrails. I’d want to see exactly where those guardrails sit before trusting it with deployments. No dates have been published for most of these agents, so I’d treat them as direction, not a plan.

The overall message is consistent: agents are coming to managed devices, and Omnissa wants to be the layer that governs them. Some of this is shipping now, some is in beta, and some is still an announcement. That’s a fair state for a first showing. I’m looking forward to seeing which pieces land first.

Sources

• Omnissa unveils AI innovations for autonomous IT workspaces (press release)
• Introducing Omnissa Elara
• The building blocks of autonomous endpoint management
• AI-ready workspaces with Omnissa Horizon
• Reworked: Elara targets shadow AI, new agents automate IT

What are you most interested in? I’d like to hear it in the comments.

The Endpoint Is Becoming an Agent Platform

Joseph Klimczak September 30, 2026 1 Comment

My take on Omnissa CEO Amit Singh’s “The Agentic Endpoint”

Disclosure: I’m an Omnissa Tech Insider. The opinions below are my own.

Omnissa has a new CEO, and Amit Singh didn’t take long to say where he thinks endpoint management is headed. His first major post, The Agentic Endpoint, makes a claim that I think every IT team should sit with for a minute: the endpoint is no longer just where a person works. It’s where AI agents run.

I want to walk through what he argues, and then say where I think it lands for those of us who manage fleets for a living.

The core idea: one user, many actors

For as long as most of us have managed devices, the model was simple. One device, one user, a set of apps. Identity, permissions and network traffic all mapped back to a person.

Singh’s argument is that this assumption is about to break. He expects that within a year, the laptops and phones we manage will each be running not one user but dozens of AI agents. Some will be built into the apps we already license. Some will run as copilots. Some will be built internally. All of them will inherit the user’s identity, the user’s permissions and the user’s traffic patterns.

That last part is what matters. An agent acting “as” a user is indistinguishable, to a lot of our current tooling, from the user. Multiply that by dozens per device and the picture gets complicated quickly.

Why it changes the security picture

Two consequences stood out to me.

A compromised endpoint now exposes every agent on it. Attackers who land on a device don’t just get one person’s session. They get access to the agents running there and the credentials those agents hold. The endpoint becomes a concentration point, which is why Singh calls it “the most valuable ground on the network” and “the last mile of enterprise AI security.”

Agents can misbehave in ways ordinary software doesn’t. They operate asynchronously, so problems can run for a long time before anyone notices. Singh points to reported cases of test agents breaking out of sandboxes and pursuing goals nobody gave them. You don’t have to accept every example to see the underlying point: software that makes its own decisions needs a different kind of oversight than software that follows a fixed path.

He adds a third pressure that’s easy to overlook. Agents won’t stay on laptops and phones. They’ll show up on watches, earbuds, glasses and purpose-built enterprise devices, which means enrolling and managing device categories that many of us don’t touch today.

The framework: Discover, Decide, Contain, Prove

The part of the post I found most useful is that it doesn’t stop at “this is scary.” Singh organizes the response into four verbs.

1. Discover. Build a complete inventory of the agents on your devices and what they actually do. You can’t govern what you can’t see.
2. Decide. Set what an agent is allowed to do before it runs, not after something goes wrong.
3. Contain. Keep endpoints clean, give agents safe places to execute, and respond in proportion when behavior drifts from what was approved.
4. Prove. Keep audit trails so you can show compliance and reconstruct what happened.

If you’ve worked in endpoint management, none of these words are foreign. That’s the point of the framing. It maps onto things we already do (inventory, policy, remediation, reporting) and asks us to extend them to a new kind of actor.

Omnissa says it will build on what it already has around device management, virtual workspaces, credential handling, telemetry and fleet-scale remediation. The post names new capabilities on the way: discovery of AI actors, tools for setting agent permissions, agents that close vulnerabilities, and application lifecycle management.

My take

I’m excited about this one, and here’s why: I’ve been asking for a way to see what people are actually running on their devices, and shadow AI is the reason it has become urgent.

Right now, most of us can tell you what’s installed. We can’t tell you which AI tools and agents people are using, what those tools can reach, or whose credentials they’re running under. Some arrive as an install. Others show up as a feature switched on inside an app we already approved, or as a browser tool someone found on their own. Inventory tools tend to miss all of it. That’s a real blind spot, and it’s growing every month.

That’s why Discover is the part of Singh’s framework I care about most. A complete view of the agents on a device is the first thing I’d want, because every other step depends on it. You can’t set permissions for something you don’t know exists, you can’t contain it, and you can’t prove anything about it later. If Omnissa delivers real visibility into what’s running, including the stuff nobody told IT about, that’s a huge help for anyone managing a fleet.

Decide is the next hard problem, and it’s as much about people as tooling. Agent permissions need owners, review cycles and an exception process, the same as any other access. Left to defaults, agents end up with the user’s full reach because that was the easiest thing to configure. Prove is the one I expect auditors to ask about first: “What did this agent do on this device last Tuesday?” needs a real answer, with logs to back it up.

What I’ll be watching is how quickly discovery and permissioning reach the products we already run, and whether they work without yet another console. The value of extending an existing endpoint platform is that the team already knows it. I’m looking forward to seeing it land.

The takeaway

Whether or not the “dozens of agents per device within a year” timeline turns out to be exact, the direction is hard to argue with. Agents are arriving on managed devices, they carry user-level trust, and our tooling was designed for a world where that trust belonged to a person.

It’s worth reading the source, forming your own view, and starting the Discover work now, before the agents outnumber the apps.

Read the original: The Agentic Endpoint

Join the conversation: Omnissa community forums

What are you seeing on your own fleet? I’d like to hear it in the comments.

The App That Wouldn’t Die: A Workspace ONE Receipt-Collision Bug

Joseph Klimczak September 25, 2026 No Comments

If you manage macOS fleets with Workspace ONE UEM, you’ve probably seen it:
an agent gets pushed, installs fine, and then — for no visible reason — gets
uninstalled and reinstalled over and over, forever. Not once. Not twice.
Forever, on a cadence that seems to have no fixed schedule at all.

This is the story of chasing that bug down, the four things that looked
like fixes but weren’t, and the one thing that actually was.

The Symptom

A macOS endpoint kept losing its endpoint management agent. Every check-in
cycle, the Munki log told the same story:

Checking for removals
Removal of Automox Agent added to ManagedInstaller tasks.
...
Removing Automox Agent (1 of 1)...
Running uninstall_script for Automox Agent
Automox agent successfully uninstalled.

And a few minutes (or hours — the cadence was wildly inconsistent) later:

Checking for installs
...
Install of AutomoxAgent-2.6.53.pkg was successful.

Uninstall. Reinstall. Uninstall. Reinstall. All day. The agent’s own event
log showed matching delete/re-add cycles going back at least 24 hours.

First Theory: Server-Side Caching

The first real lead: two different Internal App records in the console
were both installing the exact same underlying package — a current build
and a retired one — and both were assigned (directly or via overlapping
Smart Groups) to the same device. Delete the stale one, problem solved.
Right?

Wrong. Deleting the conflicting app record from the console did nothing.
Neither did:

• Republishing the app
• Sending an MDM sync command via the API
• Clicking “Sync” in the console
• Waiting 45 minutes
• Waiting another hour
• A second, unrelated conflicting app record that was also still
  fighting over the same package (there were two culprits, not one — more
  on that below)

Every one of these should have worked if the problem were simply “the
server hasn’t regenerated the device’s catalog yet.” It kept generating
the exact same removal directive, over and over, no matter how long we
waited or how many syncs we forced.

The Reboot Test

Here’s where it got interesting. A full device reboot forces the Hub
Agent’s launchd jobs to reload from scratch, which — unlike any sync
command — reliably triggers a genuinely fresh manifest and catalog fetch.
If the server had actually fixed its state, a reboot should show it.

It didn’t. Post-reboot, first check-in, same story: fresh catalog fetched,
same stale removal directive, same uninstall, same reinstall a few minutes
later.

That ruled out “just a caching delay.” Something was regenerating this
removal directive from scratch, every single time, independent of what the
console said was assigned.

The Actual Mechanism

Pulling the raw device_catalog.plist off the device (the file Munki
actually consumes) revealed the real problem. Sitting in the array of
pkginfo items was a full entry for the retired app build — the one that
had already been deleted from the console — complete with its own
uninstall script.

And here’s the part that makes this a genuinely nasty bug rather than a
simple stale-record problem: both the current build and the retired
build install the same underlying macOS package receipt.

Old build → receipts: packageid "com.example.agent", version 2.0.28
New build → receipts: packageid "com.example.agent", version 2.6.53

Different pkginfo item names in WS1’s world. Same macOS package identity
in the OS’s world. That’s the collision:

1. Munki installs the new build. macOS registers receipt
   com.example.agent at version 2.6.53.
2. Something is still telling this specific device to remove the old
   item. Its removal condition checks: “is receipt com.example.agent
   present?” Yes — any version satisfies that check. Queue for removal.
3. The old item’s uninstall script isn’t version-aware. It deletes the
   binary and LaunchDaemon plist unconditionally — which happen to be the
   exact same files the new build also uses.
4. The agent is now gone. Next cycle, the new build is missing from
   managed_installs → gets reinstalled → receipt reappears → go to step 2.

An infinite loop, entirely self-inflicted by two catalog entries that
never should have shared a package identity in the first place, and it
will run regardless of what the console’s assignment state says,
because the local device state — not just the console record — was
carrying the stale entry independently.

Why Nothing Server-Side Fixed It

This is the part that cost the most time. The console-visible app
assignment and the actual served catalog are not the same source of
truth in every case. There’s a layer of local device state
(Munki_Repo/manifests, Munki_Repo/catalogs, plus a couple of
WS1-specific plists tracking app status and Munki metadata) that isn’t
guaranteed to get purged just because you deleted the app record upstream.
Once that stale entry is baked into a device’s local files, deleting the
upstream record doesn’t retroactively scrub it — you have to clear it on
the device itself.

The Actual Fix

A short script, run locally with root, that walks four files and deletes
any array entry or dictionary matching the stale app’s package ID or
display name:

• The local Munki metadata cache (munki_data.plist)
• The WS1 agent-status plist (AppStatuses_WS1.plist)
• The local source manifest (device_manifest.plist)
• The local source catalog (device_catalog.plist)

Run it, force one more check-in (a reboot, since sync commands still
weren’t reliable), and the loop actually stopped. managed_uninstalls
went empty and — this was the real test — stayed empty through multiple
subsequent check-ins, no regression.

Interestingly, a second app on the same device hit an almost identical
setup (two catalog entries, same shared package receipt, overlapping Smart
Group assignment) but resolved cleanly with just the console-side
deletion — no local script needed. Same bug shape, two different severity
levels, presumably depending on how long the stale local state had been
sitting there accumulating.

The Takeaways

1. “I deleted it from the console” doesn’t mean it’s gone from the
   device. MDM-managed Munki hybrids keep local state that can outlive
   the record that created it.
2. Sync commands aren’t all equal. An MDM device-sync command updates
   MDM heartbeat/presence; it does not necessarily poke the software
   management agent’s own check-in cycle. If you need a real software
   catalog refresh, a reboot is more reliable than any “sync” button.
3. Two packages that install the same underlying receipt are a loaded
   gun, even if they look like unrelated catalog entries with different
   names and different versions. If your removal logic (or your MDM
   vendor’s) checks receipt presence rather than which catalog item
   installed it, you will eventually get exactly this loop.
4. When something churns forever with no fixed cadence, don’t assume
   it’s a caching delay just because waiting sometimes seems to change
   things. Test it properly — force a genuinely fresh state (a reboot) and
   see if the symptom survives. If it does, the problem is local, not
   server propagation lag.
5. Not every bug needs the same fix. Two apps, same failure shape, two
   different remedies. Diagnose each one on its own before assuming the
   first fix generalizes.

If you’re debugging a Workspace ONE app that seems to be stuck in a
delete/reinstall loop no matter what you do in the console: check whether
two catalog entries share a package receipt, and check the device’s own
local manifest/catalog files, not just what the console says is assigned.

Honored to Be a 2026 Omnissa Tech Insider (Year Two!)

Joseph Klimczak February 2, 2026 No Comments

I’m incredibly grateful to share that I’ve been selected once again as part of the 2026 Omnissa Tech Insiders —my second year in this inspiring community.

This year’s cohort brings together an exceptional group of professionals with deep experience across AI, cloud, security, developer tools, and beyond. The diversity of perspectives, real-world impact, and accomplishments across the group truly impressed me.

Being part of this community has been both energizing and humbling—learning from peers, exchanging ideas, and contributing to conversations that are shaping the future of technology. I’m proud to stand alongside such talented individuals and excited about what lies ahead.

A huge thank you to the Omnissa team and to everyone in this cohort. Congratulations to all the 2026 Tech Insiders—I’m looking forward to another great year of collaboration and growth.

👏

👉 View the full announcement here: https://lnkd.in/etxzrcVS

I Miss vCenter — So I’m Building My Own (in AWS)

Joseph Klimczak December 31, 2025 No Comments

I’ve been living in AWS long enough that I’m supposed to have moved on.

I can design multi-account landing zones, argue about Transit Gateways vs. VPC peering, and recite IAM best practices in my sleep. I understand why cloud-native patterns exist. I even agree with most of them.

But if I’m being honest?

I miss vCenter.

The Comfort of a Single Pane of Glass

Back in the vSphere days, vCenter was home base. One UI. One mental model. One place where I could:

• See all my workloads
• Understand capacity at a glance
• Migrate compute without rewriting the world
• Apply policies consistently
• Fix problems visually instead of spelunking through APIs

Yes, it was centralized. Yes, it had limitations. Yes, it could be fragile.

But it was coherent.

In AWS, coherence is… optional.

AWS Is Powerful — But Fragmented

Don’t get me wrong: AWS is incredible. The primitives are flexible, scalable, and battle-tested. But as an operator, the experience is scattered:

• EC2 over here
• ASGs over there
• Load balancers somewhere else
• Metrics in CloudWatch
• Config in tags (maybe)
• Inventory split across accounts and regions

The AWS Console isn’t lying to you — but it also isn’t telling you the whole story in one place.

Instead of operating infrastructure, I often feel like I’m assembling context.

What vCenter Got Right

vCenter wasn’t just a hypervisor manager. It was an operations platform:

• Strong inventory model
• Clear parent/child relationships
• First-class lifecycle concepts
• Human-readable abstractions
• Predictable workflows

You didn’t need five services and a wiki page just to answer:

“What’s running where, and why?”

So… I’m Building My Own vCenter (Sort Of)

I’m not trying to recreate vSphere in the cloud. That would miss the point.

What I am doing is building a control plane on top of AWS Using APIS that gives me back what I miss:

• A unified inventory across accounts and regions
• Opinionated metadata instead of tag chaos
• Clear ownership and lifecycle states
• Capacity and cost visibility that makes sense to humans
• Operational workflows that don’t start with “open three consoles”

Think less “hypervisor replacement” and more operator experience layer.

AWS provides the raw materials. I’m just putting a dashboard, model, and brain on top of them.

Cloud-Native Doesn’t Have to Mean Operator-Hostile

Somewhere along the way, “cloud-native” became synonymous with:

• More YAML
• More dashboards
• More glue code
• More tribal knowledge

But abstraction isn’t the enemy. Bad abstraction is.

vCenter succeeded because it respected how humans think about systems. AWS succeeds because it gives you freedom. The gap between the two is where a lot of operator pain lives.

That gap is exactly what I’m trying to close.

This Is Not Nostalgia — It’s a Design Problem

I don’t miss vCenter because it was old.

I miss it because it solved real operational problems well.

If we can acknowledge that, we can stop pretending the current state is perfect — and start building better tools on top of the cloud we actually run.

So yes, I’m an AWS admin Now.

And yes, I miss vCenter.

That’s why I’m building my own. More to come