Chrome OS in Enterprise – Why companies are pursuing it – Part 2

This is the second in a three-part series on Chrome OS usage in Enterprises. Please find the links for parts one and three below:
Chrome OS in Enterprise – Why companies are pursuing it

Chrome OS in Enterprise – Why companies are pursuing it – Part 3

In the first part of this three-part part series, I outlined what Chrome OS is and how it functions from an architectural perspective. In this post I’ll discuss where the potential Total Cost of Ownership savings exist for companies wishing to pursue a Cloud OS in their environment.

The TCO savings of a Cloud OS model:
There’s a common misconception that the TCO savings of using Chrome OS devices in a commercial setting are due to the typically lower cost of the devices. While device cost does play a factor for EDU (where devices are purchased in bulk, treated quite roughly, and cycled through different owners) it’s not primarily why a business would pursue Chrome OS. In fact, you’ll find that most “Chromebook for Business” devices promoted by Google are priced closer to traditional business laptops ($500-$1,500) rather than Chromebooks sold in the EDU segment ($250-$350).

Google actually provides a Chromebook TCO Calculator for Enterprise to help organizations estimate the cost savings of running Chrome OS in a business, however it doesn’t really drill down into the details of how those savings are realized. I’ll try to do that for you now, at a more technical level. Having provided a summarized view of the unique elements of Chrome OS in the first part of this series, I’ll now outline how those elements can translate into TCO savings for a business.

Headcount Reduction

  • Fewer help desk calls related to OS
    • Pretty straightforward story here. With a simplified OS experience, where the OS moves closer to merely being a bootloader for your applications and data, you will inherently have fewer issues with it. As any good IT Professional knows, complexity equals risk. This translates to fewer end-user training needs and fewer IT tickets being created.
  • No BSoD, memory leaks, etc.
    • Similar to above, except this relates to the power granted to applications and drivers in a traditional Windows OS compared to Chrome OS. An app does not have access to the underlying core system resources therefore it cannot crash the entire system. Blue Screens of Death and memory leaks are still a high causes of Windows OS stability issues, and therefore IT support costs.
  • Fewer OS/Driver image testing & validation tasks required
    • With Chrome OS there is no such thing as a “company build” of the OS image deployed to the device. There is only ever the factory image owned by Google and laid onto the device by the OEM. With a “Cloud OS Usage Model” there is no need to add company applications, device drivers, agents, or other content to the OS. You merely need to enroll the device into the Google Admin console and all browser extensions and Android apps are pushed over the air, representing a relatively small data payload (typically less than 100 MB but rarely over 500 MB). The idea here is that in a Cloud OS usage model, users are accessing their applications either via a browser or some kind of Android App (EX: Horizon Client, Citrix Receiver, etc.). This means IT resources are not required to validate OS images or deploy them onto the devices (either from the OEM or in a support scenario).
  • Improved user productivity as they are ready to work at login, with less reliance upon added technology or services
    • As the above indicates, because a user isn’t relying upon a corporate image or set of installed applications to do their job, they merely need to login with corporate credentials to an enrolled Chrome OS device and they’ll have the tools needed to do be productive. This creates a seamless experience for end-users, who can almost instantly be productive not only on their own device, but any corporate device. This reduction in onboarding friction and added flexibility results in increased productivity. Also, there’s a story here even for non-enrolled personal devices. While users may not get all their settings, Chrome extensions, or Android apps automatically pushed via policy after login, there’s nothing preventing them from logging into their personal Chromebook with their personal Google Account and manually downloading their preferred company Android apps (Outlook for Android, Boxer, Workspace One, Citrix Receiver, Horizon Client, etc.) or merely browsing to their Gmail or Outlook on the Web (OWA) website to begin doing work. Personal Google Accounts work similarly to corporate accounts, in the sense that most settings and apps follow your account. Therefore, in either scenario the experience is that users are no longer tied to a particular HW device but instead to an identity (user account).
    • Faster boot. Architecturally, the system brings you to a ready-to-work state significantly faster than a traditional PC. It also offers a better user experience when waking from sleep states or periods of inactivity. This video from Google outlines the key differences in Chrome OS from the traditional experience, from which the below image was taken:



  • Shared device usage models become more technically feasible
    • Shift workers or loaner devices become prime use cases for the cloud OS usage model. Google really promotes the shift worker and loaner scenarios in their TCO calculations, as they should. Their OS makes each model extremely easy to implement. The devices don’t require special OS preparation or sanitization before shared use. As I indicated in my previous post in this series, each user profile on a Chrome OS device is completely isolated from each other (via encryption and sandboxing), meaning users need not fear their data be exposed to other users on the system (however, in a true cloud OS model, little to nothing would even be stored locally on the device itself). Should a device become corrupted or need to be repurposed, a simple Powerwash removes all user accounts from the system while keeping the base OS intact. No reimage or redeployment needed.
    • As no image/driver validation is needed for a particular HW platform, procurement becomes somewhat easier. Companies become less concerned about standardization from a technical perspective and more so from an end-user experience perspective. Screen size, touchpad, & keyboard become key drivers for decision making, not necessarily the system’s horsepower or chipset.
  • Performance requirements shift closer to that of thin clients
    • This one is pretty well known in the Chrome OS world, and the greater Linux-based OS world. Chrome OS simply requires fewer system resources to function in an acceptable manner compared to Windows 10. Now I understand this is partly because you won’t have W32 applications installed, but you also won’t have things like Anti-Virus or multiple systems management agents taking up precious system resources. Time will tell what additional features Google will add into the OS, including expanded containerization support (Crostini) enabling Linux application usage. These could certainly add resource requirements to the OS, but I personally believe Google knows this is a line that has to be walked carefully. Currently though, Chrome OS devices require fewer resources than their Windows counterparts even when both are used in a cloud OS model (EX: Using only browser or UWP apps on Windows).
  • Flexible usage as both a work and personal device
    • Assuming a business chooses to not disable this capability via the Google Admin console, end-users can logoff of their enrolled devices after a day of work and login to them with their personal Google Account for use on their own time. Due to the architecture of the OS, this personal profile would be completely shielded from corporate visibility. This means installed apps, local files, and Chrome browser history are not made available to anyone but the end-user. However, be aware that Device Policies will still apply. This provides flexibility to end users as well as to companies wishing to pursue BYOD.


  • Centralization of applications and data into the cloud allows focus on Identity/Access management
    • As less compute and investments occur on the endpoint devices, organizations can instead invest in securing access to their applications and data. This is true whether those applications and data exist in a public cloud or private cloud. Time can be better spent implementing safeguards such as multi-factor auth or location-based device access rules. Companies who have transitioned to cloud services such as Azure AD, Office 365, or G Suite have already realized this benefit. Enabling multi-factor auth in a legacy on-premises environment with Active Directory, Exchange, SharePoint, & Skype4Business could be a very tedious process. You have to ensure each server component can support it. However, when using Azure AD & Office 365, enabling multi-factor auth is essentially as simple as a button click in your admin console. This is a great example of how a cloud-oriented operational model offers greater security through centralized consolidation of your directory, applications, and data. It’s been a key driver of cloud adoption over the past decade, and operating systems built for the cloud are inherently more capable of taking advantage of this operating model; as they themselves rely more on the cloud for applications and data and require less administration. The net effect of this shift is that organizations can focus less on mundane operational tasks and more on transformative and security-oriented tasks.
  • On-the-box investments shift from Anti-V and systems management agents to cloud content management
    • As Chrome OS endpoint devices do not require Anti-Virus or systems management agents, investments shift towards solutions focusing on the encryption and securing of the content end-users are accessing in the cloud (EX: CASB solutions, Content Encryption solutions, etc.) and away from deploying and managing multiple on-the-box agents.
    • As there are no on-the-box management agents for Chrome OS (as all management is natively performed via Google Admin Console enrollment), UEM solutions instead integrate with Google’s Admin Console via APIs. This makes deployment of UEM in a Chrome OS environment more seamless and removes the need to keep said agents up-to-date. Notice within the VMware Workspace One Chrome OS deployment guide, there’s no section for actually deploying an on-the-box agent; it’s simply not needed.


Centralized IT Spending

  • Legacy/W32 applications shift from on-the-box to SaaS or private cloud
    • From the Chrome OS device, products such as Office 365, G Suite, Citrix, Horizon are either accessed via the web or via an Android app. However, all server-side elements are centrally located either in someone else’s cloud (EX: Microsoft, Google, etc.) or in a customer’s private cloud (EX: Citrix Farm). The industry has long realized when you’re either paying someone else to handle your IT operations, or reducing your number of internal touchpoints via a private cloud, there are significant benefits. A cloud OS model assumes your organization is shifting more towards SaaS or private cloud hosting of applications, rather than many instances of applications running on each client machine. This model provides added security when you consider the time and effort involved in patching security vulnerabilities on endpoint devices. The more centralized you can make your software, the easier it becomes to remediate when a day-zero attack is discovered. At the OS level in particular, Chrome OS consolidates all OS, App, Driver, Firmware, & BIOS updates into a single over-the-air update stream, meaning patching becomes significantly more streamlined.
  • OS image management/deployment shifts to cloud policy-based
    • In the Chrome OS Enterprise model, there is no need for factory deployment of a custom OS image. Nor is there a need for Internal IT staff to image the system or deploy applications before the devices reach the end-users. The devices need only be enrolled into Google’s Admin Console to allow all needed apps and settings to be pushed over-the-air at user login. Enrollment is a fairly straightforward process explained in the link provided above. It merely requires credentials for an account with Enrollment permissions and a Chrome Enterprise License to be available within the Google Admin Console. School districts and companies pay OEMs or service providers to enroll the devices for them en masse. However, Zero Touch Enrollment is available from Google today for Android devices, meaning this same capability could one day come to Chrome OS as well. This could be compared to Windows Autopilot today.

In the third and final part of this series, I’ll discuss what I feel customers actually care about in regards to their endpoint device operating systems (Spoiler: They don’t hold any religion around the OS itself and just care about getting work done). I’ll also share what has been publicly discussed around Microsoft’s rumored “Cloud OS”.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: