Printer Management Is GA. Now Go Enroll Some Printers.

I have spent enough time saying "soon."

Printer Management is officially GA, shipped as part of Workspace ONE UEM 2607 (26.07).

That means this is no longer a roadmap slide, a demo environment, or me finding increasingly creative ways to tell you to stay tuned.

It shipped.

The official Omnissa announcement, Workspace ONE UEM 2607 release notes, and current technical documentation carry the formal version. This is my version: what shipped, why Zebra came first, why MQTT matters, and why Intelligence is the part I want to keep pushing.

What actually shipped?

This first GA release brings supported Zebra printers into Workspace ONE UEM over MQTT.

Administrators can enroll and synchronize supported printers, then manage the things that determine how those printers behave:

• Wi-Fi settings and credentials
• Firmware distribution
• Print behavior through ZPL and CPCL
• Power management
• Remote health monitoring, alerts, device queries, and selected remote actions
• Protected-device behavior, including EU RED Protected Mode where applicable

Printer health can also flow into Omnissa Intelligence for visibility, analytics, reporting, alerts, and supported remediation workflows.

That is the short version. The supported model, firmware, licensing, and exact action still matter. The current Zebra printer-management guide gets the final word on what is supported today.

The more interesting version is why those pieces look the way they do.

Why Zebra came first

Zebra is one of those brands you may not notice until you start looking. Then it is everywhere behind the work: labels, receipts, wristbands, shipping, checkout.

Its printers are already deployed across retail, transportation, logistics, manufacturing, healthcare, and plenty of other environments where printing is part of the actual work. When we spoke with customers about their printer estates, Zebra came up again and again. It was already one of the OEMs many of them had in their portfolio.

Customer demand got Zebra into the conversation. Technical readiness made the conversation practical.

Zebra has been building robust enterprise printers for a long time, and it has supported MQTT on relevant devices. For a first OEM, we needed customer demand and technical readiness to meet in the same place. With Zebra, they did.

Put those things together and it was a fairly obvious place to start. Honestly, choosing anyone else first probably would have required a much longer explanation.

Zebra first does not mean Zebra forever, and it does not mean every Zebra model is automatically supported. The current technical guide covers MQTT-capable supported models and firmware requirements; older or incompatible printers may still need the connector path. The broker model, payload framework, backend, and Intelligence work were designed to go further.

I will talk about other OEMs when those plans are ready to share. No hidden names or mystery dates in this post.

Why MQTT

I wrote earlier that printer management reminds me of Android about 15 years ago. The market is fragmented across OEMs, devices expose different capabilities, and there is no equivalent of Google pulling the whole ecosystem toward one management model. The MQTT episode explains why I see the protocol as a product decision, not just an implementation detail.

My bet is that MQTT can become the unifying technical force that printer management has been missing.

That does not mean MQTT magically makes every printer identical. OEMs still expose different settings, commands, data, security models, and firmware behavior. An MQTT client alone does not turn a device into a supported Workspace ONE integration.

What MQTT gives us is a shared way to have the conversation.

Without that foundation, every new OEM can become another custom connector project. Build the translation layer, decide who deploys it, work out how it scales, split troubleshooting across multiple owners, and then support that arrangement for years.

Connectors solved a real problem, and they will continue to matter for printers that need them. The connector tradeoffs are worth understanding before choosing a path. MQTT gives us a cleaner foundation for devices that support it, with fewer moving parts between the printer and the management platform.

I also do not think this stops with printers.

MQTT is already widely used across IoT. Sensors, cameras, displays, and many other connected devices can use the same messaging pattern. That is not a product announcement for those categories. It is the reason this architectural decision matters beyond the first release.

If we are going to standardize, I would rather standardize on something that gives us room to grow.

Does the printer need an agent?

The printer does not get another agent to babysit. There is no Workspace ONE management agent installed on it.

Instead, the printer talks over MQTT and a broker carries the messages between it and Workspace ONE. That broker can be hosted by Omnissa or provided by the customer.

The printer still needs an introduction. During enrollment, it receives a small bootstrap configuration that tells it where to find the broker. The exact delivery method can vary, but this is an initial setup step. I walk through both wired printer enrollment and wireless printer enrollment with real hardware. Once that relationship is established, management happens remotely.

That matters because the whole point is to avoid another heavy software dependency on the printer. A small bootstrap gets the conversation started. It should not require someone to keep returning to the printer every time a setting changes.

Hosted MQTT broker or bring your own?

MQTT needs a broker. We decided to give administrators two ways to handle it.

Use the Omnissa-hosted broker

With the Omnissa-hosted path, your team does not have to deploy or operate separate broker infrastructure. Current licensing, availability, and packaging information still applies.

For most organizations, I expect this to be the default.

The best broker experience for most administrators is probably the one they barely have to think about. Configure printer management; we operate the broker. That is the whole pitch.

Unless an organization has a specific reason to own that infrastructure, why add another contract, service, dashboard, and troubleshooting path?

Bring your own

Of course, some customers already have a broker, a team that knows it, dashboards they trust, and strong opinions about where traffic should go. Telling those teams to throw that away would be silly.

For those teams, bringing their own broker may make perfect sense. It keeps printer communication within an architecture they already understand and operate. We deliberately gave administrators that choice.

The responsibility line is also clear. If you bring the broker, your organization provides it, pays any related costs, operates it, manages the contract, and troubleshoots the service. Workspace ONE manages printers through it, but Omnissa does not take ownership of that third-party infrastructure.

Choice is useful, but it does not mean both paths will be equally common. My expectation is that most customers will use the hosted broker because it removes work they do not need to take on. Customers with an established IoT environment can keep the control they already value.

The printer is in the device list

Printers appear in the same device list as Windows, Android, iOS, and the rest of the managed fleet.

Yes, this is where product people normally say "one pane of glass." I will spare you the slide.

Tags and filters can still give you a printer-only view. Open a printer record and you can see reported details such as its IP address and firmware version, along with its assigned configuration.

The practical benefit is that the mysterious printer under a counter gets a real device record. Somebody does not have to walk over and inspect it just to find out what it is running. That frontline scope, and why I care more about availability than another settings screen, is the point of Episode 4.

What can you manage in GA?

At a high level, GA covers Wi-Fi and credentials, firmware, ZPL and CPCL print behavior, power management, remote health and selected actions, and protected-device behavior. In the console, that work is split across more specific payloads.

I will be honest: this is the basic management layer. It is important, but it is also what administrators should expect from a serious enterprise-management product.

Here comes the part where I risk sounding like a datasheet. I will try not to.

Wi-Fi

This is a full network profile, not just an SSID field. You can set the SSID, IP settings, and security type, including open networks, WPA-PSK, and enterprise authentication such as PEAP, TTLS, LEAP, and Kerberos.

That beats entering the same information through a tiny printer screen over and over.

Firmware management

You can send firmware to an enrolled printer and update it remotely. When printers are spread across stores, warehouses, hospitals, or other frontline locations, a firmware update should not automatically become a travel plan.

Credentials and certificates

Certificates are rarely the exciting part of a launch. They become very exciting when the printer cannot join the network. You can deploy client certificates and CA certificates to printers that need them. For networks using mutual TLS, that gives the printer the trust material and identity credentials it needs as managed configuration.

ZPL

For ZPL-based label printers, this payload controls label size, print width, media type, tear-off or cutter behavior, what happens if the printhead opens during a job, and what happens when the printer powers up.

Those settings look small in a feature list. One inconsistent setting on a busy floor can create a surprisingly large pile of bad labels.

CPCL

CPCL serves a similar role on supported mobile, label, and receipt-printer workflows. Different language, same goal: consistent output without visiting every printer by hand.

Power

The power payload covers ENERGY STAR timers, sleep behavior, and wake-on-radio. These controls matter most for mobile and battery-powered printers that need to be ready when a worker reaches for them.

Remote health and selected actions

The remote side includes health and availability signals, alerts, device queries, and selected actions such as a soft reset. Mirror can also point a printer at a remote endpoint for status collection. It is useful, but it is not a magic remote-repair button; some deeper troubleshooting still requires physical access and Zebra utilities.

Custom settings

There will always be a printer setting that does not fit neatly into a named payload.

Custom settings provide a free-form path for options outside Wi-Fi, firmware, certificates, ZPL, CPCL, power, or Mirror. I think of it as the escape hatch. Named payloads make common work easier. Custom settings keep us honest about the fact that printer environments are not all identical.

Keep it in sync

This does not end with one manual push. Synchronization runs on a schedule you control, giving enrolled printers repeated opportunities to receive assigned configuration and firmware when they are available.

Remote management at scale is not very remote if somebody has to start a fresh push every time.

How does EU RED Protected Mode affect management?

This is the part where firmware, geography, regulation, and timing all decide to share a table. The real-world fleet will not be uniform, and the current public material does not give me enough room to flatten this into one universal workflow.

The EU's Radio Equipment Directive and its related cybersecurity requirements cover certain internet-connected radio equipment. The current consolidated text is on EUR-Lex if you want the legal source instead of my summary.

How those requirements appear in a printer estate can vary by OEM, model, firmware, market, and when a device shipped. A printer that has already been deployed in the EU may not behave exactly like a newer unit shipped with Protected Mode.

I called out EU RED Protected Mode in my Community announcement because protected-device behavior matters to this launch. What I do not want to do is turn that line into a blanket support or compliance promise. Current Omnissa and Zebra documentation determines which devices, firmware, and workflows are supported.

We designed the management layer to account for evolving protected-device behavior without giving up remote administration. I will cover the exact flow when I can do it model by model instead of waving at a regulation and pretending every printer behaves the same way.

This post is not a blanket compliance guarantee. Device scope, deployment details, firmware, and legal obligations still matter.

Why does Intelligence matter?

Let me be blunt.

Wi-Fi profiles, firmware updates, certificates, printer settings, scheduled synchronization, and a device record are all necessary. They are also table stakes. Any enterprise-management platform that wants to take printers seriously should be able to handle the basics.

For me, Intelligence is where this solution starts to earn its keep.

As part of this GA release, available printer signals can flow into Omnissa Intelligence. Administrators can use supported data for dashboards, reports, alerts, and workflows. The exact attributes and actions still depend on the supported printer, firmware, licensing, and integration.

That lets us begin asking better questions.

Which printers are still reporting old firmware? How is the fleet divided by model or platform? What does printer availability look like across locations? Is a device unavailable, and is that an isolated failure or part of a larger pattern?

Static management tells you what configuration was assigned. Intelligence should help tell you what is actually happening.

Visibility is step one. I want the system to do something with what it sees. Can we recognize that a printer is down before it becomes a support call? Can we find a repeated failure across a model or site? Can we trigger the right response instead of waiting for someone on the floor to report a problem?

I am not turning every one of those questions into a GA promise in this post. I am saying that this is where the real value is, and it is the area I want us to keep pushing.

The feature list does not do the Intelligence work justice. Intelligence deserves its own posts, with actual reports, useful questions, and examples of what administrators can do with the data.

If you skimmed straight to the bottom, here is my version. Workspace ONE UEM 2607 shipped Printer Management. Zebra gave us the right place to start. MQTT gives us a standards-based path intended to support more than one OEM. The hosted broker removes work for most customers; the bring-your-own option respects teams that already run IoT infrastructure. Protected-device behavior reminds us that security is changing underneath real fleets. And Intelligence is the part I am personally most excited to prove in the field.

Zebra is first. The system underneath it was designed to go further.

If there is an OEM you are waiting on, or a printer report you wish you had today, let me know. Those are exactly the conversations I want to have as this rolls out.

For today, though, I am going to enjoy replacing "coming soon" with "shipped."

Now go enroll some printers.