Google Apps Directory Sync requires elevated privileges to Simulate Sync
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.
Only a moron would run a Windows server with UAC turned off, so I got caught out by this immediately. If you simply run the tool from the Start Menu, it won’t prompt for elevation. Here’s what happens when you then try to run a sync simulation with a valid config file (click to enlarge):
Basically, the Simulate button will grey out, then do nothing. If you click back to another part of the config tool, then return to the Simulate section, you’ll find you can now see the simulation results page, but it will be stuck on “Initializing…” forever.
Running the tool with elevated credentials immediately solves the problem. This happens on Vista, Windows 7, and Server 2008 and Server 2008 R2, so it seems Google either haven’t actually tested it on any Windows OS made in the last 5 years, or they routinely turn off UAC, a key security feature. No wonder they think Windows is so bad.
So why does it happen? Because the log file is located in the Program Files directory, and you’re not supposed to write logs to Program Files. Log files should go in AppData, either for the individual user or All Users (C:\ProgramData in Vista/7/2008/R2).
So, when the tool tries to log its simulation process, it is denied access to write to its own log file. Not that it tells you this, of course. Why would there be any error boxes? Error boxes are for WHINERS.
You can either solve this by always running the tool with elevation, or by adding an ACL entry to the Google Apps Directory Sync folder in Program Files so that whatever user you are running the tool under has permission to write to the log file. I recommend the latter, because the sync-cmd tool that performs the actual sync will need the same rights, and it’s easier to configure this as a Scheduled Task if you don’t need to elevate it every time.
If you’re a total hack of an administrator, you could also disable UAC, but that’s using a sledgehammer to crack a nut, and frankly, I don’t like puréed nuts.