Extending Workspace ONE to Complete Your Enterprise Device Management Requirements

with No Comments

The Problem

Workspace ONE is a wonderful product! However, just like any other product, there are some features we would like to have, but aren’t part of the product yet or may never be. For a while this was frustrating to the VMware IT team. There was pressure to implement particular components but our requirements could not be met. A prime example of this was mac management. While the management of macs is great, we wanted Workspace ONE UEM to help more with our automated deployment capabilities. We needed the hostnames of these machines to be automatically determined and applied.

Our team decided to take a different view.  Instead of constantly hounding the product team to deliver on all of our demands we took a step back and reevaluated our options.  We found that through the Workspace ONE APIs, Workspace ONE already offered so much more than we initially realized.  The Workspace ONE APIs combined with FaaS enabled us to implement the additional requirements we have.

Use Cases

  • Identity Management Network Sync: VMware IT maintains multiple VMware Identity management tenants that have some overlapping requirements.  One of these requirements is our network definitions.  We are using this project to synchronize the network definitions from a primary VMware Identity Management tenant to multiple secondary tenants.
  • Device Hostnames: VMware IT needs to have automated and deterministic hostnames applied to Workspace ONE managed devices.
  • Criteria Based Automated Tagging: When managed devices meet certain requirements we are able to automatically apply a tag to the device in turn pushing down special profiles.

How We Solve It

Tools Used
  • AWS Lambda
  • AWS RDS
  • Python 3
  • Serverless
  • Workspace ONE UEM APIs
    • Custom attributes setting the device hostname (out of scope for this post)

Below is a sample diagram of how we solved the hostname requirements.  There are 2 flows.  The first (green) flow populates the AWS RDS database for use by the Lambda function and the second (blue) flow is the flow of a device obtaining a hostname.

  • Data Population (Green) Flow
    1. Scheduled task uses Workspace ONE API to capture device hostname and user data
    2. API replies with full list of devices with hostname and users
    3. The same task populates the database with the data
  • Device Hostname Request (Blue) Flow
    1. Device is enrolled into Workspace ONE UEM
    2. Script pushed to device to request hostname
    3. Device sends user, serial, and current hostname to Lambda function
    4. Lambda request device information from database
    5. Data returned from database
    6. Lambda Function compares data sent from device against known device data in database, determines hostname, and applies hostname

Impact

Our team has had positive results from utilizing this approach. We were able to roll out projects successfully and faster from utilizing this method and mindset. Utilizing this approach is a solution for our team on a regular basis. I believe IT operation teams whom are capable of thinking out of the box and harness the idea of FaaS for problem solving will be able to stand out as rock stars in their organization.

Now and The Future

Currently, we are using the AWS Lambda functions with the serverless framework to deploy our functions.  However, VMware has a new tool called Dispatch (Check it out here) that we are evaluating for our use cases.  This looks especially promising for on-premises use cases we do not want exposed on the public internet.

What are your use cases?

Please comment below and talk about your use cases and how you are solving them!  I would love to hear from you!

Leave a Reply