In the services industry, we sometimes run into “fun.” One of these “fun” situations is when someone rolls out a platform. They may have used VMware Professional Services or attempted it on their own and something wasn’t considered. I recently ran into one of these situations and sadly VMware Support told them “You can’t do that” or “you have to re-enroll EVERYONE.” We now have a gateway of empowerment in the Workspace ONE API.

Let’s forget the idea that this is REALLY bad. Let’s focus on from a technical perspective that telling someone to start over from scratch just isn’t the best situation for anyone. This client, which honestly is one of the nicest groups of people was really in a bind. This is a great case study of being told no, and turning it into a maybe?! Today, we are going to go over the issue, show how we solved it with the Workspace ONE API, and share out the code as a reminder. Never let any vendor or anyone for that matter box you into a corner.

The Problem

When we look at Workspace ONE UEM rollout methodologies, staging accounts are a fairly common scenario for corporate-owned devices.

You build your DEP profile (which is a topic I have covered before) and you disable authentication, you typically setup a section that looks like this (I know this is for automated enrollment, but it’s basically the same idea) or YOU might have used automated enrollment. Most of the ideas and concepts are a big problem.

It’s not a completely uncommon issue but is one that can cause major problems for users. The end result is hundreds if not thousands of devices that are enrolled to the same account.

Now, if you reach out to VMware Support (like my client did), they will likely tell you that you have to re-enroll everyone!

Is There a Solution?

The underlying issue is that you now have a device enrolled as a staging account of some sort. This can be problematic in general because you lose your ability to personalize. Before, discussing the solution. Let’s introduce ourselves to the API documentation aka https://as1688.awmdm.com/API/help (This exists on every tenant).

This interactive documentation site lets you search for terms and open directly into API commands, which I use fairly regularly when trying to figure out an issue. I teach young engineers to do this all of the time:

I’ve written about using the APIs in the past. I’m a huge supporter of it and what I am here to tell you today is that YES you can fix this customer issue with the API and not just RE-ENROLL everyone like they were told. We should never accept at base value what any vendor tells us. Pushing the envelope and digging deeper is the difference between an administrator and an engineer. Let’s get into the code of my solution that I wrote for them.

Examining my New Workspace ONE Device Migration API Tool

The first part of my API tool that we will look at is the authentication into the API, which is really the best place to start.

Authenticating to the Workspace ONE API

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$Username = Read-Host -Prompt 'Enter the Username'
    $Password = Read-Host -Prompt 'Enter the Password' -AsSecureString
    $apikey = Read-Host -Prompt 'Enter the API Key'

    #Convert the Password
    $BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($Password)
    $UnsecurePassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)

    #Base64 Encode AW Username and Password
    $combined = $Username + ":" + $UnsecurePassword
    $encoding = [System.Text.Encoding]::ASCII.GetBytes($combined)
    $cred = [Convert]::ToBase64String($encoding)
    $script:header = @{
    "Authorization"  = "Basic $cred";
    "aw-tenant-code" = $apikey;
    "Content-Type"   = "application/json";}

##Prompt for the API hostname##
$apihost = Read-Host -Prompt 'Enter your API server hostname'

This piece of code does a few things:

• We will use TLS 1.2
• What is your username, password, and API key?
• Creates your authorization header
• Collects the API server name

Once we finish that portion, we can now move onto doing some real work!

Capturing Data to Migrate a Device

Once we have built our headers, we can start asking the administrator some questions to set the stage for the migration:

##Prompt for the serial number##
$serialnumber = Read-Host -Prompt 'Enter the serial number for the device you want to migrate'

##Prompt for the Username you want to migrate to##

$username = Read-Host -Prompt 'Enter the username for the device you want to migrate'

##Get the Device ID with the Serial Number##

$deviceresults = Invoke-RestMethod -Headers $header -method Get "https://$apihost/API/mdm/devices?searchby=SerialNumber&id=$serialnumber"
$deviceid = $deviceresults.id.value

##Get the User ID##
$userresults = Invoke-RestMethod -headers $header -Uri "https://$apihost/API/system/users/search?username=$username"
$userid = $userresults.users.id.value

This code does a few things also:

• Prompts for the serial number of the device
• Prompts for the username that we are moving the device to
• Uses the serial number to get the device ID (unique identifier of the device) and user ID (unique identifier of the user)

The Migration Begins!

Now that we have all of the information that we need, we can start to migrate devices!

##Migrate the Device##
Invoke-RestMethod -Headers $header -method Patch https://$apihost/API/mdm/devices/$deviceid/enrollmentuser/$userid
##Query and Sync Device##

Invoke-Restmethod -Method Post -Uri "https://$apihost/api/mdm/devices/$deviceid/commands?command=SyncDevice" -ContentType "application/json" -Header $header
Invoke-Restmethod -Method Post -Uri "https://$apihost/api/mdm/devices/$deviceid/commands?command=DeviceQuery" -ContentType "application/json" -Header $header
##Sync VPP Assets when Finished##

$groupid = Read-Host -Prompt 'Enter the Group ID where your VPP is Setup'
Invoke-RestMethod -Headers $header -method Put https://$apihost/API/mam/apps/purchased/VppSyncAssets/$groupid

So what does this do?!

• It runs a command to re-assign the enrollment user of the device to the username you specified
• Forces the device to check-in and sync
• Re-synchronizes VPP Assets (this was determined to be required after a ton of testing).

The full script can be found here

Final Thoughts

I basically hit on my points throughout the article. Sometimes people go off what they think they know but aren’t always 100%. With all of our vendors, it should always be trust but verify. The entire point of an API is to push the limits and to do things you cannot do through normal methods. The API is a whole new world for us now. A little bit of effort and creativity can save you hundreds of hours of effort.