I'm trying to integrate WiX into my automated build solution using Tfs2010 running on Server 2008 R2. Everything seemed very easy, and then I get this:
light.exe: 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.".
That's odd. But hey! They provided a link. That should help, right?
Error LGHT0217
In WiX v3, Light automatically runs validation-- Windows Installer Internal Consistency Evaluators (ICEs) --after every successful build. Validation is a great way to catch common authoring errors that can lead to service problems, which is why it’s now run by default. Unfortunately, there’s a common issue that occurs on Windows Vista and Windows Server 2008 that can cause ICEs to fail. For details on the cause and how to fix it, see Heath Stewart's Blog and Aaron Stebner's WebLog.
Not at all. These posts just describe a situation involving scripting engine registration, and the conditions they describe were not present. However, I came upon this link that seemed to indicate that if I used a domain account to run the Windows Installer service, it would work. Sounded like it was worth a shot.
"For whatever reason on Windows 2008 (I didn't test Vista, XP, 2003, 7, or 2008 R2) the MSI Service is only available from logins that either have administrative access or are logins that are "interactive". Logins that are from service accounts that to not have administrative privileges cannot access the msi service and thus cannot run ICE tests."
However, when trying to start the Windows Installer service with my build service account:
Windows could not start the Windows Installer service on SKILLET-1. Error 1297: A privilege that the service requires to function properly does not exist in the service account configuration. You may use the Services Microsoft Management Console (MMC) snap-in (services.msc) and the Local Security Settings MMC snap-in (secpol.msc) to view the service configuration and the account configuration.
Ok, windows, so you're telling me that my build service account is missing some ambiguous permission that it needs to start up the service. Making it administrator should fix that right? Nope, that doesn't work either.
So I revert back to local system for the Windows Installer service account. This time I made the build service a local administrator, and lo, success! That's hardly a solution, though.
My next idea was to attempt to isolate the permission set that the build service would actually require to get this done. That would be a nice solution instead of having to add more accounts to the administrator set. Step 1: go into local security policy and add the build service account to all permissions currently given to Administrators. In theory that should allow the build to succeed, and from there I could selectively remove permissions until I've isolated all the permissions that must be held in order for it to succeed.
Unfortunately, even with all the same permissions, the build will still fail unless the build service account is a member of local administrators. Why is this? What other things besides LSP have dependencies on the administrator group that I could have changed to bring my build service account to equivalence with administrators?
Current conclusion: build service must be an administrator in order to avoid ICE validation errors.
Open questions:
- Why didn't my permissions isolation idea work?
- What is this mysterious
Error 1297
being thrown when running Windows Installer Service as a domain user? There's almost no documentation I can find on this.
Thanks!