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.

Fix

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.

Tags: , ,

About The Angry Technician

The Angry Technician is an experienced IT professional in the UK education sector. Normally found in various states of annoyance on his blog. All views are those of his imaginary pet dog, Howard.

6 responses to “Google Apps Directory Sync requires elevated privileges to Simulate Sync”

  1. mavhc says :

    To be fair it’s actually Postini’s software that’s never been tested.

    More annoying is a bug that suspends your admin account when you run the sync: http://www.google.com/support/forum/p/Google+Apps/thread?tid=2fcf4060362fd5c7&hl=en

    Now I can’t play with it until google finds a human to help me.

    • AngryTechnician says :

      A lot of Google’s desktop software started life in someone else’s dev team (Earth and Sketchup spring to mind). My view is that as soon as you slap your logo on it, you get to be the fall guy.

      That’s foul luck with your account suspension. Not that it will make you feel any better, but the potential for that problem did occur to me when I was setting up my config. I remember thinking ‘surely it won’t be dumb enough to suspend the master admin account… or will it… I’ll set an exclusion anyway’. Something else that could do with being in the documentation?

  2. PalmPirate says :

    And I thought niche software development was bad!

    Let’s hope they never devise their own testing certification, ex-“Google Logo Tested!” Maybe this could be their logo: http://1.bp.blogspot.com/_oBTxhRLevpA/TKoPHI7EcnI/AAAAAAAACr8/Vl7Is3KloLE/s1600/labmonkeys.jpg

  3. Parlance says :

    Thanks for the tip. I found your blog recently and have really enjoyed reading it as I am also in IT and education and use many of the same products.

    I just wanted to point something out in case anyone is reading this and setting up Google Directory Sync along with Single Sign-On to enable users to login with their LDAP credentials without giving Google (albeit hashed versions of) all your passwords. In the user sync attributes settings do NOT check force user to change password at first logon; you’d think it is irrelevant because it only applies to the internal Google Apps password because and it unused after you enable Single Sign-On, but it actually causes weird issues and I had to delete and recreate all my accounts because of this (which can take a very long time for thousands of accounts, apparently).

  4. Brad says :

    I worked around this by creating a folder in C:\ProgramData and moving the configuration .XML file and the .LOG file there. You need to update the .XML file to the new .LOG file location. This folder can be written to without requiring elevation, and UAC stays intact.

  5. Harry says :

    It’s really a joke. It’s been 4 years since your post, and still it doesn’t work without running as an administrator. Worst thing is that there’s ZERO mentioning of this in the admin guide or about anywhere else. I had to send Google a feedback of this.