SSHGuard

If you run any Unix-like systems, you probably know that the bad guys are trying to break into your server over SSH. You can use fail2ban or sshguard to greatly reduce the chances of a break-in. Below, I show how I setup sshguard on my FreeBSD servers. Its quick and relatively easy, so I consider it a requirement for all of my FreeBSD servers.

First, install sshguard from the ports collection:

cd /usr/ports/security/sshguard
make install

Next, tell FreeBSD to allow it to start by adding this line to /etc/rc.conf:

sshguard_enable="YES"

Then start it and stop it. This will create a configuration file that we'll use.

service sshguard start
service sshguard stop

Now the file /usr/local/etc/sshguard.whitelist should exist. Edit that and add any IP addresses that you might need to whitelist. For example, I whitelisted my network monitor. My reasoning was that it would test if the SSH service was still running every 60 seconds. So this would look like a break-in attempt and the monitor would be blocked after a few minutes.

You might also wish to whitelist certain other hosts, but I don't recommend whitelisting everything in your internal network. If someone did manage to break into your web server or some other system, they could then use "island hopping" to get to this host and break into it, too. So sshguard makes that harder on the attacker.

To add items to the whitelist, just add one IP address or FQDN per line. If you want to insert a comment, you can start the line with a "#" and then write your comment. I highly recommend putting a comment just above every entry. A few years from now, after an IP address is assigned to a different server, you might not remember why it is in your whitelist. Comments can help your future self save time.

Now just start the service back up with this:

service sshguard start

To confirm that it's running, try this:

service sshguard status

That is all it takes. If sshguard sees a suspicious attempt to login, it will add the IP address to the top of /etc/hosts.allow as a "deny" rule. It will take care of things all by itself from now on.

If you find that it blocked an IP by mistake, you can remove the block by just removing its IP from the hosts.allow file. Just be sure that you can really trust that IP. Maybe someone put a rootkit or bot on that host and sshguard is doing exactly what it should be doing. So be confident that its an error before removing the IP.

A few last notes: First, sshguard will log some data in /var/db/sshguard/blacklist.db. As far as I can tell, this is more or less just a log. I think sshguard uses it at startup time, but I'm not sure. If you need to remove the blacklisting from an IP, edit /etc/hosts.allow instead.

Second, there are a few different ways to setup sshguard. One of them involves piping data from syslog into sshguard. Others involve using PF or IPFW instead of hosts.allow. I haven't used those option and don't know the relative advantages and disadvantages of each method. What I've presented here is what works for me. Please feel free to research the options further and do what works for you. If you know why I should consider another method, please leave a comment on this article. I would truly appreciate the advice.

Lastly, don't forget that this is looking for persistent failed logins from a single IP. Advanced Persistent Threats can use botnets to try out one or two passwords from an IP and then one or two from another IP and so on. Patient attackers might also try one or two passwords every few hours until they guess right. People who know you or looked at the password list you keep under your keyboard are much less likely to be stopped by sshguard. The bottom line is simple: sshguard helps reduce risk but security is a mindset and not something any single product can give you. Be smart and be safe out there.

Software License Enforcement

So you manage a few hundred or maybe a few thousand computers. What do you do when it's time to buy software? If you buy too many copies, you wasted money. Too few copies means you're vulnerable to an expensive lawsuit. How do you ensure that you're in compliance and not wasting money?

I solved this problem about a decade ago and sometimes forget that others still face this challenge. If you're one of them, this article was written for you.

If you find yourself in this situation, I highly recommend having a conversation with the folks over at Sassafras Software about their K2 (a.k.a. KeyServer) product. I've been a happy customer for years.

Their customer support is knowledgeable, thorough, and friendly. I've never been on hold for more than 2 minutes or so. In fact, it is kind of like calling a buddy for advice -- no customer number to remember or case number to track. You just get through to them and start talking about your situation.

The product itself is great. You can install it on Windows or MacOS quite easily. I even did an automated install to hundreds of Macs via FileWave without problems. (This should work on Munki, Casper, etc. as well.) This customized installer is already configured with my KeyServer's address, so it connects as soon as it is installed. The computer then shows up in a list of monitored computers. As end users run programs, those programs are added to a list of "discovered" software. You can also add purchases, products, computers, and policies manually.

Here is a recent real-world example from my job. We purchased 500 installations of Microsoft Office 2016 for Mac. I told KeyServer that we had a new product and it checked in with Sassafras about what constituted "Office 2016" and set up some criteria for me. For example, if the user runs OneNote 2016, that computer is considered to have a license to Office 2016. So it is entitled to run Word, Excel, PowerPoint, and Outlook as well. Another computer might run Word 2008, but K2 knows that is a different version and doesn't count it as Office 2016.

Then I told it that we had purchased Office 2016 and filled out a form telling KeyServer it was 500 units of single-computer installations, that it was an original license and not an upgrade license, what it cost, my organization's purchase order number, that it didn't expire (i.e. that it wasn't a subscription,) etc. This is great data for tracking the licenses during a future audit. I could pull up a list of every time we purchased this product, how many "seats" we bought, which purchase orders to pull out as proof for the lawyers, and so on. It also helps calculate costs for supporting different products in the future. These kinds of hard numbers can help you make calculations and drive discussions about maintaining products in the future.

Lastly, and perhaps most importantly, KeyServer will let you choose how to monitor the license usage. It can passively track installations, track frequency of usage, or even enforce licensing. In the previous example, I configured it to allow the first 500 Macs to run Office 2016 to be automatically registered as users of it. After that, the 501st Mac to try to run that particular version of Office would receive a message saying that they weren't licensed to use it. So if someone was "helping out" and installed it when they shouldn't, that would turn up rather quickly. We could then choose to buy additional licenses or have a conversation about who really needs the software. If it turns out that one of the 500 to grab the license automatically shouldn't have it, we could withdraw that license and assign it to someone else. Next year, when computers are replaced, I can move the licenses around. A few years later, when the next version of Office is released, I could run a report to see how many computers actually used the software and factor that into future buying decisions.

There are a lot of features and situations that I didn't cover in this example. My point was just to show how K2 can make many common situations much easier. Given what we pay on it compared to the manpower (and the salary) wasted on walking around doing manual audits, I think K2 is a huge time and money saver. It saves even more time and money if you use the utilization reports to find licenses to move around or drive budgeting of upgrades.

If you manage a few hundred Windows PCs or Macs, I highly recommend a look into what Sassafras Software could do to help you.

SFTP Connections from PowerSchool

At my job, we store student data in a program called PowerSchool. One of PowerSchool's features is AutoSend. AutoSend can make a text file full of data and send it to another computer over SFTP. This is very useful, as it allows student data to be entered once (in PowerSchool) but appear in many systems.

Recently, I replaced and updated the FreeBSD system that runs our SFTP server. After the upgrade, PowerSchool couldn't send data to the FreeBSD SFTP server. Other SFTP programs, such as FileZilla, were able. This issue only seemed to affect PowerSchool's AutoSend. I couldn't figure it out at first. The FreeBSD community couldn't. Our tech support couldn't. They escalated the issue over and over until it reached "engineering" and I never heard back from engineering.

After working on this on-and-off through the summer and eventually found a way to make it work. Since it took me so long and confused so many other people, I wanted to put this out there for others to benefit.

The short version is this: I had to change the default settings of the SSH server.

This may sound strange to some, but SFTP on many Unix systems -- such as FreeBSD and Linux -- is based on OpenSSH. OpenSSH is a system that is all about making encrypted connections and preventing the bad guys from seeing what you're transmitting. However, its default settings moved to a more strict standard at some point and this was why I saw a difference between the old FreeBSD server and the new one.

The setting in question deals with how OpenSSH handles authentication. In plainer language, it's all about the login process. It seems that "keyboard-interactive" is the mode used by programs that interact with humans, such as FileZilla. However, "password authentication" is the kind used by automated systems, such as PowerSchool. Personally, I found the name "password authentication" to be confusing for a while, but that is what it is called.

So I edited /etc/ssh/sshd_config to allow the password authentication system. However, the OpenSSH developers disabled it for a reason. They know more about computer security than I do, so I struck a compromise. I changed the settings so that password authentication was valid if and only if the connection came from my PowerSchool server.

If you need to do this, just find your system's copy of sshd_config and add the following lines to the bottom of the file. If you have any lines beginning with "Match", this should go immediately above those.

# Turn off PasswordAuthentication in general, i.e. without a Match statement to change it.
PasswordAuthentication no
# Allow only the IP address of the PowerSchool server to use the
# PasswordAuthentication directive. Note the "PasswordAuthentication no" 
# above all Match statements.  That is part of this configuration, but 
# must be before any Match blocks.
Match Address 999.999.999.999/32
        PasswordAuthentication yes

You should change "999.999.999.999" to the IP address of your PowerSchool server. Everything else should be fine exactly as I wrote it above.

Free Chromebook Inventory Tool

If you manage chromebooks (or other ChromeOS devices) in a Google Apps for Education or Google Apps for Work system, you need this tool.

The Chromebook Inventory Add-On for Google Sheets allows you to quickly make a spreasheet of your managed chromebooks. You can then edits the spreadsheet and export it back to the Google servers. When the export is done, it will update those settings. This makes it a convenient tool to do bulk updates, move large numbers of chromebooks to a new OU, make inventory files, or make checklists.

I couldn't explain this system any better than the seven minute long video that they provide. So just check that out.

Restarting snmpd on MacOS X Server

Recently, I needed to update the SNMP settings on some old MacOS X file servers that I was monitoring. There was no GUI to change the SNMP settings on those, only to start and stop it. Since I was using the command line to reconfigure lots of other servers and switches, I didn't want to resort to the GUI just to restart the SNMP process on these Mac servers. This is what I ended up doing.

First, I made a new snmpd.conf file the Mac in the usual way.

sudo snmpconf

Then I put the new file into place and restarted the snmpd process.

sudo cp snmpd.conf /usr/share/snmp/snmpd.conf
launchctl stop org.net-snmp.snmpd

Technically, that only stopped the process. However, the org.net-snmp.snmpd.plist configuration file states that snmpd should always be running. So the launchd process in MacOS just starts it back up when it sees that it isn't running. It happens so quickly that a "stop" command is practically a restart in this case.

Its worth noting that these are older file servers running MacOS X Server 10.6.8. I don't know if the launchctl command would be the same in newer versions.

FreeBSD Updates (Semi-)Automatically

Keeping servers up to date with security patches is a challenging task. No one likes server outages, upgrades could break things, etc. This is what I do on FreeBSD systems to safely manage updates.

First, login as root. Then make sure that /etc/aliases is configured to forward root's email to your email address. This makes sure that you get the notifications of updates. It will also cause you to get nightly, weekly, and monthly updates about important things like how full the hard drives are and if any of the installed ports or packages have known security bugs. Once /etc/aliases is updated, type "newaliases" to activate the changes. Then email root to see if it worked.

Then, add this to /etc/crontab. (Note: Press "Tab" five times between "@daily" and "root".)

# Get OS updates every day
@daily                      root    freebsd-update cron

This will make the system check every night for important upgrades. If there are any, it will download them to a staging area and not install them. Instead, it will email you a list of the pending changes. This email will only happen when there are recommended updates to install, so you won't see it every day.

That is all the setup work. Now just wait for an email about a pending upgrade.

When you get one of these messages, read it over to make sure it wouldn't affect anything that you've customized. If it would, you might want to take a closer look at that system to put your mind at ease.

When you're ready to activate the upgrade, login as root again and type this:

freebsd-update install
shutdown -r now

This will cause it to install the pending updates and restart. If everything goes as planned, you're all set. Really. That is it.

If anything doesn't go to your liking, you can revert to the pre-update system by logging in as root and typing:

freebsd-update rollback
shutdown -r now

If the FreeBSD system is running as a virtual server in VMware, Digital Ocean, etc., then you may wish to make a snapshot of the server right before the "freebsd-update install" command. That gives a very convenient way to roll back to pre-update conditions. I haven't heard of anyone breaking their system with freebsd-update before, so this is really just an extra precaution more than a necessity. With servers, its always nice to have extra backups.

By keeping on top of updates regularly with a (mostly) automated system like this, your servers will be more secure, more trustworthy, and more stable. More importantly, you won't accidentally forget to update a random server for two years and then worry about breaking it during the next upgrade. Based on that stress-reduction alone, I highly recommend this approach.

PowerSchool Gradebook on Chromebook

This school year, I had a few high school teachers beginning to use chromebooks as a full-time tool. Generally, there were two complaints: They weren't able to print and they couldn't run the (Java based) PowerSchool gradebook program. The printing issue was simply because I hadn't set up any Cloud Print compatible printers yet. Accessing their gradebook, on the other hand, was a more interesting challenge.

One day, I had an idea. Its a huge "hack," but it works. We used a service called rollApp to remotely run a Firefox & Java capable environment and, from that, we could run the gradebook. Its a bit like the matryoshka Russian nesting dolls.

First, from the chromebook you visit rollApp. Then click "Login" and click on the Google logo. This will allow you to quickly login using your Google account and save you from having to remember Yet Another Password. This even works with accounts in a Google Apps for Education system.

Second, once your account is set up, run the rollApp version of Firefox. This will cause Firefox to display on your screen, but its actually running on the rollApp server and using their memory, CPU, etc.

Third, once Firefox is on your screen, go to your PowerSchool system and login. Then run the gradebook program.

The first time you do all of this, it will take a while. The next time, though, there are a few fewer steps. For example, you won't have to agree to so many things and Firefox will be in your list of recently used rollApp programs.

Important Note: As stated above, the gradebook is running on rollApp's servers and not your chromebook. Its only visible from your chromebook. This means that you've allowed rollApp to see you typing in your PowerSchool password. You have to decide if they are trustworthy enough for that. Check with your Information Technology department. There may be a district policy that could guide you on this topic.

It is my hope that PowerSchool will eventually have an HTML 5 version of their gradebook so that this hack isn't necessary. If they even came out with an Android version of the gradebook, that could be ported over to ChromeOS quickly via the Android Runtime for Chrome. So, with any luck, this idea will not be needed some day. For now, however, its an option that you can consider. Just make note of the potential security issue and check if your district has a policy on this before you begin using it.

iPads on Chromebooks

I learned an interesting thing recently. A teacher I work with connected an iPad to a chromebook's USB port. I was pretty sure that it wouldn't do much other than charge the iPad off the chromebook's battery, but I was wrong.

Trying to show the teacher that she couldn't synchronize data between the iPad and chromebook that way, I opened the Files program on the chromebook. In Files, in the same sidebar area that Google Drive and other things appear, there were two listings for the iPad. When I clicked on one, nothing showed up. When I clicked on the other, a DCIM folder showed up. Most digital cameras store their data inside a folder named DCIM and it appears that iOS follows this standard. So ChromeOS basically said, "OK, here are the photos on that camera you just connected," and offered up the files. We were able to drag-and-drop them into Google Drive, allowing her to copy them over.

Of course, she could have done this with the Google Drive app for iOS. This USB method does have a few advantages, though.

For one, it allows a teacher on a chromebook to collect photos off of their students' iPads. No accounts are required. You don't even need software from Apple's App Store. This could be useful in schools that provide iOS devices (e.g. iPads or iPod Touches) to younger students. It could also be helpful for people who have iPads but don't use Google Apps for Education. In that situation, the students wouldn't necessarily have Google Drive accounts to upload their photos into. There are also situations when students don't have Apple accounts and, therefore, can't download apps like Google Drive from the App Store.

I suspect there are other potential uses for this that I'm not thinking about right now. If you have any, please tell me about them in the comments section below so that other readers can benefit, too.

YouTube Use in Schools

Recently, GoGuardian published this interesting analysis of YouTube usage over a sample set of a few hundred schools. Its well worth a read, just to see how the younger crowd views computers in general and YouTube in particular.

Side note: If you use Chromebooks (or their desktop cousins, Chromeboxes) and haven't heard of GoGuardian, you should give them a look. It might not fit your institution's needs, but they have interesting enough features that they could be useful.

What Username Mounted That Drive?

A few months ago, I had to upgrade a system that wasn't documented. A key piece of the system was a Windows network drive that automatically connected when the workstations started up. In order to do the upgrade without accidentally breaking the system, I needed to know what user account was used to mount the drive.

A little bit of research turned up the following command, which I found really helpful. I am documenting it here just in case it helps anyone (including me) in the future.

wmic netuse where LocalName="Z:" get UserName /value

Note that "Z:" should be replaced with whatever drive letter you need to check.

Credit where its due: http://stackoverflow.com/questions/9037503/determine-domain-and-username-used-to-map-a-network-drive

Meraki MDM No Longer Free

Articles like this one and talking with my counterparts in other schools lead me to invest my time into using Meraki System Manager (a.k.a. just "Meraki") as a free Mobile Device Manager. As with all free services, I had reservations. Specifically, I wanted to know their long-term business model so I could be certain that it would remain free.

However, the Meraki MDM remained free for the two years or so that I had been watching them and a great many schools began depending on their service. Meraki also publicly stated several times that its MDM service would remain free. So I took a chance on them.

Then I heard the Out Of School podcast's episode 126. They claimed that Meraki changed directions and turned the MDM service into a bit of a bait-and-switch service.

Doing my own research, I found Meraki's own document on the transition.

Bottom line: For those of us already using Meraki System Manager, its not as bad as the hosts of Out Of School would have us think. But it does "start the clock" for our search to migrate off of Meraki's free offering and onto a paid service. This is especially the case if you have lots of devices.

For anyone who hasn't started on Meraki yet, I recommend avoiding it unless you can be 100% certain that you won't have more than 50 or so devices to manage AND that you can lay our hands on them in short order if the need arises in the future. I say that because you may find yourself in a position where you have to move off Meraki System Manager in a hurry when Apple or Google introduce new MDM expectations for iOS or Android at a future date. Meraki has said that they won't introduce new features into the old/free service. Also, while Meraki will let you have up to 100 devices on a free account, any experienced systems administrator knows that their institution school will some day increase its number of devices without a lot of advanced notice. By setting the threshold at 50 devices, you have a decent buffer to use up while explaining to your managers that they'll need to spend thousands of dollars per year on a service that they didn't even know existed and doesn't have an obvious affect on their bottom line.

There is certainly an element of a betrayal of trust with Meraki's new direction, but I feel that this wasn't entirely a surprise. Its why I hedged my bets and tried three MDMs first. (For the curious: Apple's Profile Manager and FileWave were the other two.)

For my part, I think its still not a bad deal. It allows you to manage your MDM without running the service yourself. Let's face it, you didn't want yet another server's upgrades and backups to worry about, did you? It also supports iOS all the way back to iOS 4.x. Not a lot of MDMs seem to do that. That said, I think there are also better options. Especially if your other workstation management tools have MDM components, e.g. Profile Manager, Casper, or FileWave.

So there you have it. A warning of upcoming change and my two cents on it. Take it for what you will, but if you use Meraki System Manager or are considering using it, please be informed. Good luck!

Chromebook Flip from Asus

I'm a fan of ChromeOS based computers, like the chromebook, especially when paired with Google Apps For Education. They're a capable and low maintenance combination that allows Information Technology staff to focus on things that are closer to the institution's core mission and not installing software, upgrading servers, recovering lost files, preventing/removing malicious software, etc.

Sometimes, though, a touch screen system is a better tool. So it was of great interest to me when my team deployed the Lenovo Thinkpad Chromebook Yoga 11e to dozens of my teachers in the 2014-2015 school year. I really wanted to see what the teachers could do with such a "convertible" style of computer that could combine Chromebook and tablet features.

At the time, there were only three touch-screen chromebooks: the Yoga, the Pixel, and the Acer C720P. They were all excellent notebook computers, but the Pixel was prohibitively expensive and only the Yoga could mimic a tablet. That is about to change.

Asus has announced the Asus Chromebook Flip, to be released in June 2015. Its a $249 chromebook with 4GB of RAM. That is a pretty good deal already. Their other 4GB RAM chromebooks (the C200 and C300) cost more than that. The Flip, however, comes with a touch screen and converts into a tablet just like Lenovo's Yoga. This nearly halves the price of a convertible chromebook when compared to when we bought them for our teachers just a few months ago.

The Yoga is probably a bit more durable, especially its keyboard and non-metal chassis. The Yoga also has a 15% larger screen. It might be the better computer for adults. However, for younger students the 10.1" screen might be fine. The Flip's cost also matches the low end of what we typically spend on chromebooks for student use. So adding the convertible nature of these models and some Android software (Android-programs-on-Chrome project) and Google Play For Education, we end up with a very nice package.

I don't know about anyone else, but I'm looking forward to the idea of a chromebook for K-5 students which doubles as a tablet, costs the amount of a 2 year old iPad mini even though its brand new, runs Android programs (which are as numerous and diverse as iPad software these days), is the size of a full iPad Air, and has that full keyboard that is required for computer based testing. It sounds like the perfect way to help students transition from "what I use at home for casual web browsing and games" to a more serious "what I need to do research, take notes, and build large projects." Like putting the computer on training-wheels.

Managing ChromeOS Users & Alternate Accounts

Part of this article is relatively obvious, but there is an interesting tip about users switching between accounts.

Once a user logs into ChromeOS, they can add a second profile for a different Google Account and toggle between them. This is much like using profiles in Chrome for Windows or Mac. The article gives directions on how to block that and other user login controls.

Honestly, I'm not sure what the negative impact would be if users were allowed to login to your domain and then add an account that isn't in your domain. If they want to separate their work and personal lives, I consider that to be a good thing. The only advantage I can see is if your institution has a set of users that are being monitored (e.g. students who are minors or an employee on an improvement plan) and you need to prevent them from circumventing that monitoring. For example, if you use GoGuardian in a school setting, this could help.

At the moment, I'm not inclined to use the tips in the linked article. However, I'm leaving this link here in case it could benefit any on me else or in case I change my mind and want to do this in the future.

Chromebooks For Young Students

Chromebooks are a marvel of low maintenance. They require almost no effort to get running or keep running and have all kinds of advantages. However, logging into them can be a challenge for the youngest of students. Typing a username like "john.doe@myschoolname.org" is a bit much for a kindergarten student. It can even pose a challenge up to 2nd grade.

In this article, I want to show two solutions that I came up with. My teachers were extremely grateful when I rolled out the first one in 2013. Since rolling out the second in 2014, they've barely stopped thanking me. Both approaches are free and only require that your chromebooks are enrolled in a Google Apps For Education domain -- a very common thing.

First Steps

First, you have to identify which chromebooks will be effected by this setup. In my case, there were two carts of chromebooks used by kindergarten through second grade. This was the obvious choice for me, since we start teaching students to login with their own accounts a few months into second grade. I was fortunate, because K-2 are the only grades using these two carts and they only use these carts.

Once you've identified the chromebooks you want to effect, go to admin.google.com and create an organizational unit (OU) to isolate them. OUs can be hierarchical, so feel free to arrange things however you need. In my case, I made an OU called "Devices", then sub-OU called "Schools" and "Digital Signage" and "Special Cases" and so forth. Within "Schools", I made a sub-OU for each school and then a sub-OU for each cart of chromebooks.

It took a bit of time to do this and then file each chromebook into its relevant OU, but it pays off in the long run. There are a lot of time when applying a setting to just one lab or just one school is exactly what you want to do. This groundwork makes that possible.

One last point before I move on: Talk to your stakeholders. Sometimes the teachers are aware of things that the technical support folk aren't. Don't get into too many technical details, but ask them about their computer use patterns. The right OU structures should become obvious once you do this.

Guest Login

Now that you've laid a good foundation, then next step is pretty easy.

In the Google Apps For Education (GAFE) controls located at admin.google.com, go to "Device management" then "Settings". On the left side, select the first OU that you want to effect. Then go to "Guest Mode" and change it to "Allow guest mode". Click "Save changes" at the bottom. Repeat this for each OU that you want to change.

After the next reboot, the chromebooks' login window should have changed. If you had the kind of login window that has two blank text fields for name and password, it will now have a bit of blue text on the right side. It says "Browse as Guest". If you previously had the kind of login window that shows icons of each user, then you'll have a "Browse as Guest" button on the lower-left corner.

Either way, the effect is the same. A student clicking on Browse as Guest will be sent to an Incognito window. This means they don't have to remember a password and they don't have to type a long (for a 5 year old) email address. However, this also means that you can't look up their browsing history nor can you know who used the chromebook last. So there are trade-offs. However, for the very young students these trade-offs can be very worthwhile.

If you'd like, you can stop here. Show your teachers this new option and you're all done. Its a huge improvement and they'll probably be grateful for it. However, if you want to take this to the next level, keep reading.

Next Steps

My teachers used Browse as Guest happily for a year. They eventually started telling me that having students type in "www.example.com" took a long time. Students didn't know where the letters were on the keyboard and didn't know how to spell things. This was in the back of my mind on the day I discovered Public Sessions. I realized that we could much go further.

Using Public Sessions, I could make a chromebook as easy to use as a tablet. I can't understate this. This is huge.

One of the reasons that teachers in the early grades like tablets is that they are a big screen full of buttons. The student presses the button for the service they want and then they get it. No login window. No typing URLs. Its just there. And the teacher can customize and streamline the experience.

Using a mix of Google Sites and Public Sessions, chromebooks can have this advantage, too. If you have touch-screen chromebooks, then you've basically made a low cost, low maintenance tablet with a keyboard.

Get Feedback

First, ask your target teachers what sites they use regularly. These are the URLs that teachers have been typing into the chromebooks for the students. These are the sites that you're going to make easy to access.

Once you have that list compiled, send it to them. Ask if anything was missed.

Now look for a pattern. Does each grade level have its own list? Would it be best to arrange them by subject? The purpose here is to figure out how you want to arrange the icons on the screen.

Google Site

Next, make a Google Site using logos for each service. Arrange the logos in a way that makes sense to you. Don't over think it. Just get them on the page. Then email the URL to your new site to your teachers. Ask what they think. Say something like, "I'm looking at a way to make the chromebooks easier for the really young students. It would look like this: [link]. What do you think?"

Ask questions that get their thoughts flowing. Listen to the feedback. Make changes. Send them the new version. Repeat this feedback cycle until they are happy. This feedback cycle makes the teachers much happier with the results. It takes a few days or weeks, but its well worth it.

Just to give you an idea of how much the feedback matters, consider my first and final drafts. The first idea was to have three rows of icons and to color code them based on grade level. By the time we were done, we moved to a much different design that was less flashy but more effective. In part, this was because there were some sites that were used at several grade levels, so the color coding didn't work out. See what I mean in the images below.

First draft:

Final draft:

The point? Don't over-think things. Let the teachers be your guide. Its less work for you in the long run and it makes a result that they'll be happier with.

Public Sessions

Once you have your Google Site completed, we move back into the more technical aspects of the process.

You'll need a testing environment. Get a single chromebook that you can use for testing your settings. In admin.google.com, make a new OU and place only this chromebook into it. We'll make all of the changes inside this OU for now, so you can perfect your system.

Go to "Device management" and then "Public session settings". Select the OU that you just created. Name the session that you want the teachers to see. I used "Kiosk", but "Dashboard" or "Springpad" or "Quick Launch" are all fine. This is what some people call "branding." Its the word that you want people to use when they think of this service you're creating. You can come back and change this latter, so don't over-think it right now.

Next, scroll down to the "Startup" settings. For "Homepage is New Tab Page" set it to "Homepage is always the Homepage URL, set below". Then type in the URL to your Google Site. Enter the same URL under "Pages to Load on Startup" as well. Then save your settings.

Now go to "Device management" and then "Device settings". Select the OU for your testing environment again. Set "Public Session Kiosk" to "Allow Public Session Kiosk". Save your new settings.

Go to your testing chromebook. Restart it so the new settings kick in. There should now be a new login window. It should just say "Kiosk" (or whatever your public session is named). Click on that and then the next button. You should go straight to the Google Site you made.

If this worked, its time to polish the settings. Sorry, but I have to be vague here. The settings that work for me might not work for you. Things that I considered include "Auto-Launch Public Session" (in Device Settings) and various settings in the Public Session (such as idle logout, avatar, wallpaper, etc.) This is why you need a testing environment. Keep making changes and then looking at the results. See what works for you and what doesn't.

Next, and perhaps most importantly, get teacher feedback. Ask for a 15 minute after-school meeting with that team of teachers. Show your test system to the ones that show. Ask what they think. Point out things you can adjust, such as the Google Site's contents and layout, the avatar icon, the idle logout period, the session name, etc. Take notes of their suggestions. Ask the group for a consensus. Then let them know what changes you'll make and let them know about when you'll roll out the changes.

Make the changes that you agreed to and test them. If everything is working, you have everything you need. On the afternoon before the scheduled rollout, make new public sessions in the OUs that you want to effect. Just copy over all the settings. (Unfortunately, this has to be done manually.) Then enable the public session in the device settings and you're all set.