Software Request Review Considerations in a K-12 Environment

In a previous post , I discussed the need to slow down and breathe during tech adoption, especially while under stress.  Based on that post, I thought I would share some policies written in regards to software adoption in an educational environment. Several years ago, I was responsible for authoring my employer's Software Steering Review Committee policies and considerations for approval. In a time when the school district I work for was pushing hard on instituting personalized learning, it was difficult to maintain a balance between flexibility and appropriate review. The district already had the initial request process documented, so I was simply left with the review process documentation. Originally, there was a Software Steering Review Committee that met to evaluate requests. Unfortunately, that process was cumbersome and difficult to schedule, which resulted in many successful attempts to completely bypass review. (Please keep in mind, the purpose of this post is not to

No, You Don't Need That Highlighter App (A discourse on Google for Education and FERPA)

As educators, parents and students around the world struggle to rapidly adapt to our changed environment, now seems like a good time for a reminder that it's ok (even necessary) to slow down and evaluate our technology adoptions.  As such, I'm taking this opportunity to review some points about Google Apps for Education (GAFE) and FERPA compliance. The G Suite Terms of Service for Education Agreement is not a terribly long document, it totals out at just over 12 pages.  When a school district signs up to use Google Apps for Education, someone authorizes this agreement.  In it, Google asserts that they will act as a "school official" with regards to the data they receive.  There are two very important things to remember about this agreement however: This agreement applies to Google's Core Services and does NOT apply to additional services (explicitly noted in the GAFE privacy policy .) It is still the responsibility of the district to configure the G Suite

Simulating Walled Gardens with G Suite Sharing and Directory Settings

As I mentioned in a post several months ago, the school district I work for recently underwent an audit specifically focused towards G Suite domain configuration in a K-12 setting.  I would like to give a quick shout out to Amplified IT , it was a great experience to work with a company so familiar with the unique needs of an educational institution. As with the results and recommendations of any audit, there is a process for evaluating and prioritizing the remediation response.  A significant consideration in any school district is the ability to maintain safety for kids with the least possible adverse impact on the educational environment.  Below I will detail a couple specific changes made to our G Suite domain as part of our effort to simulate "walled gardens" for our younger students.  Please keep in mind, this is by NO MEANS an exhaustive list. Specific service sharing settings for our primary and intermediate student organizational units (Pre-K through 6th grade)

A review of my last three years at THOTCON

TLDR: Social media has a purpose, follow all the people.   Plan ahead, then realize that plan won’t actually work very often.   Take notes in the way that is best for you, whether electronic, by hand or photos.   Meet people. This spring I had the opportunity to attend THOTCON (a hacking conference in Chicago, IL) for the third year in a row.   It was an excellent time, with awesome people, and I decided to put together some of my thoughts on the experience. At this point, I think it would be best if I give a bit of background on how I ended up attending conferences in the first place.   As people may or may not be aware, Alaska is not what could be considered a hot spot when it comes to security/tech meet ups and opportunities.   Due to limited availability, I started looking outside for conferences as a way to assist my career development possibilities.   Additionally, Alaska is expensive to get out of, and as I was paying for this out of pocket originally I narrowed my

Synthetics monitoring with New Relic for PowerSchool products

Beginning August 2018, the school district I work for rolled out a new Learning Management System, PowerSchool Learning, for use by faculty, staff and students.   While our primary Student Information System (PowerSchool SIS) is housed on-premises, the learning management module is hosted by the vendor.   One of the concerns brought to my attention prior to the rollout was monitoring i.e. what kind of notice were we to expect during outages, and how could we most effectively communicate that to all effected parties.   So, to start with we needed an effective way to verify that a client could log in to the self-hosted SIS, then navigate through to the offsite-hosted LMS.   While there are many monitoring products out there, and many are very good at what they do, we eventually settled on using New Relic Synthetic Monitoring.   The primary considerations for that were as follows; the scripted browsers are easily configurable, the built-in tracking for Service Level Agreements, and

G Suite Organizational Unit Structure in a K-12 Environment

As previously stated, I work in a K-12 school district.  Recently there were some incidents that required me to evaluate and make some changes to the organizational unit structure in our G Suite domain.  Without getting into policy or politics, the concerns raised had to do with how to go about preventing certain types of communication while still providing equity of education in a one-to-one Chromebook environment. Our initial user OUs had minimal granularity available.  In the below example I've left out devices: G Suite Administrators Teachers (All Staff) Chromebook Managers Students Primary (PreK - Grade 3) No Additional Services Intermediate (Grade 4 - Grade 6) No Additional Services Middle School (Grade 7 - Grade 8) No Additional Services High School (Grade 9 - Grade 12) No Additional Service If you aren't familiar with service management in the G Suite Admin console, services are generally turned on or off on a per OU basis.  While Google has

Whitelisting Chrome Extensions/Apps in G Suite Admin Console

Recently, an incident in the school district where I work required that the district implement additional restrictions in regards to Google Chrome and Chrome devices.  After looking at options, the decision was made to switch the Student Organizational Unit over to a whitelist policy for extensions and apps.  Teachers and other faculty members would remain on a blacklist policy, and notify technology of what they would like whitelisted for student use.  I sent out a survey to collect the names of all currently used extensions, collected the results, and made a test OU to switch to whitelisting. Part of the conversion process also involved a review of all force installed apps and extensions.  There are two ways to force install through the admin console ; using App Management or User Settings in Device Management - Chrome Management.  App Management is meant for singular instances, while the User Settings method is more conducive to multiple force installs.  While both methods are ac