WiX 3.0 throws error 217, while being executed by continuous integration

Question

This is the error that is thrown by our automated build suite on Windows 2008, while running ICEs (after migrating from WiX 2.0 to WiX 3.0):

LGHT0217:

Answer 1

End of the story:

After fiddling with the permissions of the integration account, DCOM, service activation, etc. without any luck, I finally simply disabled ICE validation in the continuous integration build, while still keeping it in the local build.

To disable ICE validation you can set SuppressValidation to true in the .wixproj file:

    <PropertyGroup>
        <SuppressValidation>true</SuppressValidation>
    </PropertyGroup>

Or pass the -sval command line option to light.exe.

Answer 2

The correct description (without a solution, except if adding the CruiseControl account into local administrators group can pass as a solution) of the problem:

Quote from Wix 3.5 & Cruise Control gives errorLGHT0217:

ICE validation needs an interactive account or administrator privileges to be happy. See for example WiX Projects vs. TFS 2010 Team Build (2009-11-14) or Re: [WiX-users] Help with building patch (2009-11-20).

Answer 3

None of the above suggestions worked for me, for me the anti-virus (mcafee) came into the picture and looks like it updated the vbscript.dll registry entry to a wrong DLL location. These are the things to keep in mind:

1. Some of the WiX ICE validations are implemented using VBSCRIPT.
2. So while compiling the MSI, the build server would need access to the c:\windows\system32\vbscript.dll.
3. Chances are that somehow the user that runs your build lost access to this DLL.
4. As mentioned in the above answers do look for the admin access/registry access and make sure your user has it.

Here are the steps that I took to fix the issue:

1. Open cmd (run as admin) on the build agent machine.
2. Run RegEdit
3. Select the root, then click ctrl + f and Search for the following registry entry : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
4. Look for the InprocServer32\Default Key

1. On my build agent, the path was replaced with a mcafee DLL location. I updated the path back to c:\windows\system32\vbscript.dll
2. Editing the registry entry was not easy, as it was a protected registry entry. I used the below link to get access permissions changed before I could edit the property: Edit protected registry entry

Once I updated the path, everything started working as usual.

Answer 4

imagi is totally right! I could not believe this is the true answer. Supressing validation and making TFS user Administrator are not good solutions. Plus I could not find NT\Authority to add it to Administrators group and was totally stuck in this.

I got the same error on Windows Server 2012 Datacenter as Build Agent. To solve the problem :

1. List item
2. Go to Environment Variables on the build agent machine
3. Create two System Variables
4. "PF86" which is equal to "C:\Program Files (x86)"
5. "PF" which is equal to "C:\Program Files"
6. They are so short because I want to save characters.I made them without the final backslash because TEMP, TMP and others were made so and I decided to stick to MS standard for these variables.
7. Edit PATH variable by substituting every "C:\Program Files (x86)" with %PF86% and every "C:\Program Files" with %PF%
8. Close and build and enjoy!
9. It worked for me. :)

UPDATE I found a better solution : Rapid Environment Editor will do all this and even more for you. Automatically.

Answer 5

Go to your build machine and restart the Windows Installer service

Answer 6

My solution is similar to Vladimir's one. My CI user was admin of the computer.

But the following steps were mandatory to allow my jenkins build to succeed:

• log in as CI user using rdp
• open a dos command prompt
• execute: %windir%\system32\msiexec.exe /unregister
• execute: %windir%\system32\msiexec.exe /regserver

then i got a successfull job