[WiX-users] Burn Error

[Kelly Graus]

Hello,

I have a customer who is receiving error 0x80070660 when running a Burn based 
installer on Windows Server 2008 R2.  Below is the log file.  I have verified 
that both the temp directory (pointed to from the TMP and TEMP environment 
variables) and the c:\ProgramData directory are writable and have plenty of 
space.

A separate installation created using installshield is failing with error code 
2755 (which seems to also be related to permissions problems with the temp 
directory).

Any thoughts on what the problem could be?

Thanks!

Kelly

[0A98:071C][2012-10-10T13:39:53]: Burn v3.6.3213.0, Windows v6.1 (Build 7601: 
Service Pack 1), path: 
C:\st-data\Stapps\APPS\toltech\toltech-license-server.exe, cmdline: 
'-burn.unelevated BurnPipe.{C1D2E94A-666A-485F-ADF2-C0F01F1678BF} 
{222F5F32-A900-4241-A7E3-C0D90A9731CF} 2072'
[0A98:071C][2012-10-10T13:39:53]: Setting string variable 'WixBundleLog' to 
value 
'C:\Users\ADMINI~1.STU\AppData\Local\Temp\License_Server_20121010133953.log'
[0A98:071C][2012-10-10T13:39:53]: Setting string variable 
'WixBundleOriginalSource' to value 
'C:\st-data\Stapps\APPS\toltech\toltech-license-server.exe'
[0A98:071C][2012-10-10T13:39:53]: Setting string variable 'WixBundleName' to 
value 'License Server'
[0A98:071C][2012-10-10T13:39:53]: Detect 1 packages
[0A98:071C][2012-10-10T13:39:53]: Detected package: License_Server.msi, state: 
Absent, cached: None
[0A98:071C][2012-10-10T13:39:53]: Detect complete, result: 0x0
[0A98:071C][2012-10-10T13:39:57]: Plan 1 packages, action: Install
[0A98:071C][2012-10-10T13:39:57]: Setting string variable 
'WixBundleRollbackLog_License_Server.msi' to value 
'C:\Users\ADMINI~1.STU\AppData\Local\Temp\License_Server_20121010133953_0_License_Server.msi_rollback.log'
[0A98:071C][2012-10-10T13:39:57]: Setting string variable 
'WixBundleLog_License_Server.msi' to value 
'C:\Users\ADMINI~1.STU\AppData\Local\Temp\License_Server_20121010133953_0_License_Server.msi.log'
[0A98:071C][2012-10-10T13:39:57]: Planned package: License_Server.msi, state: 
Absent, default requested: Present, ba requested: Present, execute: Install, 
rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[0A98:071C][2012-10-10T13:39:57]: Plan complete, result: 0x0
[0A98:071C][2012-10-10T13:39:57]: Apply begin
[0818:09E8][2012-10-10T13:39:57]: Creating a system restore point.
[0818:09E8][2012-10-10T13:39:57]: System restore disabled, system restore point 
not created.
[0818:09E8][2012-10-10T13:39:57]: Caching bundle from: 
'C:\Users\ADMINI~1.STU\AppData\Local\Temp\2\{1ceedb7f-bc77-4979-87f5-a0b54b8eac69}\.be\setup.exe'
 to: 'C:\ProgramData\Package 
Cache\{1ceedb7f-bc77-4979-87f5-a0b54b8eac69}\setup.exe'
[0818:09E8][2012-10-10T13:39:57]: Registering bundle dependency provider: 
{1ceedb7f-bc77-4979-87f5-a0b54b8eac69}, version: 2.0.8.0
[0818:049C][2012-10-10T13:39:57]: Verified acquired payload: License_Server.msi 
at path: C:\ProgramData\Package Cache\.unverified\License_Server.msi, moving 
to: C:\ProgramData\Package 
Cache\{809F96D3-6E6B-4C67-9D95-3B6BECDADA5A}v2.0.8\License Server.msi.
[0818:09E8][2012-10-10T13:39:57]: Applying execute package: License_Server.msi, 
action: Install, path: C:\ProgramData\Package 
Cache\{809F96D3-6E6B-4C67-9D95-3B6BECDADA5A}v2.0.8\License Server.msi, 
arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" ARPSYSTEMCOMPONENT="1"'
[0818:09E8][2012-10-10T13:39:57]: Error 0x80070660: Failed to install MSI 
package.
[0818:09E8][2012-10-10T13:39:57]: Error 0x80070660: Failed to execute MSI 
package.
[0A98:071C][2012-10-10T13:39:57]: Error 0x80070660: Failed to configure 
per-machine MSI package.
[0A98:071C][2012-10-10T13:39:57]: Applied execute package: License_Server.msi, 
result: 0x80070660, restart: None
[0A98:071C][2012-10-10T13:39:57]: Error 0x80070660: Failed to execute MSI 
package.
[0818:09E8][2012-10-10T13:39:57]: Skipped rollback of package: 
License_Server.msi, action: Uninstall, already: Absent
[0A98:071C][2012-10-10T13:39:57]: Applied rollback package: License_Server.msi, 
result: 0x0, restart: None
[0818:09E8][2012-10-10T13:39:57]: Removing cached package: License_Server.msi, 
from path: C:\ProgramData\Package 
Cache\{809F96D3-6E6B-4C67-9D95-3B6BECDADA5A}v2.0.8\
[0818:09E8][2012-10-10T13:39:57]: Removed bundle dependency provider: 
{1ceedb7f-bc77-4979-87f5-a0b54b8eac69}
[0818:09E8][2012-10-10T13:39:57]: Removing cached bundle: 
{1ceedb7f-bc77-4979-87f5-a0b54b8eac69}, from path: C:\ProgramData\Package 
Cache\{1ceedb7f-bc77-4979-87f5-a0b54b8eac69}\
[0A98:071C][2012-10-10T13:39:57]: Apply complete, result: 0x80070660, restart: 
None, ba requested restart:  No


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrel

Re: [WiX-users] Remove Options button from Burn?

[Kelly Graus]

A related question: how do you support the option to change the installation 
directory? I'm guessing its passed to the msi as a variable? I'm sure it's 
probably easy, but my google skills are failing me :-).

Kelly

On Sep 30, 2012, at 10:02 PM, Rob Mensching  wrote:

> Yes, see the WixStandardBootstrapperApplication element.
> 
> On Sun, Sep 30, 2012 at 3:33 PM, Dave Steckler wrote:
> 
>> Looking through the archives, this has been asked a few times, but not
>> answered yet, so I thought I'd ask again:
>> 
>> Is there any relatively simple way to remove the Options button when
>> creating a Burn install? I'm
>> using WixStandardBootstrapperApplication.HyperlinkLicense, but with an
>> empty LicenseUrl to skip the EULA page. I have a simple install, and want
>> it to be nothing more than: "Install" -> "Done" (everything goes to a nice
>> default location under Program Files)
>> 
>> But it shows the Options button. Knowing my users, g*d only knows what they
>> might screw up with that...
>> 
>> Thanks,
>> 
>>Dave
>> 
>> --
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> -- 
> virtually,
> 
>   Rob Mensching
>   http://RobMensching.com LLC
> --
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn errors

[Kelly Graus]

Thanks for the replies!

Rob: I'm using version 3.6.2221.0.  I'll update to RC0 (the latest as far as I 
can tell) and see if we can get the customer to try again.

Pally: We are signing the bundle, the bundle engine, and the MSI file.  
Hopefully that should take care of any problems with AV.

Kelly

On May 24, 2012, at 3:38 AM, Pally Sandher wrote:

> Kelly I saw those same errors a while back which were caused by our AV 
> (Symantec Endpoint Protection v12) heuristic detection blocking Burn from 
> extracting stuff from itself when it was unsigned. We reported it to Symantec 
> but other AV products may have similar issues.
> Have you tried signing your Bundle & MSI? This fixed it for me before 
> Symantec updated their heuristic detection engine to be a little less 
> overzealous.
> 
> Palbinder Sandher 
> Software Platform Engineer 
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501
> http://www.iesve.com 
> 
> **Design, Simulate + Innovate with the ** 
> Integrated Environmental Solutions Limited. Registered in Scotland No. 
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park, Glasgow 
> G20 0SP
> Email Disclaimer 
> 
> 
> 
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com] 
> Sent: 24 May 2012 07:34
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Burn errors
> 
> What version of Burn are you using? Those sound like old errors that I
> think were fixed in more recent builds of Burn. The security ID issue could
> be a problem if they mucked up the permissions of %ProgramData% or certain
> parts of the registry.
> 
> The full line from the log file would probably help. 
> 
> On Wed, May 23, 2012 at 3:01 PM, Kelly Graus wrote:
> 
>> Hello all,
>> 
>> I am seeing a couple different errors on a customers machine when running
>> a burn based setup.  The setup is about as simple as you can get - the
>> bootstrapper just wraps a single MSI.
>> 
>> Initially the customer was getting the following error:  "0x800705ib -
>> This security ID may not be assigned as the owner of this object."
>> 
>> Then the customer changed "something" related to permissions (their
>> computer is run by an IT group, and they wouldn't give us more details than
>> that).
>> 
>> After the change, he then received the following error: "0x800700e8 - The
>> pipe is being closed."  He passed along a screenshot of the log file (I
>> have no idea why he couldn't send the actual log file, but anyway, see
>> attached).
>> 
>> Having him install the MSI file without the bootstrapper "worked,"
>> although it's not something we want to do if we can help it.
>> 
>> So my question is: Without any additional information, can anyone shed
>> some light on the situation?  I realize that I don't have much to go on
>> (since this is a customers machine I don't have access to it, and we
>> haven't been able to duplicate the problem on any of our machines).
>> 
>> If it helps I can pass along any of the .wxs files.
>> 
>> Thanks for any help!
>> 
>> Kelly
>> 
>> 
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>> 
> 
> 
> 
> -- 
> virtually, Rob Mensching - http://RobMensching.com LLC
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover al

[WiX-users] Burn errors

[Kelly Graus]

Hello all,

I am seeing a couple different errors on a customers machine when running a 
burn based setup.  The setup is about as simple as you can get - the 
bootstrapper just wraps a single MSI.

Initially the customer was getting the following error:  "0x800705ib - This 
security ID may not be assigned as the owner of this object."

Then the customer changed "something" related to permissions (their computer is 
run by an IT group, and they wouldn't give us more details than that).

After the change, he then received the following error: "0x800700e8 - The pipe 
is being closed."  He passed along a screenshot of the log file (I have no idea 
why he couldn't send the actual log file, but anyway, see attached).

Having him install the MSI file without the bootstrapper "worked," although 
it's not something we want to do if we can help it.

So my question is: Without any additional information, can anyone shed some 
light on the situation?  I realize that I don't have much to go on (since this 
is a customers machine I don't have access to it, and we haven't been able to 
duplicate the problem on any of our machines).

If it helps I can pass along any of the .wxs files.

Thanks for any help!

Kelly

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Globalized Bundle?

[Kelly Graus]

I'm very interested in the answer to this also. I will be working on 
internationalizing our installer in the next couple of weeks, and I was worried 
that we would have to go with the multiple MSI file route. If the localization 
files can be loaded at runtime that would be great!

Kelly

On Jan 9, 2012, at 5:53 PM, Ian Williams  wrote:

> Merging threads; just ensuring my reply doesn't get lost. Thanks.
> 
> -Original Message-
> From: Ian Williams [mailto:iawil...@microsoft.com] 
> Sent: Monday, January 09, 2012 11:15 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Globalized Bundle?
> 
> Hmm, I'm a bit confused here.
> 
> I'm under the impression that originally .wxl files were used for an MSI in 
> conjunction with a few options passed to light.exe (-cultures:ja-jp -loc 
> ).  And what you get it a Japanese localized MSI 
> (this is all compiled into it).
> 
> You're saying that the WixStdBA will look for .wxl files at runtime - great! 
> That's exactly the sort of thing I'm looking for, that should avoid the 
> creation of an installer for each language. But I can't figure out the usage 
> pattern here. If I add things like !(loc.ProductName) to my bundle authoring, 
> light complains that the localization variable !(loc.ProductName) is unknown. 
> So at link time I have to point it to a particular .wxl file... and we're 
> back where we've started! I also tried pointing light to multiple .wxls for 
> each language I want but that doesn't seem to work either.
> 
> What the piece I'm missing here that allows runtime localization decisions?
> 
> As an aside, the most important thing for me really is to be able to choose 
> the WiXVariable "WixStdbaLicenseRtf" at runtime based off of the system 
> language. Not sure if even runtime loading of .wxls will accomplish this.
> 
> 
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com] 
> Sent: Monday, January 09, 2012 12:36 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Globalized Bundle?
> 
> We do LCID because we still support WinXP SP2
> 
> On Mon, Jan 9, 2012 at 3:46 AM, Sam Morris  wrote:
> 
>> On Sat, 07 Jan 2012 08:50:15 -0800, Rob Mensching wrote:
>> 
>>> The wixstdba will automatically search for a .wxl file of the system 
>>> language (i.e. look in 1033 directory for english and 1041 for 
>>> german and 1044 for japanese, or are those last two switched?).
>>> 
>>> Failing to find a matching .wxl file will cause wixstdba to fall 
>>> back to a .wxl in the root.
>>> 
>>> There are a few bugs about localization open that need to be fixed 
>>> before this works well but you can see the beginnings.
>> 
>> Would you consider keying translations by the string representation of 
>> the locale name rather than the numeric locale ID? This will allow 
>> more intelligent fallback behaviour.
>> 
>> Currently if I ship a .wxl file in the 1031 directory (de-DE) then a 
>> user with a UI language setting of 3079 (de-AT) will not see the 
>> German strings, even though they are closer to the user's preferred 
>> language than the default strings.
>> 
>> > (v=vs.85).aspx> /dd374098%0A%28v=vs.85%29.aspx>> describes the UI language fallback 
>> behaviour in Vista and later. Emulating this on earlier Windows 
>> versions (that lack LOCALE_SPARENT info for a locale) seems 
>> straightforward enough: just chop off the hyphen and anything that 
>> follows.
>> 
>> --
>> Regards,
>> Sam Morris
>> 
>> 
>> 
>> --
>>  Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't 
>> need a complex infrastructure or vast IT resources to deliver 
>> seamless, secure access to virtual desktops. With this all-in-one 
>> solution, easily deploy virtual desktops for less than the cost of PCs 
>> and save 60% on VDI infrastructure costs. Try it free! 
>> http://p.sf.net/sfu/Citrix-VDIinabox
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>> 
> 
> 
> 
> --
> virtually, Rob Mensching - http://RobMensching.com LLC
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex 
> infrastructure or vast IT resources to deliver seamless, secure access to 
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> 
> 
> 
> --

[WiX-users] Burn digital signature

[Kelly Graus]

Hello,

I'm currently in the process of setting up a bootstrapper using Burn.  In the 
past, we've signed our MSI files so that we don't get the yellow unknown 
publisher warning dialog when prompted to elevate.  However, signing the 
executable generated by Burn doesn't seem to work - it looks like a temporary 
executable is being written out, and that is what gets elevated.

What is the correct way to sign the elevated executable?

Thanks!

Kelly
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users