Recently at VMware Explore, an under-the-radar session about the new cloud native Workspace ONE enhancements took place. This session covered the new enhancements that happened behind the scenes on the platform. Most of what was discussed, was mentioned in this article a year or so ago. The major takeaway is that we are moving to a Desired State Management-adjacent framework providing Workspace ONE delivery optimization that should eliminate many of the headaches that comes with administration.
Today, we will discuss the new architecture (or at least how I understand it at this point), how payloads are being delivered today, and the new capabilities that are rapidly approaching (hopefully by end of year). There are definitely reasons to be excited as we embark on this journey.
The Current Architecture in Workspace ONE UEM
In Workspace ONE UEM today, you have architecture that looks like this basically:
There are plenty of other components optionally, but for the sake of this conversation we will focus on the core basics. Basically, to make it simple we have a collection of services:
| Service Name | Short Description |
| AirWatch API Workflow | Processes WS1 API commands. |
| AirWatch Background Processor Service | Executes asynchronous long running jobs. |
| AirWatch Batch Processing Service | Processes batch requests |
| AirWatch Cloud Messaging Service | Runs message queueing server that transfers messages between devices and WS1 |
| AirWatch Compliance Service | Evaluates compliance and executes actions. |
| AirWatch Content Delivery Service | Pushes staging and provisions content to relay servers. |
| AirWatch DataPlatform Service | Pushes data to WS1 Intelligence. |
| AirWatch Device Scheduler | Orchestrates scheduled jobs across console and devices. |
| AirWatch Directory Sync Service | Syncs users and group for directory services. |
| AirWatch Entity Change Queue Monitor | Monitors event log queue and sends outbound event logs. |
| AirWatch Entity Reconcile Service | Reconciles and syncs for entities linked to smart groups. |
| AirWatch Eventlog Processor Service | Monitors event log queue, enriches, and posts to WS1 Intelligence. |
| AirWatch GEM Inventory Service | Communicates instance-specific info to Global Environment Manager (GEM). |
| AirWatch Integration Service | Integrates WS1 with 3rd party apps. |
| AirWatch Interrogator Service | Reads device samples from the queues and writes to the DB. |
| AirWatch MEG Queue Service | Reads and processes mobile email gateway requests from the queues. |
| AirWatch Messaging Service | Sends messages to platform messaging services like APNS. |
| AirWatch Outbound Queue Monitor Service | Subscribes for outbound event notifications. |
| AirWatch Policy Engine | Determines product and product set validity/compliance for devices. In turn, it will queue up jobs to execute on devices. |
| AirWatch Provisioning Package Service | Generates the PPKGs for dropship provisioning. |
| AirWatch Smart Group Service | Updates smart group device maps. |
| AirWatch SMS Service | Sends SMS messages to devices. |
| AirWatch Tunnel Service | Manages the WS1 Tunnel configs. |
| MetadataTransformService | Stores DDUI metadata used to render the UI and creates the device profile. |
Okay, I know that was way TOO much, but I wanted to make a point. You also have stuff like MSMQ, which we will discuss in a second. Basically, you get the gist that there’s a bunch of services sitting on your WS1 servers and has been for years. Let’s discuss MSMQ before we get to the new architecture.
What is MSMQ?
The Message Queuing service in Windows, is how jobs/tasks, etc have been processes today. The concept is relatively simple:
MSMQ is a messaging infrastructure and development technology that facilitates collaboration between multiple applications/services. Simply, its a queue manager that helps Workspace ONE work its magic.
So, Workspace ONE’s services mentioned earlier will send messages to queues and read those queues to queue up tasks going to devices through the AirWatch Messaging Service for example. Now, I’m not going to list the queues because that’s ridiculous, but you can see them yourself here. For context, there are 128 queues that are created in MSMQ.
You have a few different functions that happen with MSMQ:
- Creating Queues (which I believe happens when services are installed)
- Finding a specific Queue (graphic below, and happens either via API function calls or COM methods calls):
- Opening Queues (involves sending messages, pulling, examining, closing queues)
- Navigating Queues (involves using IDs to find the item you’re looking for)
Essentially, your services are writing and reading from the queue to facilitate the delivery of various things, like profiles, apps, policies, etc.
Some of the challenges we’ve seen over the years are things like:
- Inactive devices filling up the queue, which is getting jobs stuck in the “held” or “queued” state
- Services failing to start because queues couldn’t be created
- Duplicate user accounts and conflicts, etc. There are various problems that have occurred over the years, which tells us it’s time to modernize.
The New Modern Architecture of Workspace ONE UEM
VMware has made significant investments in containerization, such as Tanzu/Kubernetes so it’s only logical they would eat their own dog food. The new architecture focuses around building microservices as you can see below:
Additional containerized services have been added, which was covered at VMware Explore for this new graphic:
Some of the capabilities that have been designed on the new platform are:
- Global Freestyle Orchestrator
- The New Windows Update capabilities in UEM 2306 (I covered some of the features/concepts recently)
- Windows Multi-User
- Linux
- Android Management APIs
- Apple DDM
VMware powers these microservices with their Control Plane, which has done wonders for Horizon and its cloud offerings. Some of the new capabilities the Control Plane are:
- Improved Performance by reducing the reliance on the DB (microservices have their own databases)
- Services that are independent, delivering multiple benefits:
- One service can be changed without impacting the others.
- Lower risks and easier testing because of isolation (bugs can be fixed faster yay!)
- Increased reliability as issues with one microservice shouldn’t affect each other.
- Improved scalability thanks to the Control Plane and its scalability (think of how autoscaling works in AWS) as things can grow and shrink to meet demands.
- Development enhancements, such as their CI/CD pipeline to deliver enhancements faster than ever before.
So, you’re saying “Okay this is sort of interesting, maybe a little confusing, but what does it actually mean to me?”
Resource delivery optimization is what we’re here to discuss. Let’s move onto that discussion.
Resource Delivery Optimization
Let’s first talk about the value. The new optimizations in testing have reported to have nearly a 40x improvement. Publicly, they’ll be stating 10x, which on its own is entirely worth it from my opinion.
The reason why this is so crucial is VMware separated out UX and Reporting from the standard UEM/MDM flows. Historically stuff like AirWatch Reporting and UI have created a ton of slowness on the UI and platform. We saw some of these adjacent benefits when we moved off of SSMS and to the data lake in Workspace ONE Intelligence. (Many of us remember those 10m waits for reports back in the day).
The first wave of resource delivery optimization is targeting for Q3:
Device State Service: This service will detect what the current state of the device is for the new desired state management capabilities.
Platform Resource Management: Evaluates the delta from device state services and will process the commands to bring the device to its desired state.
Desired State Service (still waiting for confirmation): Stores the data for your desired state.
Sampling Service (still waiting for confirmation): Processes the device samples to collect what current state is.
Entitlements Services (still waiting for confirmation): Processes and syncs entitlements
YATs Service: Unsure and looking into that.
With the new resource delivery capabilities, VMware moves from a “Push” to a “Pull” delivery methodology. The concepts behind it are very similar to how ActiveSync works.
Devices will be checking in every 4 hours, which gets us away from the concept of MSMQ and toward devices policing themselves not dissimilar from what Apple has done with Declarative Device Management.
With WS1 Desired State Management, it leverages the Device State service to find out what the device is missing every 4 hours. The Platform Resource Manager will now process the commands to bring it up to a “desired state”
This graphic shows how these improvements deliver that performance improvement:
Workspace ONE Deployment Tracking Comes to Life
The deployment tracking capabilities in Workspace ONE are a great example of these new features coming to life. Mostly, your situation doesn’t change all that much.
Once you go to publish your assignment, you will see that you see a few different things
Firstly, you will see a banner showing you the expected percentage of updates done by a given time based on the state of your device fleet:
Additionally, you can see that it provides much better context into what is going to happen if you click the dreaded “Publish” button.
After publishing, you can see that they do a great job with an interactive screen where you can filter, see how many devices are pending check-in, and much more (delivering a really nice user experience for your administrators):
Final Thoughts
I was a bit unsure when the announcement came out around the re-architecture because of how it was communicated to be honest. I think now that I have seen under-the-covers with the shift to microservices that we are moving in a good direction. Microservices plus the CI/CD pipeline is a huge win. What we need for this platform to re-establish its competitive advantage is to rollout capabilities faster, better, and sooner.
Inevitably, Workspace ONE is positioned to be successful and my hope is this will be a great way to combat the Intune Suite crowd that think they’ve won. There is a real opportunity to capitalize off the Desired State Management popularity around the Enterprise world, which I believe is the goal to give users the experience they are striving for.
