Frequently Asked Questions
As of January 2013, 127 Oregon School Districts and Educational Service Districts are using Google Apps for Education under the State's agreement. Oregon's 127 Districts Domain's provide services to 273,000 users.
The Agreement between ODE and a District includes the following provisions:
- Districts assume the administrative control over their domain.
- District staff control account creation, user permissions, Google application availability and e-mail filtering configurations. The Google Postini default filtering settings are very effective.
- Districts have the use of the secure Google Groups to set up school groups and permissions.
- Districts accept the responsibility for user support. Admin support will be available through the ORVSD Help Desk with Google technical support as required.
- Districts retain their responsibility and authority with respect to federal privacy and student protection guidelines including, but not limited to, FERPA and COPPA.
- Districts are required to obtain new Parental Consent for the student use of the Google Apps Domain. Consent Forms must be retained on file by the district.
- Districts control the advertising functions in the domain. They are off by default.
- Districts retain the decision to issue Gmail accounts under their domain for school staff. There are no restrictions for staff.
- Districts have use of the services for up to five years. Google and ODE will review additional multi-year extensions year four of the agreement.
Current Schools and/or Districts who are using Google Apps as of April 28th 2010:
- ODE has negotiated an agreement with Google that specifically addresses the liability exposure Oregon School Districts currently use Google Apps, may encounter under the Standard Google Agreement. In the event school districts are currently using Google Apps under the Standard Agreement, they are strongly encouraged to either migrate their existing domain to the ODE-Google Agreement or verify risk mitigation with local legal counsel. ODE is providing access to Google Applications for Education as a suitable substitute.
The Agreement acknowleges the student safety and privacy requirements in CIPPA and COPPA. School Districts and Educational Service Districts using Google Applications for Education under this agreement are accepting responsiblity for the policies, procedures and administrative control of their domain.
Postini features are currently being built into Google Apps for Education editions. Configure Email settings for email filters, customized email policies per organization (Google's version of OU), content compliance, attachment compliance, etc.
A tip for easy archiving:
BCC all email to an archive account
Create a new user account.
All incoming and outgoing messages will be BCC'd to this user. Optionally, you can log in as the archive account and delegate access to another account for when someone needs to check the archive for a message.
Select the "Settings" tab at the top, then "Email" under "Services" on the left, and finally the "Filters" tab.
Click the Add Setting button, and select "Content compliance" on the left side. Add an expression, and simply use @. The @ symbol will be in every email, so it's any easy way to match every message incoming and outgoing. Save that expression.
Scroll down and check "Add more recipients," and add the archive email account setup in step #1.
Save and add the setting, then log into the the archive account and make sure emails are being archived correctly.
You might consider creating multiple archive user accounts, for instance, one dedicated to 2012, and other for 2013, for better organization.
Google Apps Lesson Plan resource - http://www.google.com/a/help/intl/en/edu/lesson_plans.html
Lesson Plan Submission - https://spreadsheets.google.com/a/google.com/viewform?hl=en&zx=124702759...
Google Education Resource Center - http://www.google.com/a/help/intl/en/edu/resource_center.html
Google Implementation Plan - http://www.google.com/support/a/bin/answer.py?answer=151500
Google Deployment Checklists - http://deployment.googleapps.com/Home/resources-deployment-planning/deployment-checklists
Probing questions and options to think about:
* Directory structure integration? Will you be leveraging LDAP/Active Directory to keep accounts updated?
- eDirectory - SADA systems is a Google partner that can provide integration with eDirectory for single sign-on if using Novell.
- Active Directory - UMRA by Advanced Toolware can be used to provision/manage accounts using Active Directory.
- Single/Dual domains and name of domains should not interfere with LDAP integration.
* When deploying student accounts, how will you alert your community? ORVSD staff will have a sample consent letter available soon. Please check back.
- End user agreement required
* Purchasing Google email archiving through Postini
* ESD provided archiving solution
* District provided solution
See articles below to use own archiving solution
* Google Resource docs
Outbound Mail Gateway - http://www.google.com/support/a/bin/answer.py?hl=en&answer=178333
Inbound Mail Gateway - http://www.google.com/support/a/bin/answer.py?hl=en&answer=60730
* There is no user identification for records/accounts created in Google Apps for Education. Username/email address is the sole uid for the entire domain.
Some districts already have students access file shares using the State Secure ID number (SSID) as a login. But transferring this to the Google login is not feasible. Using the SSID could violate FERPA and will hamper communication. For email address book autocomplete, suggest using a first.last type login. Adding graduation year might help eliminate errant emails to previous students as email addresses are recycled to students with the same name in subsequent years and still allow autocomplete to work. For students in the same graduation year with the same name, a middle initial or incremental number could be used on a case by case basis.
* What naming scheme will you employ? (just some possible solutions)
* Single domain - same security, access, sharing settings for teachers/staff as students
Some districts use this configuration as they feel providing two logins/passwords to multiple domains is cumbersome for staff. However, this eliminates the ability to make separate settings in each domain. Usually staff desire an open domain, so using this configuration would require an open domain that students were also using.
* Dual domain - different security settings for teacher domain, student domain. Multiple accounts for teachers to be able to access/share work with students. Multiple administration points
Most districts seem to use this configuration so that different applications and closed/open domain settings can be maintained separately for staff and students. Of course, staff are required to have multiple logins to the staff and student domains. If staff already have a personal Google Apps account at home, most likely they will then have three Google logins/passwords to manage. Sharing documents between the two domains would be cumbersome/impossible unless both domains allowed sharing outside the domain and this may not be desired by the district for at least the student domain. When working in the student domain, staff would have an account @students.district.k12.or.us. This name is not quite accurate. This introduces an additional email address to manage/forward.
Some districts use a dual domain architecture to maintain different app settings, but open both domains. This allows documents to be shared among the two domains, and allows teachers to have one login since they don't need a separate login to the student domain to share docs. The district addresses COPPA/FERPA through the end-user agreement, et. al. However, it would appear students could share documents with "anyone" outside the domain. Google does not appear to have any way to allow sharing between two domains only.
* Multiple domain - Multiple accounts for teachers to be able to access/share work with students. Multiple administration points
Tuesday, July 20, 2010 at 9:00 AM
"FROM GOOGLE BLOG: In the past six months, we’ve released a series of new features giving administrators more controls to manage Google Apps within their organizations. Recent additions include multi-domain support, new data migration tools, SSL enforcement capabilities, more mobile device security controls, and the ability to tailor Google Apps with more than a hundred applications from the new Google Apps Marketplace. Today, we’re excited to announce one of the most highly requested features from administrators: user policy management. Now administrators can segment their users into organizational units and control which applications are enabled or disabled for each group. For example, a manufacturing firm might want to give their office workers access to Google Talk, but not their production line employees. Mayooran Rajan, CTO of Revevol Consulting, noted, "We work with businesses with 100 to 20,000 employees moving from on-premise solutions to Google Apps. The new user policy management feature helps us tailor Google Apps and provide businesses with granular control for each department within their company."
Link to Google Blog for full post
sub-domain of k12.or.us domain? (username/email address considerations) i.e. students.district.k12.or.us
* provides clarity
* is managed by existing DNS
* is freenew domain all-together (LDAP integration, web presence consistency (i.e. .org domain instead to shorten (some districts prefer)
* requires separate registration, dns management, and yearly fee
* may not look as "official" or "recognizable"
* might be much easier to use
* using .org should not impact LDAP integration