WS1 UEM Event Notifications
Overview
Several years ago I gave a presentation at the old AirWatch Connect Conference about automating your AirWatch deployment. As AirWatch evolved into Workspace One UEM, there has been a big effort to imporove the API functionality of the tool, to make it easier to integrate into your existing enterprise apps, and bulild additional workflows. This post will focus on a particular feature in the UEM console - Event Notifications.
In this walkthough we will use a couple of services to build a workflow that when a device enrolls, an Event notification is fired to a web service, that will process the event, and respond by calling the UEM api for adding a device tag. In practice, this enroll+tag workflow probably isnt something that would be deployed in a production environmnet, but builds the foundation to easy expand on.
Event Notifications
Event Notifications in Workspace One UEM allow the UEM console to send a notification of an event in the UEM console, such as a device enrollment, unenrollment, compliance status change, etc.. to another service via http methods.
The VMware documentation for this feature can he found here
Prep work
As mentioned in the intro, we are going to be using several services to build our end to end service. What is cool about this, is that we will get some exposure to some pretty neat tech that I generally don't touch on a day to day basis - things like node.js, serverless, API scripting,
To follow this guide step by step we will need the follwing. If your just using this as a reference, adjust based on your development environment:
Admin Access to a Workspace One UEM console
a test device to enroll and unenroll in UEM
Create a pipedream account
Once we have those 3 things - were ready to build our workflow
Pipedream configuration
The first thing we have to do is get logged into pipedream and create a new event source
Head over to pipedream.com and if you dont have an account already, hit Get Started, if you have an account log in.
Start by clicking Workflows across the top nav bar and click New Workflow
Let’s give our new workflow a name - in the upper left-hand corner below the menu bar, click on "Title", and update it, in my case I am calling it "device enrollment, apply tag"
In the main window select the HTTP / Webhook trigger - this will generate a unique URL for your workflow that we can send event notifications to from the UEM console.
Copy the https URL into a note pad for use later on.
Below the trigger you will see a + button, select that and pick the Run Node.js code action
This will open up a code editor where we can run any node.js code, for now - let’s make it easy to understand and paste the following:
console.log('Everything is awesome.');
In the code editor window, click save, and then click deploy to make this a live serverless app
What will happen now, is that if trigger our workflow, either by generating test data in the workflow editor or by sending a message to the URL, the node.js console log will output our Everything is awesome message.
Let’s verify that by clicking the Send Test Event button
After a moment, a test event will be generated, and our node.js script runs, and we see in the console log output our message - very cool!
Now let’s get UEM connected to this and generate some test data for us to build our real workflow with.
Workspace One UEM configuration
Now that we have the service, we want to receive our UEM event notifications, let’s get UEM configured to send it some data.
Log into your Workspace One UEM console and head to Groups and Settings in the menu bar, then All Settings \ System \ Advanced \ API \ Event Notifications
Here we will configure a new rule - so hit Add Rule
In the Target Name, I like to make it descriptive so later on I remember what it was for - I am going to call mine - "pipedream app, device enroll apply tag"
The target URL is going to be the URL from our http trigger we built in the last step
We didn’t configure any auth on that app since this is just an educational thing - but for anything more than that I would advise you do - so leave those blank.
In the format - set it to JSON to make our lives easer later on
hit test connection and verify it was successful
That will actually generate an event in your pipedream workflow, and you should see your Everything is Awesome status message in the console log.
Let’s check that out, go back to your pipedream window, on the left-hand side you will see timestamped events, you should see a current time stamped event - click on that and look in the main window, at the bottom you should see your status message.
Back in the UEM console we need to select a which events will trigger an event notification to our service. Since I want to apply a tag on device enrollment, I will enable device enrollment and hit save.
So now I have my Event notification rule, and it will send an alert to my pipedream service every time a device is enrolled.
Let’s give that a go and see what kind of information is sent to pipedream.
Take your test device and enroll it - I am going to assume if you are reading this type of blog, that we don’t need to walk through the enrollment process - but if you need some help, here is the link to the VMware Docs page for iOS device enrollment
Next up, lets create a new Device tag to apply to the deice on enrollment
If you are interested in reading the docs on Device Tags - check it out here
In the UEM console navigate to Groups & Settings \ All Settings \ Devices & Users \ Advanced \ Tags
Click Create Tag and give your Tag a name - in my case I’m calling it "pipedream" and hit save
while were here, let’s get the Tag ID - the main way to do this via the API, but were going to cheat a bit right click on the new tag we just created and copy the link. Paste that link into a notepad, it should look something like this: https://console.awmdm.com/AirWatch/Tags/Actions/View/1234
the last digits in that URL in this case "1234" is the tag id
We are going to get a few other pieces of information while were still in the UEM console that we will need to allow our pipedream workflow to send the apply tag command back to UEM.
First, we need to generate an API key for us to use.
In the UEM console head to Groups and Settings in the menu bar, then All Settings \ System \ Advanced \ API \ REST API. Click Add and a new row will appear with an API token generated.
Give the service a name and description that will make sense when you look this over later on.
Copy the API key into a note pad for later use and hit save
Next create a new admin account with API access. In the UEM console navigate to Accounts \ Administrators \ List View and Add an admin.
Fill out the Basic tab and the Role tab for this account and make note of the credentials.
Building our app
Now that we finished enrolling our device into our UEM console, an Event notification should have been fired and a message received in our pipedream app. Let’s head over there to check it out.
Open your pipedream window and look for the most recent time stamped event
in the HTTP Webhook trigger section, expand the sted.tigger.event section and then expand the body section. Since we selected to use JSON as the output, we get a nicely formatted message of all the information contained about the device we just enrolled - pretty neat! check it out and get familiar with the fields it shared.
In our case to apply a tag to a device via the UEM API's, I need to know a couple of things, the tag id, which we will got in a previous step, and the Device ID - which you can see in the event notification - hint it’s the "DeviceId" value.
OK - so don’t be overwhelmed, we will break this down but here is the code we are going to use in our node.js workflow step.
const axios = require("axios")
// Make an HTTP POST request using axios
const resp = await axios({
method: "POST",
url: `https://as1.awmdm.com/API/mdm/tags/TagID/adddevices`, //This is your UEM API URL, replace {TagID} with the correct tag id
data: {
"BulkValues": {
"Value": [
steps.trigger.event.body.DeviceId //this is the variable that will grab the device ID send in the Event notification if you followed step by step, this shoudl be correct, if not update to your value
]
}
},
headers: { //the headers to send in the post to the UEM API
'aw-tenant-code': 'UemApiKey', //API key from UEM console - !! DO NOT HARD CODE THESE IN THE FINAL CODE this is educational only!!
'Accept' : 'application/json',
'Content-Type' : 'application/json' },
auth: {
username: 'UemApiAdminUser', //UEM Admin user with API Access - !! DO NOT HARD CODE THESE IN THE FINAL CODE this is educational only!!
password: 'UemApiAdminUserPassword' //UEM Admin User password - !! DO NOT HARD CODE THESE IN THE FINAL CODE this is educational only!!
}})
// Retrieve just the data from the response
const { data } = resp
// export this data for use in a future step
// https://docs.pipedream.com/workflows/steps/#step-exports
this.data = data
OK So what are we looking at the first line is telling node to load the axios http library, this allows us to send a POST http method to our UEM endpoint
The next block is building the POST message, defining the method - “POST" - the URL to send the POST to.
Here we need to make our first update. In place of the "TagID" change it to be the actual tag ID we collected earlier.
For example, instead of being: https://as1.awmdm.com/API/mdm/tags/TagID/adddevices
it should say: https://as1.awmdm.com/API/mdm/tags/12345/adddevices
The data field what the UEM API is expecting to contain the deviceID values. Here we are using a variable to dynamically gather the DeviceID that the UEM console sent to us in the Event notification. This way it will work for all devices as they enroll.
Below that are the headers we want to include with our POST request - and you need to update with your values we collected earlier.
The UEM API expects a few things in the headers of our request:
the API key - defined as aw-tenant-code
Authentication - with node when we define the "auth:" value it will convert the UN/PW combination to base64 for us
Here !! I AM ADMITTEDLY FOLLOWING BAD PRACTICES !! - we are going to hardcode our API key, API user and password into our code. As this is educational at this point, I am OK with that, if this was anything more than that, there are much more secure ways to handle the credentials.
Copy the code upadated with your valies and replace the "Everything is awesome" code in our pipedream editor. Update the values we just reviewed - the TagId, API key, Username and Password
Look for any errors the code editor may flag - tip - sometimes quotation marks get a little mixed up
Save and deploy the code change
Verify
OK so quick recap, at this point we have configued UEM to send a notification from the UEM system to pipedream every-time a device enrolls. That notification contains a number of pieces of device information. Once the notification hits our pipedream endpoint, it moves into the node.js code and gets the deviceID of the device that just enrolled. Once it does that it sends a command back to the UEM console to apply the "pipedream" device tag to the device that just enrolled.
Let's test it out!
Start by deleting your test device from the UEM console.
Bring up your pipedream workflow
Enroll your device again and monitor the UEM console and pipedream console. You should see your device appear in the UEM console, a new event be logged in the pipedream console and if you refresh the uem device list view your tag will be applied.
Have Fun!
OK so as I mentioned just adding a tag on enrollment alone probably isnt much value - but if you got more complex with your node application code, you could apply tags based on a bunch of different things, or differnt UEM events as well. Rather than pointing back at UEM maybe your node code goes to a totally different system! There are tons of options and I would love to hear what you come up with!