So, after a year of supporting our enterprise deployed Chromeboxes, it’s probably a good time to gaze back over the year and see what has worked and to admit what hasn’t from an Operational point of view. It’s been a great year for us and Chrome appears to have really picked up too, with some very healthy sales figures. But is it still the right choice? What could (and possibly did) go wrong?

“What could go wrong?” is a real loaded question. After all, if I said this about Windows machines, like the Intel NUC we had considered, this would be a very different article. After all, we know what to expect with a Windows machine (better the enemy you know is a term that was bandied about) – Chrome devices, however, were a dive into the unknown, when we chose to deploy them we didn’t know of any other businesses in the UK who had done so. There have been plenty of education deployments, but nothing too ‘enterprisey’, so we literally went into it blind. We could only trial and test so much before we had to decide to take the plunge.

Eventually we decided to use the Samsung Chromebox Series 3 for our deployment – mainly as it was the only option available to us. Also, a bit of a bug-bear for us, was the switch between the black model and the white model when ordering from Google. We couldn’t dictate which ones we recieved, so the idea of a clincal looking all gloss white equipment set up was quickly dashed as we got one box of the black model and one of the white – and there was no room to switch any around. Not a deal breaker and not an issue with Chrome, but as an Enterprise supplier, Google have some work to do with their hardware provisioning.

So we deployed the Chromeboxes with a little fanfare and got our staff up and running. Initial deployment and training was easy enough – although you will always encounter the odd naysayer, these we’re quickly overshone by our Google Champions (an idea Google themselves suggested). The idea behind the champions is easy,  empower several users throughout the business early on by giving them early access to the new system. Spend time ensuring they’re up to speed and get all the help they could possibly need from your support function. Then, naturally these users will start to champion your cause for you, from within the business. After all, they’ve seen the improvements the new systems have brought and they’ve had the correct training and support to ensure they can then tell others and share their knowledge, making your job as a deployer much easier.

I’ll write another article soon about the deployment itself (and what resistances and issues you may encounter), but for now, lets get back to the task at hand. What are the Chromeboxes like to run Operationally.

So, to give some metrics, here are some headline Chromeified stats:

Total number of deployed Chrome devices: 132

Chrome Device failures (wherein a device ceases function) : 1

Chrome Device failures (wherein a device had to be swapped out and be opened up and repaired, then resumed function): 1

Chrome Device failures (wherein a device required a wipe and rebuild): 22

Total Chrome failures: 24

Now, it is worth pointing out the wipe and rebuild of these devices takes around 15 minutes and is entirely automated – meaning that for 22 devices, it took roughly 6 hours of Tech Ops time to rebuild them all, and during that time, you’re only ever going to be actively working on the unit for 2-3 minutes, so it’s more like an hour of your team’s time, total  – and that’s being generous.

So, before we go too hog wild with analysis, lets compare it to some Windows machine stats, taken over the same time period:

Total Windows devices: 138

Windows device failures (wherein a device ceases function): 2

Windows Device failures (wherein a device had to be swapped out and be opened up and repaired, then resumed function): 3

Windows Device failures (wherein a device required a wipe and rebuild): 14

Total Windows failures: 19

Now, the initial impression here is that the Chrome devices fail more frequently. However, quite often we discovered that our Windows users would encounter an error and attempt to fix the issue themselves, due to the associated time they’d have to wait for a rebuild of a machine, this led to less recorded issues. Chrome users, by comparison, would simply ask for a switch at the first sign of an issue. However, for the sake of fairness, we kept a record of only what we had to fix ourselves.

So, to address that big issue we touched on earlier – time taken fixing issues and rebuilds. Given the 15 minute maximum time to perform a Chrome rebuild versus the 55 minutes to rebuild and re-image a windows machine and get it back into action, we should add up the totals and see where we stand:

Total Technical Operations team time taken up by actively rebuilding or repairing machines (estimated)

Windows: 17 Hours 40 Minutes

Chrome devices: 6 Hours

This is where the Chromeboxes start to shine. Nearly the same amount of devices, but under half the amount of the Tech Op’s team’s time is spent working on them. This is also assuming your staff will sit and watch the Chrome OS rebuild for 15 minutes, as opposed to switching to dev mode, kicking off the process and doing something else important, like having a coffee. Or a beer. With Windows, you can do something similar, but it takes far longer, especially if you’re running rebuilds on a case by case basis for custom machines, like we have.

That’s the real bonus we’ve found by going Chrome – we can now run a very lean and agile support function with only two staff supporting hundreds. If a Chrome devices fails, we pop to the user’s desk, unplug the faulty unit and plug in a new one. Coupled with Google apps and a lack of local storage (hooray for cloud), the user is back up and running in uder 30 seconds. This frees up your support staff to concentrate on the bigger tasks and ensure that time isn’t wasted trying to get a driver working or backing up the 67GB someone’s saved to their hard drive.

With development and product teams becoming more flexible and IT moving towards a more agile and reactive environment, surely it’s wortwhile to make sure your support teams can do it too?

I’ll leave it here for now, but next time I’ll cover common Chrome faults that we’ve encountered and how we’ve dealt with them. After all, the road isn’t always perfect!