Lessons learned on the digital workspace journey with Workspace ONE

API's in Workspace ONE UEM continue to be a popular topic when working with clients. API's allow you to integrate other products and services; while also giving you the flexibility to build your own toolsets if needed. Treating enterprise configurations as source code is one challenge I have been working on lately, and in this blog post we will look at creating Android profiles with the appropriate configuration with Workspace ONE UEM API's. HTTP Verb Workspace ONE UEM API Endpoint GET /profiles/{profileId} POST /profiles/platforms/android/create The table above lists the HTTP verb and API endpoints being used in this example. If you have a development, user acceptance testing and production environment; you could capture the configuration used in development. Then post the configuration to the API endpoint in UAT and production. This should reduce mistakes when committing your changes, and allow you to store your con

Using API's has been infinitely helpful in integrating Workspace ONE UEM with other enterprise services and applications. A question was asked recently about forming the correct HTTP header using Powershell, and returning the users in the users. Below is an example Powershell script I was able to create for this example. Make sure to include base64 encoded credentials in a folder (c:\creds\b64.txt in the example), and to update the $apiKey variable with an API key. #Workspace ONE UEM Environment Address / Authentication  $addy   =   "https://ws1.molokaibank.com" $b64   =   Get-Content   -Path   "c:\creds\b64.txt" $apiKey   =   "apikey" $b64EncodedAuth   =   " $b64 " # Header $content   =   "application/json"   $authHeader   =   "Basic "   +   $b64EncodedAuth $header   =  @{ "Authorization"   =   $authHeader ;  "aw-tenant-code"   =   $apiKey ;  "Accept"   =   $content ; 

--> Product provisioning in Workspace ONE UEM is an incredibly useful feature. We are often able to deliver resources or manage a device without the use of product provisioning, but there will be use cases that require additional capabilities. Product provisioning allows for actions to be defined in a product manifest, with actions being completed in a sequential order. These actions can be placed in the correct order to achieve the required outcome. If there is a failure in a step, the delivery will stop at the step that failed. The success or failure of each action can be logged for auditing or troubleshooting. Optionally, debug mode can be used to identify root causes remotely. Debug mode level can be turned on by organization group, allowing large groups of devices to have results recorded, or on individual endpoints.  One action that I have become very familiar with is remotely delivering an intent to an activity in my Android application. The abilit

Ad revenue from this blog will be donated to  Kalamazoo Loaves and Fishes , a non-profit in Kalamazoo, MI. This blog is to share lessons learned along the digital workspace journey. Disclaimer: To avoid potential liability, there is no guarantee in the methods documented. Each use case is unique to its design, architecture, and configuration.  You must always test and validate.  Posts and viewpoints are my own, and do not represent the views of any company. Mahalo, Ryan Pringnitz