I have been spending the last few weeks trying to perfect a new fringe technology from our friends at VMware with Chromebook Management. It’s certainly an interesting experience to share. It makes a ton of sense that it is picking up so much speed on the education side because it’s incredibly challenging to make the magic happen. Let’s walk through the setup on both ends and share some of the good and the bad.

Why Chromebooks?

I think we often ask a simple question whenever analyzing a new technology: WHY OH WHY?! Chromebooks buy you a few nice things overall: (1) Simplicity and (2) Cost Savings. We typically see Chromebooks in the education space but it is picking up speed elsewhere. On average you can spend roughly $200-$500 for a Chromebook with some super high end versions that are just over $1k. Some of the types of people that I think Chromebooks have value for are:

• Non-technical people
• Older People
• Education
• Shared Devices
• Developers or other potential VDI use cases

Setting up your ChromeOS Integration

The hardest part about the entire thing is getting the Chrome Administrator Portal ready to go. We will go through setting up the API, Google Console, and UEM Console.

Setting up API Access for Chrome Enterprise

We start by going to the Google Developer Console and setting up the API access, which is a bit challenging overall but the documentation on setting this up isn’t super strong. I figured out by slapping various random things together. Below, you will see a video walkthrough on setting things up on the Developer Console.

Configuring the ChromeOS Console for Workspace ONE Integration

Once you have set everything up, you will be ready to start configuring the Chrome console side, which will be mostly painless. We can look more at the video to show how to setup the OAuth scopes and such.

As promised, below you will find a list of the OAuth scopes that you need for this to work correctly:

https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/admin.directory.user.alias.readonly
https://www.googleapis.com/auth/admin.directory.user.alias
https://www.googleapis.com/auth/admin.directory.user
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/admin.directory.group.member
https://www.googleapis.com/auth/admin.directory.group

I found a few articles are particularly helpful if you need additional references on getting the integration setup:

• WS1 Docs on ChromeOS Setup
• Chrome Setup with 3rd Party EMMs

Configuring the Workspace ONE UEM Integration

The setup is pretty easy so I won’t do any sort of video, but just explain it quickly. The main key is that you can only do it from the top of your WS1 UEM environment. You simply go to Devices & Users > Chrome OS > Chrome OS EMM Registration and input your domain and Google admin email address and click “Register with Google:

That brings you to a Google login, which will give you an authorization code that you put in and authorize to complete your integration.

Chromebook Mass Deployment

Chromebook mass deployment strategies deserve some major discussion because it’s pretty challenging. As you can read about here, you have several ways of deploying Chromebooks essentially using technologies that tap the keys for you. I will highlight the top two and give you a script to make the magic happen.

USB Rubber Ducky Deployment for Chromebooks

The USB Rubber Ducky is a very user-friendly product. The main issue is that they cost $50 a piece, which means you are talking about roughly $500 of USB sticks for deploying your devices. The main benefit and why its the gold standard is the code is relatively easy to write. The commands are VERY pseudocode-like.

You can access my working code for Chrome 85, which presumes a Workspace ONE UEM deployment using Workspace ONE Access. You can find that code here. An example of what ducky looks like can be seen below.

DELAY 1000

ALT-SHIFT S

DELAY 1000

TAB

TAB

TAB

I also suggest watching the video that I made showing what a Rubber Ducky deployment looks like.

Centipede Deployment for Chromebooks

Personally, I find Centipede to be a bit more palatable since they’re $10 per USB stick, but the challenge is that the code is much more challenging to write. You will find a functional Centipede script here for Chrome 85, but as you will see below the code can be a bit tricky.

void setup()

{

  setPrescaler(); // Set prescaler to highest clock speed

  Keyboard.begin(); // Start they keyboard emulator

  pinMode(buttonPin, INPUT);  // Set up the debugging pin. If you want to debug the code, use a length of wire to connect pins 2 and GND on the board

  digitalWrite(buttonPin, HIGH);

 

  pinMode(RXLED, OUTPUT); // Configure the on-board LED

  digitalWrite(RXLED, LOW);

  TXLED1;

  if (digitalRead(buttonPin) == 0) {

    showSuccess();

  }

  wait(5); // Wait for all services to finish loading

}

A few other things that I love about Centipede is that it supports variables, which is VERY helpful and it has some built-in functions to nuke your staging Wi-Fi settings to name a few. The main problem is your admins are going to likely struggle keeping the code updated with iterations of Chrome thus creating a support headache.

Final Thoughts

Some things that we don’t touch on a ton is the supportability of ChromeOS via Workspace ONE UEM. It’s a challenge considering when you create profiles it’s actually just sending API commands to the Google APIs. It’s great to have a single-pane-of-glass approach to your device fleet, but there is much lacking today. You can build some great user experiences with the right combination of process and technology making Chromebooks a viable option at your organization.