Google Apps: What About Security?

One of the questions that WILL come up as schools speak to the IT staff about Google Apps for Education is security.

One question I get frequently is simply... "What about security?"

I sometimes go into the "money in the bank" theory and share that we store money in the bank because that's what banks do so much better than we do at home. Banks have locked safes, fire suppression, armed guards, and they pay me an embarrassingly low interest rate. These are all measures that I don't do as well at my home. (And the bank won't let my kids find my money!) So I let banks do what they do so well. 

The same is true with Google. Google does more in their data centers than most schools can afford to do or are staffed to do. Read this post and be sure to watch the short video. Ask your school IT folks if they take the same measures to ensure data security.

I'm not suggesting that any online service is impenetrable and infallible. I do think the measures that Google takes is more than adequate for most schools. Do you?

Google Docs for Classroom Projects - Project Templates

Google Docs is an awesome platform for classroom projects! In project-based learning teachers will provide project directions, requirements, and resources to their students when beginning a project. Usually that's in the form of a paper handout of some sort. Some teachers like to provide an electronic document that will get students started.

In the past we've easily created a Word or other document template. When the student opens the template a fresh new copy is provided for him/her without affecting the original document. Google Docs has a unique method for sharing documents.

Here's my first attempt at creating a class folder with a project templates collection (folder) that will help provide project starter documents:

1. Create a class GROUP in your Gmail contacts. (This will make it easier for sharing collections with the whole class)

2. Create a Class collection (folder) and share it with the class as VIEW ONLY using the "Can view" permissions setting. The class folder is set to "Can view" so that others cannot modify the folder setup.

3. Inside the Class collection I've created two other collections. One Inbox that will be used for submitting assignments and one Assignment template folder.

4. The Inbox collection may be shared with the class as "Can edit". This will allow students to submit files there. It's not a perfect solution as students can see other's projects. This is another post.

5. The Assignment template collection should be shared with the class as "Can view". This will allow you to create assignment templates. Students will be able to open and view items in this collection. They will not be able to edit the original. They may, using the file menu, create a copy of the template and rename it as their own to begin the project. I like to provide students with naming conventions to make file collection unique and organized.

For the remainder of the course the teacher may create an assignment starter template, place it into the Assignment Template collection, and it is properly shared using the permissions on the collections. The document will be shared with the class as view only.

Students may place completed projects into the Class Inbox. That will make the document available to the teacher for grading, comments, etc. The inbox needs some work. I hope that Google will institute the necessary sharing permissions to create a more private dropbox-like feature.

Have you found similar solutions? Please share!

Going Google - Migration Weekend

It's cut-over weekend. This means that for all District staff email is closed for the Independence Day holiday weekend. (A few MUST HAVE users excepted of course.) When staff return to work on July 6, 2010 they will begin using the new Google Apps email and calendaring system. My District has officially "Gone Google" now.

Preparations: 

In preparation for cut-over weekend we initiated a series of communications. We issued notices of what people should do, when they should do it, and what to expect. I really don't think you can over communicate when making such change.

We pre-migrated some of our very heavy users. This gave us a chance to work one-on-one with those who really depend on email, calendar, mobile access, etc. It was good in two ways. First our team was able to practice the migration techniques. We were able to learn where our users would need support. Now we can adequately prepare the help documentation that most staff are likely to need. Second, by migrating several heavy users we can begin to minimize the folks who may need more attention on day one. I'm pleased with the outcome of the early adopters.

On the technical front we prepared about a week ago by shortening our "time-to-live" notice on our mx record. This tells DNS servers across the internet to check for an impending change. The change they'll be getting is mail delivery for our existing domain will change from our email servers to the Google email servers. In prior testing we didn't shorten the TTL and the change took nearly a week on some DNS servers. This can result in lost email due to confusion on Internet DNS servers.

Migration from Exchange to Google servers:

One of the things that has been very handy is a "test" Google Apps domain. We have registered two domains. One for staff and one for students. It has been handy to use the student domain for testing the Exchange migration tools.  While students are gone for the summer we can import and export accounts without disrupting the contacts database in our staff server. So if you are planning a migration, having a test domain is handy.

We have learned that calendar events that have been created as a result of a meeting invitation are not being migrated from Exchange to Google Apps. We have also noted that if a delegate user maintains your calendar that event migration is suspect. We have asked all of our staff who use the calendar system to print their calendar event list. After migration they are advised to compare old to new. Another option for staff who's calendar migration wasn't successful is to export their Exchange calendar to a .csv file and import into Google Apps calendar.

On Friday, offices closed at noon. Network administrators spent many hours importing accounts into Google Apps and testing the migration tools. They set up a series of desktop computers with the migration tools installed. While some documentation suggests to migrate smaller numbers of accounts we tested larger numbers with success. Each computer was pre-configured to migrate between 50 and 100 accounts. The migration kicked off and seemed to go slowly at first but picked up speed. Any inconsistencies in account spelling from one server to the next introduces serious delays. Triple-check your account name spelling! More than a million email messages, calendar events, and contacts are being migrated over the holiday weekend. Fingers crossed!

When all migration systems had started the Exchange server was running close to 50% CPU. Our Internet circuit was hovering around 8 mbps outbound. I'm guessing that the bottle-neck was disk read speeds as we had a number of computers pulling data for migration.

First Day Support for Office Staff:

On the first day using Google Apps email we have assigned a member of Technology Services to each building. The technician will assist office staff with getting logged in, sending email, reading email, and checking / maintaining their calendar. The tech will provide staff with a user manual (pdf), quick start guide, and answer basic questions.

Technical staff are directed to provide basic assistance only. Staff who wish to have more formal training will be pointed to our training calendar for opportunities.

Advertising to the Public:

Notices to parents, contacts, and constituents will be made through traditional correspondence. We have placed a prominent announcement on our District website. Staff members are urged to put new address notices in their signature block. School buildings will be asked to highlight our new email addresses through welcome letters and school newsletters. Pennsylvania Department of Education have been notified of our official change of web and email domains.

I'm considering sending news releases to local newspapers as well.

Please check back for our successes and pitfalls.

In my region this change to Google Apps for our primary email is like a middle school dance. Everyone stands on the perimeter until one person starts dancing. Well, we're dancing! Will you join us???

Going Google - Last Week Sneak Peeks

T-minus one month!

Our District will transition to Google Apps for Education as our primary email system on July 2, 2010. We've notified staff, posted our training and support site, encouraged email back-ups and clean up.

We have also tested user migration, calendar migration, Outlook folders and more. (Don't get me started on sorting email into folders! I just don't understand why anyone would file email 4, 5, and even 6 folders deep!) Am I the only one that doesn't sort their email into folders? Who has that kind of time?

Now we turn our focus to training. The last weeks of school we are setting up in school libraries. We are inviting all staff to introductory sessions using demonstration accounts. We are providing tri-fold brochures that outline the basics of Gmail, Calendar, and Contacts. We call the sessions "Sneak Peek This Week!"

Almost all staff are excited, perhaps nervous, about the change. Once they experience the interface we see staff members are more relaxed. They are confident that they will be able to operate in the new system.

The biggest challenge to date has been the difference between folders and labels as well as "search rather than sort".

One technical challenge that we've recently discovered is that calendar events initiated by the user migrate just fine. Calendar events that are created from an invitation are not being migrated. Fingers crossed that we'll get that ironed out.

Has anyone solved the calendar migration issue?

Going Google - Reconfiguring Staff Computers

The next step in going Google is a big one! We have outlined a plan to collect all staff computers and reconfigure them for our summer conversion to Google Apps for Education. This will involve about 350 teacher laptops. Let the fun begin.

There are a few key items that represent significant change:

• There will be no email client configured. All staff will complete the school year using Outlook Web Access only. Entourage and Outlook will be blank.
• We have added Google Chrome as an additional browser option. Google Chrome is not the default browser. We stayed with Firefox as the default browser. I expect that many users will try Google Chrome and like it. I really like Chrome. I also expect it to become our default browser on the next refresh. 
• We have installed the Google Notifier on our Macs. Google Notifier is a handy utility that sits in the Mac OS X menu bar and notifies users of new email messages and calendar appointments. It also helps us make NASDschools Gmail the default "Mailto" client in Firefox.

There are a number of other updates but these are the ones significant to our migration to Google Apps for Education. 

Going Google - And the #1 feature...

We've started introducing our office staff and administrative teams to the new Google Apps interface. We provide a tri-fold brochure with the basics of NASDschools Gmail, Calendar, and Contacts. They are the primary tools that many staff members use to complete their job responsibilities. It is our hope that these "sneak peeks" alleviate some of the anxiety of changing email systems.

As we introduce the Gmail interface the number one feature that our secretaries like... emoticons! Yep. Email is fun again! We have to allocate 5 minutes to allow staff to review all the emoticons smiley's.

Shhhh... don't tell them there is a lab to add even more!

Going Google - Authentication - Password Options

Many schools deploy Google Apps for Education as an additional service. Teachers and perhaps students have a system username and password and an additional account and password for the G-Apps access.

Switching to Google Apps for Education for all staff as our primary email and groupware communications presents several challenges.

In our current setup accounts are created in our directory service. Users in a particular group, in our case the Staff group, receive email account as well. The directory username and password are the same for system log-in and email access. So network administrators need only provide one account.

Adding Google Apps for Education creates the need for an additional account. Ideally network administrators would continue to create accounts in the directory service and accounts would be synchronized to Google Apps. This service is available and is called Google Apps Directory Sync.
When network or system administrators create a staff account a corresponding Google Apps account is created. When accounts are suspended or deleted, Google Apps accounts are suspended/deleted in turn.

There is one drawback Google Apps Directory Sync tool, directory passwords are not passed from your local directory service to Google Apps for Education. (Yes, there are APIs and service providers to assist with this.) So users would have one username and two independent passwords, one for system log-in and another for email. The passwords are independent and the staff member controls each one separately.

To minimize password problems and ideally provide one username and password combination we've tried a few things:

Option 1: We set up an open source central authentication system or CAS. (Special thanks to Kris Hagel for his step-by-step directions and his willingness to assist.) The CAS server is tied to our directory services for authentication and then tied to Google Apps with a one-to-one correspondence. When a staff member attempts to log into their email the authentication request is re-routed to your CAS server. The authentication process proceeds locally and is then handed off to Google Apps. VERY SLICK solution. There are a few drawbacks and some VERY compelling benefits to this solution. One of our network administrators invested many hours implementing this solution. Thanks, Brian!
Drawbacks:

• CAS requires a local server (virtual server in our case), 
• The open source solution has informal support only
• If the District has a power failure then even home or mobile users cannot authenticate. The CAS server is a single point of failure. 
• Passwords are never actually transferred to Google Apps

The benefits of a CAS server are that it can be tied to multiple online systems such as your Moodle server, Wikispaces private label, your web-based SIS, Mahara, ... etc.

Option 2: We also are looking at a .dll and registry hack on our directory domain controllers that would take the users password, encrypt it and store it in another contact field. Upon directory sync as discussed above the password would be pushed to Google Apps for Education. I'm rarely a fan of registry hacks and custom .dlls on domain controllers. The drawback here is that the solution seems that it's still being developed. We've read reports that it only syncs passwords after system administrators reset the password and NOT when users initiate the password change. A recipe for problems in my opinion.

Option 3: is to do nothing. Allow staff members have two independent accounts. One for active directory and the other for email. The accounts will have the same username. They may set the passwords differently or the same. It is up to the user. The drawback here is that password management is done in two systems for network administrators.

We're as yet undecided. What would you do?