For me, one of the advantages of Google Apps over Live@Edu is the simplicity of the tool used to automatically provision user accounts based on your Active Directory. While Live@Edu requires you to use the complicated Identity Lifecycle Manager (which consumes significant server resources), Google Apps Directory Sync can be run on the bare minimum of hardware and takes only a very short time to set up.
When used in conjunction with the sha1hexfltr program, you can not only synchronise the user account data, but also the user’s password, ensuring the user does not have to remember two different passwords for their standard computer logon and their Google Apps account. Unfortunately, the way it does so is not the exactly most secure method in the world.
Don’t get me wrong, I’m very glad that the Google Apps .NET API library exists. Unfortunately, the documentation can be a little obscure, and there isn’t a lot in the way of example code around for it, especially when it comes to OAuth. Even the official documentation page has only a single .NET example, and that uses an API call that is deprecated in the latest version.
To make matters worse, getting user data out of Gmail isn’t really supported at all by the Google Apps API. You can change settings and provision accounts, but not get any actual email. However, there is a single feed for Gmail to retrieve unread email details in Atom format, and you can use it with 2-legged OAuth. This isn’t mentioned at all on the page that lists the API scopes, and there’s no official support for it. But it works.
The big advantage of using 2-legged OAuth, in case you’re unaware, is that you (as the Google Apps administrator) can create an application which retrieves data for your users without them having to supply their credentials or go through the standard OAuth approval mechanism. This is especially advantageous in, say, a web portal application in a school. You need to set up 2-legged OAuth in the control panel to get your consumer key and secret, but that’s the easy part.
As part of a recent foray into Google Apps for Education, I’ve once more been learning that Google don’t really take their Windows product testing seriously. Google Apps Directory Sync is a somewhat essential tool if you want to manage even a moderately sized Google Apps deployment, because it will synchronise your user accounts (including passwords) with an LDAP server such as Active Directory. Compared with the somewhat tortuous process of accomplishing the same thing with Live@edu, the Google system is a clear winner.
Apart from when it comes to actually running it on a modern Windows system. It starts off badly when reading the Features and Benefits section of the (otherwise excellent) administration guide:
“Runs on any Windows (XP or Vista), Linux or Solaris server.”
Yes, that’s right, Google thinks that Windows servers run on XP or Vista. Not, say, Windows Server 2003 or Server 2008, the actual server environments. Worse still, it’s clear they haven’t actually tested it on Vista, or its server counterpart, since the instructions fail to mention one crucial thing: the Simulate Sync function of the configuration tool does not work at all with UAC turned on because of insufficient rights to the Program Files directory, which is the default install location for Google Apps Directory Sync.