As I mentioned before, I’m in the process of moving my life over to TFS 2010 Beta 2. I’m using the excellent WiX 3.5 Beta that plugs into Visual Studio 2010 to create my setup and I had a developer build working like a dream. Things got a little more exciting when I created my first build definition and let the build fly on the build server.
The build failed with errors like the following:
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 you are running Windows in safe mode, or if the Windows Installer is not correctly installed. Contact your support personnel for assistance.”.
The first eight Internal Consistency Evaluators (ICE) failed and ICE8 was the most unhappy of all:
light.exe: An unexpected Win32 exception with error code 0x643 occurred: Action – ‘ICE08’ Fatal error during installation
I had installed TFS Build on my build server using the defaults, which uses NT AUTHORITYNETWORK SERVICE as the account for running the build controller and agent. Switching the controller over to an interactive controller/agent combo using a domain account, everything worked great. However, if I used that same domain account and ran the controller/agent as a service, I got the ICE failures.
After a night’s sleep, I played around some more and stumbled into a work around. In order for the .WiXProj files to compile, the account running the build controller/agent must be in the local machine’s administrator group. I found that any domain or computer account works fine for the builds. You can also use NT AUTHORITYNETWORK SERVICE, but you have to add it to local machine administrator group. Since you can’t do that through the computer manager, he’s the command line way to make the addition:
net localgroup “Administrators” “NT AuthorityNetwork Service” /add
No amount of google-fu turned up anything about the permissions issues with ICEs so I hope this saves you some hassles when you set up your own TFS 2010 Build Servers.
Microsoft Azure and Amazon Web Services (AWS) are two of the most popular cloud platforms.…
Cloud management is difficult to do manually, especially if you work with multiple cloud…
Azure’s scalable infrastructure is often cited as one of the primary reasons why it's the…
https://www.youtube.com/watch?v=wDzCN0d8SeA Watch our "Unlocking the Power of AI in your Software Development Life Cycle (SDLC)"…
FinOps is a strategic approach to managing cloud costs. It combines financial management best practices…
Using Kubernetes with Azure combines the power of Kubernetes container orchestration and the cloud capabilities…
View Comments
You said,
"Since you can't do that through the computer manager"
But, it is possible to add "Network Service" including "Local Service" / "SYSTEM" account to local machine administrator groups with "compmgmt.msc" tool, isn't it?
Interesting Finds: November 15, 2009
SeongTae,
On Server 2008 R2, the UI didn't let me. It's probably not a safe option to allow your service accounts to to have Administrator rights so Microsoft has tried to help protect us. :)
- John Robbins
In my case,
The UI did let me on Server 2008 R2. :)
http://www.sysnet.pe.kr/syswebres/builtin_accounts_with_adminrights.PNG
(KST 09:00 ~ 23:00)
In case this is still of interest, I'm running into these same issues when attempting to build Wix projects through TFBuild using TFS 2008 and Server 2008 R2. Also of interest, with regard to your comment on google-fu, was that I've been able to find nothing on the subject myself when searching for things having to do with ICE errors; I only found this article itself when I searched for "wix tfs 2010."
So far the only solution I have found is to disable ICE validation, but I would really rather not as it has already helped me discover quite a few things I would have done wrong otherwise.
Alex,
Do what I did and set the permissions on the build account to have local admin rights. That'll get things working.
- John Robbins
DANGER DANGER, DO NOT DO THIS!!!
Placing Network Service in the Administrators group basically opens a massive security hole on your server. The whole point of Network Service is that it's a locked down account that *does not* have Administrator access!
Running a build as Administrator is not a good idea, but at very least configure the build to run as a custom account with Administrator access - don't put Network Service into Administrators. I think I'm going to have nightmares tonight!
SW,
You're right. :) I should mention that I moved my build account to a local machine administrator. Because of crappiness on Microsoft's part you need admin rights for these ICE validations to work. I hate it, but Windows Installer is such a bad API we need all the help we can get.
- John Robbins.
For me it started to work as soon I have added my account to local Admins group AND HAVE RESTARTED the Visual Studio Team Foundation Build Service Host (Windows service).
Wow, this is in every respect what I nedeed to know.