Friday, August 21, 2009

Google Apps for Our Chapters - An Experiment

Twittastract: The basics and best practices I have discovered while moving to offer email forwarding via Google apps to some of the chapters that my Association supports.

The problem with Google Apps especially for non-profits is that they make it so easy and appear to be providing a service for no cost that I don't trust them. So, I continue to move forward deploying their stuff, but grow increasingly wary that it is too good to be true.

My latest venture is to deploy Google Apps for mail forwarding for our chapters. For a while now we have been partnering with some of our chapters to give them website hosting and vanity domain names. There is a lot of overhead associated with this venture that we try to hide from the chapters. A downside of this, is that when they ask for something that seems to be a quick add to them and we say "no" they don't understand and the whole experience sours a little for them.

Mail forwarding is a good example. To save a chapter from having to maintain their own domain, DNS and associated registration costs and headaches, we make a sub-domain for each chapter. For instance, our Valley of the Sun chapter is now vos.astd.org. The vos.astd.org website is hosted on our SharePoint farm in our domain. They get to shed these costs and their admin staff gets to be shielded from the spam that we endure by having our contact information associated with the domain registration. In return, however, they have to rely on our staff for all dns and domain changes. This has made mail forwarding a problem since we don't want to use our internal mail servers for their forwarding (they are undersized for such a volume) and the chapters don't have their own mail servers.

We first looked at Google Apps a while ago but due to some brain lock on my part, I couldn't figure out how to set up the domains to make it work. Finally I saw the light and remembered that subdomain.domain.com can point to an entirely different place on the Internet as domain.com.

Blah, blah blah, I know. I need an editor. Anyway, the how to:
1) Create an account for the chapter on Google Applications. Since we may have to do this for all of our chapters eventually, we're using a similar "master" username and password for each. This account will be granted Administrator permissions.
2) Decide on the kind of account. Some of our chapters are actually 503 corps, so they qualify for the special "Google non-profit" version of Google Apps. Others are not so organized, so we are setting up each one using Google Standard Application accounts (limited to 50 named users). The chapters who want to can upgrade the account whenever they need to.
3) Verify domain ownership. This one took some trial and error. We finally went with the "CNAME" route since we use Sharepoint. Sharepoint and some other cms' don't actually have straight html files. A way to verify ownership is to modify the main html file on your server and then let Google find it. The modification is an html comment, so inserting it shouldn't change the look of your page. If you don't have html files on your server this won't work so you have to use CNAME.
4) Active the mail by adding a set of MX records pointing to Google to your DNS. This will actually do the relaying of mail. In essence a piece of mail will arrive at your DNS and ask the DNS the name of the actual server that has the email program. The DNS will send them over to the Google email servers.
5) Create the "users". Because we are just doing mail forwarding and relays, we are only creating one or two users. The chapter leaders will do the forwarding by creating a number of "Groups". See below for why.
6) Create a sub-admin account for the chapter to use. This way the chapter can manage their own forwarding and we can step in when they forget the password or have some other kind of leadership turnover and need our help. If the chapter truly breaks everything, we can just eliminate the MX record and CNAME record in our DNS (which would cut the Google Apps account off from the domain name) and start over.

Google actually has very good documentation on how this all works on the site, complete with pictures and Wizards to step you through.

So, why we are using Groups instead of creating a separate user for each? For the most part, the Chapter Leaders just want the email to forward to their home or work account. The easiest way to do this is to create a group with only one person (president@vos.astd.org for example) and set it to forward to an external email address. Also, creating a group does not count against the named users. The downside of this method is that the person does not get the Google spam protection and must rely on whatever they use at home. Additionally, when they reply to the message it will come from their own account, not from the alias account. Another reason to set up groups for the aliases is that it doesn't require us to set up a new password and account for each alias. For example, we could set up president@vos.astd.org as an actual user of the system and then give her the credentials to log in. This would give her the spam protection and give her the ability to send and receive from the account. The downside of this approach is that setting up the forwarding is more complicated and the risk that we have password issues at the end of the term of office goes up causing more work for us on the back end. With potentially 160 chapters using the service and all of them changing officers in January, we just couldn't scale that.

So far, this has been well received. If you would like me to walk you through how to do this for your organization drop me a line. Also, I'll post a follow up in a few months about how we change our process in response to more chapters using the service.

No comments:

Post a Comment