Google Edu Apps how-to, Part 1

For the last half of 2009, I've been writing about my great experiences with Google Apps for Education. I've talked about cool features, their plans for next year, and user acceptance of the service.
Written by Christopher Dawson, Contributor on

For the last half of 2009, I've been writing about my great experiences with Google Apps for Education. I've talked about cool features, their plans for next year, and user acceptance of the service. However, as a reader pointed out recently, I've never actually explained how to get your school or district up and running with Apps. While it's actually quite simple, there are a few things worth considering in advance, some decisions to make, and a few things to plan for.

First, you need at least one domain over which you have control. In particular, you need access to all DNS functions related to this domain. Some of the more masochistic among you may host your own DNS, but for the rest of us, any number of services like GoDaddy, 1and1, and Siteground have incredibly easy tools for managing your domain. Better yet, as you go through this process, Google provides very specific instructions keyed to the major hosts. So if, for example, you use GoDaddy, you can select the GoDaddy-specific instructions and the process becomes a matter of simply following directions.

Notice, however, that I said you need at least one domain. Why would you want more than one? Because currently Google Apps does not allow for granular control of user group policies. Don't want your students to have Chat? Then your teachers won't have it either. Don't want your elementary school kids to have email? You can't just shut it down for them. This requires at least a canonical domain name, but means that you then have to manage multiple domains within Apps. While that's not a huge deal, it is cumbersome, which is why Google has promised subgroup control within a single domain in 2010. Thus, you won't need to have a set of users in the domain elementary.yourschool.org, a set in yourschool.org, and a set in secondary.yourschool.org to fine tune user policies.

One other consideration in terms of the domain is that Google must be able to verify that it belongs to an educational institution for you to get Edu Apps for free. Edu Apps has basically all of the features of the Premier Edition of Google Apps for which business pay $50/user/year. While this price isn't actually unreasonable for what you get, free is obviously better. Fortunately, Google knows basically everything about anything on the Internet (yes, conspiracy theorists, it really is fortunate), so within a couple days of initiating your request for an "Educational Upgrade", you're automatically up and running.

"Educational Upgrade?" you ask? Initiating what request? OK, I'll take a couple steps back now that we've covered domain concerns. Let's assume you already have your domain of choice and are only planning to hook one of those domains to Edu Apps (you can certainly do more, but the process is the same). Go to this website: http://www.google.com/a/help/intl/en/edu/get_apps.html. Once you answer a few simple questions (e.g., are you K12 or higher ed), you'll be asked to enter your primary domain. This goes back to the question I asked earlier: do you want multiple domains for your school/district? Whether you do or not, this should be the base domain (e.g., myschool.org).

A few more steps in the wizard and you now have a "Standard" Apps account, allowing you to begin setting up users and policies. The Standard account is fairly limited, but the request for an Educational account is automatic when you sign up, so you'll be upgraded shortly. You should also expect a call from an Apps engineer and possibly some sales-types. Go ahead and talk to them. They're helpful.

I'll post Part 2 of this a little later on Wednesday. For now, it's worthwhile to read Google's own deployment guide since we've made it through the basic account creation. Part 2 will take us through Postini and archiving services, multi-user setup, user data migrations and imports, and more.

Editorial standards