Visual Studio solution with WiX project - light.exe error - The Windows Installer Service could not be accessed

I am working on migrating our FinalBuilder 6 on Windows Server 2008 instance to FinalBuilder 7 on Windows Server 2008 R2.  We have several Visual Studio solutions that contain a WiX project.  These projects used to build successfully through the build service on the old server but are now failing during the WiX validation on the new server.  The error is:

light.exe(0,0): error LGHT0217: Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".

This repeats for ICE action ICE02 - ICE09.

These projects succeed on the new server when built interactively through the FinalBuilder GUI.  I've done a lot of searching on similar issues without luck.  Some searches suggest improperly registered scripting engines, that doesn't appear to be the problem.  Other searches suggest permission issues.  The projects are configured in the build server to run as a domain user that is a local admin.  I've tried changing the "FinalBuilder Server 7 Build Service" to allow the Local System to "interact with desktop" and also tried to run the service as the same domain user that the projects are configured to use, neither helped.  In fact, using "interact with desktop" was even worse as FBCMD would fail to start.

My searching has led me to believe that there was a fundamental change in the Windows Installer that is preventing non-interactive sessions to access it, changing server versions has moved us from Windows Installer 4.5 to 5.0.

At this point, the only solution has been to suppress ICE validation within the WiX projects which I'd rather not use as a permanent fix.  Just checking if anyone else has encountered this problem.  Thank you.

So, turning off UAC corrects the problem, but that is also not a desirable fix.

Ouch. Typical of microsoft though. The UAC security model is very much not compatible with automatio, this is not the first tool to behave differently with UAC enabled and probably won’t be the last. There is no programmatic way to elevate a processes permissions in a manner where we can capture stdout. Microsoft kindly added that to shell execute, which makes sense since with shell execute you kind of expect that there’s a user around to react to a dialog… but there is no way to do that using CreateProcess.