Hey CloudReady fans!

On Tuesday the 24th, we held a webinar featuring two guests from Florida's Lee County Public Schools: Dwayne Alton, Lee's Executive Director of Infrastructure Services, and Jerry Christmas, Systems Engineer.

Dwayne and Jerry spoke during the session about the background, processes, and lessons learned from their district switching to the Google ecosystem, including G Suite, Chromebooks, and CloudReady. You can find the session available now as an on-demand webinar here.

During the session Q&A, we encountered some audio challenges with the last two questions, so we've transcribed that portion here for you:

Q: What do you feel is good enough, as well as suggested, internet bandwidth for deploying Chromebooks and CloudReady?

A: So let’s put it this way - for our high schools, which hover around 2000 students, we have 1GB for those. Our middle schools have 500 MB to them and they hover around typically around 1200 students - and keeping in mind that we’re not using digital textbooks - we’re actually using interactive digital objects and videos and things like that, so we deliver some pretty heavy content over that. Our internet bandwidth right now is 16 GB, it’s two redundant 8 GB lines. We did increase our bandwidth with the implementation, however a lot of people think that if you use Google rather than Windows that your bandwidth utilization is going to be higher because everything is “in the cloud.” In reality, there is actually not a big difference between what we were seeing with on-prem Windows machines and the cloud traffic for Google Docs. Google Docs saves continuously while you’re typing. Microsoft saves files in larger chunks. So the transition from Windows to Chrome was handled with the bandwidth we had already roadmapped for upgrades anyway. We didn’t do anything special for Chrome. Of course if you’re in a rural area and you’re saying 16 GB, that is special, I understand. 

Q: Can you talk about how you’re doing Web content filtering, and are you doing SSL inspection?

A: So the answer to the first one is we’re using GoGuardian for our Chrome devices, and GoGuardian has two components: one is filtering, which is called GoGuardian for Administrators, and the other one is GoGuardian for Teachers, which is a classroom management tool where they can see the students’ screens, kill the background tabs when the students are not on task, and add their own rules to what the students can do. We implemented those two solutions - it’s actually one product, but two pieces. As far as SSL inspection, it’s a little bit different way of looking at it. It’s not like a traditional perimeter appliance where you’re doing a man-in-the-middle attack and installing your own certificates and decrypting the traffic and inspecting them. We see all SSL traffic, not just the traffic for the specific sites where we’ve pushed “trusted” certificates. The other benefit is that we see what the user intended to go to, not where they ended up. A lot of the solutions show you destinations, I see what they’re trying to get to. I’ll give you an example where that’s useful. If you have SSL decryption turned on and you happen to catch that they’re going somewhere inappropriate, you might see - oh, they’re going to a proxy site. For us, we see what they’re looking at through the proxy site. So, having the agent on the device to see the traffic before it even hits the tunnel is beneficial. For the Chrome world, your two probably biggest leaders would be GoGuardian and Lightspeed; both use similar methodology for the Chrome devices. And what I really like is that they are human-readable reports. So the way we do it is to delegate the review to the schools. Whether it was blocked sites or they were getting through to something inappropriate, the AI system sees that and flags it for the school directly so the IT department doesn’t have to do all the investigation.

Our thanks to Dwayne and Jerry for taking the time to join us on the webinar!

Comment