title: WiX: Mysterious and hard-to-diagnose ICE validation errors on build server build
body: <p>I'm trying to integrate WiX into my automated build solution using <a href="http://en.wikipedia.org/wiki/Team_Foundation_Server" rel="nofollow noreferrer">TFS</a> 2010 running on <a href="http://en.wikipedia.org/wiki/Windows_Server_2008" rel="nofollow noreferrer">Windows Server 2008</a> R2. Everything seemed very easy, and then I get this:</p>
  
  <blockquote>
    <p>light.exe: Error executing <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa369554%28v=vs.85%29.aspx" rel="nofollow noreferrer">ICE</a> action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See <a href="http://wix.sourceforge.net/faq.html#Error217" rel="nofollow noreferrer">http://wix.sourceforge.net/faq.html#Error217</a> 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.".</p>
  </blockquote>
  
  <p>That's odd. But hey! They provided a link. That should help, right?</p>
  
  <blockquote>
    <p>Error LGHT0217<br/>
    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.</p>
  </blockquote>
  
  <p>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 <em><a href="http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg35149.html" rel="nofollow noreferrer">Re: (WiX-users) Why do I get ICE failures building from a serviceaccount?</a></em> (2010-01-14) that seemed to indicate that if I used a domain account to run the Windows Installer service, it would work. It sounded like it was worth a shot. </p>
  
  <blockquote>
    <p>"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."</p>
  </blockquote>
  
  <p>However, when trying to start the Windows Installer service with my build service account:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>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.</p>
  
  <p>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. </p>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>Current conclusion: the build service must be an administrator in order to avoid ICE validation errors.</p>
  
  <p>Open questions:</p>
  
  <ul>
  <li>Why didn't my permissions isolation idea work?</li>
  <li>What is this mysterious <code>Error 1297</code> being thrown when running Windows Installer Service as a domain user? There's almost no documentation I can find on this.</li>
  </ul>