Google Apps: Configuration for a non-Google managed domain

I now have four Google App/Domain pairs and I've created a fifth Google App for Minnesota Special Hockey (at the moment the latter is down for the migration). I've also suffered through more-or-less migrating several blogs to "custom domains". Even if I ignored recent Gooflops at Gmail and Blogger my experience with Google Apps would confirm Google has way too many partially finished products. Here's some help.

If you create a Google App and register a domain (via eNom, Google isn't a registrar (!)) it's not too bad, though the documentation is scant. If you have an existing domain you want to migrate into the Google Apps suite ... well, prepare to gnaw a limb off. Unless, of course, you read this first, in which case you'll probably decide this is ridiculously complex and do something else.

Here's the secret sauce, hidden away in the help file, I found it because I knew to search help with the string "ghs.google.com".

1. Sign up for your free Google Apps. Non-profits like MN Special Hockey can start out with the regular freebie and then easily upgrade for more free support and services.
2. Now you need to validate your ownership. You can either do this with a CNAME record or you can create a file in the root of your domain that Google will look for. I prefer the file trick since CNAMEs can be treacherous. The Google page for validation will tell you what to do. (See [1] below for a bug in Google's directions.)
   
3. Change your CNAME records (these are simple redirects) to both validate your ownership (if you choose the CNAME validation) and setup your custom URLs for your content at the same time. [2]
   For example (using kateva.org, the domain that hosts this blog), create these CNAME entries all with a relationship to ghs.google.com
   news.kateva.org (for your blogger blogs, I prefer this to blog.kateva.org)
   www.kateva.org
   start.kateva.org (this is the Google Apps "desktop" page)
   calendar.kateva.org
   docs.kateva.org
   mail.kateva.org
4. Google help tells you to do use a "CNAME Lookup" service to test the CNAMEs, but when I followed their advice to "Google" for a service I found nothing. Dumb. Until you validate you can't do anything. Once you validate you can use Google App services at Google URLs.
5. Wait until you're validated, then login to your Google App (https://www.google.com/a/cpanel/kavteva.org for example) and change to the custom URLs that match the above. A bug in Google's "start" page means it always displays the non-custom URL but users can reach it via the custom URL.
6. Now go to blogger and change your blog to the custom domain of blog.kateva.org (for example)
7. If you want the email to work, you have get your ISP to change MX records: "Mail Exchange (MX) records control how incoming email is routed for your domain. Before Google can host your email, you'll need to change these MX records to point to our servers." Until then users get fairly useless generic emails.
   

[1] I attempted to validate using the old "upload file" trick, but Google's documentation of this was nonsensical. Here's exactly what they wrote (changing the secret token):

"Create a HTML verification file named googlehostedservice.html , copy the text specified below into it, and upload it to http://mnspecialhockey.org/ . googledwkgf4845250

Here's what they meant:

1. Create googlehostedservice.html
2. Put the text "googledwkgf4845250" in the file googlehostedservice.html
3. Upload googlehostedservice.html to http://mnspecialhockey.org/

[2] Some registrars let you change CNAMES yourself (yay!) others (boo, hiss) make you write them an email.

Update 7/21/07: I'm still working through this, when I'm done I'll revise this entire post. A few things to note:

1. When you're trying to integrate a pre-existing domain and hosting arrangement with Google Apps you really want direct control over you CNAME redirects. It's a pain to do this otherwise.
2. If you have a pre-existing hosting arrangement your main decision is whether to keep the original web page and file hosting or switch to Google Apps (very weak) web page designer(Google Page Creator) and file server. If the former you want to keep your domain name under the control of your host and keep a CNAME redirect of www.kateva.org (for example) to the domain name. If the latter you probably need to give up the hosting arrangement entirely and plan to recreate all web pages in Google Page Creator (impractical for any but the simplest sites). The case of mnspecialhockey.org is unusual in that we will want to move the web hosting to Google Page Creator because we need something very simple that anyone can maintain.
3. You may need to restart your router to see some of the CNAME changes. I suspect my router was caching old IP addresses, I didn't see the changes until I restarted it. Might have been coincidental.
4. There's a bug in the Google Apps "start" page. Even if you change to a custom URL and create a CNAME redirect, it still publishes to the original "partner" URL and the custom URL resolves to the "partner" URL. I thought this was a Lunarpages error, but I see the same behavior with Google/eNom managed pages.

Update 7/23/07: I've got most of the configuration working, and now I'm implementing workarounds for the one residual intractable problem -- there's no simple way to have mnspecialhockey.org redirect to www.mnspecialhockey.org. It always directs to the lunarpages "subdomain" IP address. I can redirect from index.html on that machine of course, but that doesn't help with other page requests.

Lunarpages recommended URL rewriting using my /public_html/mnspecialhockey/.htaccess file:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^mnspecialhockey.org [NC]
RewriteRule ^(.*)$ http://www.mnspecialhockey.org/$1 [L,R=301]

I'm not positive Google approves of url rewriting, but this example is fairly benign. I reviewed Matt Cutts writings on the topic and I didn't see an obvious red flag.

Update 7/24/07: The URL rewrite seems to work, though the original one I was sent had an error in it (above is corrected). Lunarpages, to their credit, quickly adjusted the MX records so the email now works.

Update 8/31/08: Things were far simpler when I switched from Lunarpages to DreamHost in August 2008. I also have a more detailed explanation of how things work.