Chromebooks can be a surprisingly useful tool in reducing the device management overhead for schools that are standardising on SaaS applications such as Microsoft Office365.
This is mainly due to the fact that Chromebooks handle imaging and updates in a completely different way to traditional Windows clients which traditionally depend on a suite of local software such as WSUS, MDS and SCCM.
The Chromebook model can be a bit of a culture shock for Microsoft admins who are used to managing infrastructure and controlling every aspect of the update process. However once the basic concepts are understood, the initial scepticism is normally replaced with a sense of relief that one of the more tedious elements of desktop management, imaging and updates has at last been fixed.
So from a Microsoft sysadmin’s perspective what are the surprises when working with Chromebooks?
So basically there’s far less hassle and and fewer things that can go wrong from the security and general management perspective. Because Google does all the background work it’s possible for schools and districts to manage hundreds and sometimes thousands of devices without being bogged down by the overhead of imaging and patching and, because it’s a serverless model, hardware dependencies can’t put a break on the deployment.
This is mainly due to the fact that Chromebooks handle imaging and updates in a completely different way to traditional Windows clients which traditionally depend on a suite of local software such as WSUS, MDS and SCCM.
The Chromebook model can be a bit of a culture shock for Microsoft admins who are used to managing infrastructure and controlling every aspect of the update process. However once the basic concepts are understood, the initial scepticism is normally replaced with a sense of relief that one of the more tedious elements of desktop management, imaging and updates has at last been fixed.
So from a Microsoft sysadmin’s perspective what are the surprises when working with Chromebooks?
Surprise One : There’s no image.
Unlike a Windows client the local admin does not build, maintain or deploy a Chromebook image. The work of integrating, patching and regression testing still occurs but that’s all done by the the Google smarts. The local admin only sees a fully formed download. Each Chromebook is delivered from the manufacturer with a running version of the operating system (ChromeOS) which will automatically update to the latest release once the Chromebook connects back to Google. Behind the scenes each version of ChromeOS has a specific image matched to the hardware so everything stays in step with the model of the Chromebook.
Surprise Two : There’s no patch set.
ChromeOS moves forward as a series of minor and major point releases. There is no concept of a security or application patch which is independent of a point release. This system avoids the possibility that a security patch or application upgrade could introduce instability into the system when combined with a specific OS version. For this reason there’s no requirement to invest in auditing tools to provide a patching profile of each client device. If a Chromebook is running version 61.0.3163.101 that’s all you need to know.
Surprise Three; There’s no gold build or extra security requirements.
As an administrator you are committed to move forward on Google's six week release schedule . There are some breaks and controls that you can use to affect the pace of the change but the direction is always forward. It’s not possible to hold on a gold image which remains static for an extended period and because security updates are integral to point releases they can't be side stepped. This ensures that all Chromebook’s are running with the latest security policy rather than an out-of-date set that's vulnerable to current threats. There no requirement to slipstream extra software into the build to protect against viruses and malware which, apart from the benefit of reduced licence costs, just makes things easier and more secure.
Surprise Four; There’s no update scheduling.
There's no Configuration Update message or patching schedule because the update process does not impact on the user experience. The user does not see any spinning graphics, percentage dialogs or delays on boot. Each Chromebook has two copies of ChromeOS that act in a similar way to the “Last Known Good” on a Windows client, although the security model is entirely different. Updates are applied to the passive version of the OS as a background process. Once it’s complete and verified the two versions are swapped on the next power cycle. Because the updates can occur without affecting the running workload and from any location is there’s no real point in attempting to impose a schedule that has to be checked and independently managed.
Surprise Five; There’s no profile management.
Chromebooks can run in an entirely ‘stateless’ manner. Each time a user logs off all personal is removed and the Chromebook returns to exactly the same state it was in before the user session. The user profile that’s delivered from Google is extremely light. User data files can be forced into cloud storage (Google Drive/OneDrive) so moving between devices is a seamless experience. There are however some operational benefits to maintaining a cache of local profiles but even here Google has your back. Each local user profile is protected by an encryption layer that only the owner of the profile can pass through and the Chromebook will automatically purge degraded profiles to free up space in a shared device deployment.
Surprise Six: There’s no requirement for any local infrastructure.
Managing a suite of Chromebooks does not require any local resource and for this reason is an ideal partner for a serverless approach or any strategy built apon SaaS applications such as Microsoft Office356 or Google GSuite. However this exposes one potential weakness in the solution. In a Microsoft environment the on-premises WSUS server acts a cache for downloads and updates but no such facility exists for Chromebooks. So what happens to your internet bandwidth when 500 Chromebooks all decide to update at same time.
Fortunately this situation can be addressed in a number of ways.
First the admin console provides a option to stagger the updates over period up to two weeks so not all the Chromebooks will request the data at the same time. Chromebooks are also capable of updating through a peer-to-peer process although this function has a limited role on more secure wireless networks due to the reliance on mDNS as the discovery mechanism.
The most common solution for large Chromebook deployments is to use an edge security device that has a file transfer proxy function. Updates are one of the few Google functions that can operate outside of the https security envelope so the patch files can be easy cached using software such a Squid. File integrity is maintained by the fact that every update is digitally signed by Google and this signature must be verified before the update is applied.
So basically there’s far less hassle and and fewer things that can go wrong from the security and general management perspective. Because Google does all the background work it’s possible for schools and districts to manage hundreds and sometimes thousands of devices without being bogged down by the overhead of imaging and patching and, because it’s a serverless model, hardware dependencies can’t put a break on the deployment.
Although a Chromebook will never run a local copy of MS Office they make great platforms for thin client deployments using the Citrix Receiver or MS Remote desktop client and of course the MS Office webapps.
Although you still need a Chromebook management licence and a Google GSuite for Education account it's role is reduced to that of an policy management engine for your Chromebooks as there's no actual requirement to take any of the core GSuite services such as GMail, you simply turn them off and replace them with links to Office365 and your SaaS applications.
You can even replace the authentication service with Active Directory by directing the Chromebooks to a local federation service (ADFS) if you have a strong desire to be presented by a familiar logon dialog.
Although you still need a Chromebook management licence and a Google GSuite for Education account it's role is reduced to that of an policy management engine for your Chromebooks as there's no actual requirement to take any of the core GSuite services such as GMail, you simply turn them off and replace them with links to Office365 and your SaaS applications.
You can even replace the authentication service with Active Directory by directing the Chromebooks to a local federation service (ADFS) if you have a strong desire to be presented by a familiar logon dialog.
Even if you're planning a Single Sign-On solution you still need to synchronise user accounts between Active Directory and GSuite for Education but there are tools available to help with this.So as web-based applications become increasingly integrated with MS Office365 there are fewer reasons not to look at Chromebooks as the student device of choice. Try it out, it might be a pleasant surprise
