My educated guess on what is taking place is that the COM Tables are being used to register various COM Libraries in the package. When your main application calls these, they are used as an entry point into the Windows Installer autorepair, but the application relies so heavily on them, the check that's performed each time the entry point is called causes a performance hit. When you build your repackager project, there's an Advanced setting in the project that you can disable, "Map registry data tot he appropriate COM tables". If you disable this and rebuild, it will register the COM Servers through the registry table, which is then not used as an Advertised resource, so there's no check when the COM class, types, progid, etc. are called. ... View more

This sounds like the "Unknown Error Occured" that I posted on a short time ago: http://community.installshield.com/showthread.php?t=164340 Basically, if it isn't giving helpful messages, just strip it down until you can narrow the cause to something specific. ... View more

A few pieces of information that will be helpful: 1. For what you're looking to do, you'll probably want to use the AdminStudio editor to create the transform--it exposes more granular MSI functionality. 2. For removing SelfReg entries, you can do this by unchecking the 'Self Register' option in the file's properties. To still get the file registered, use the 'COM Registration' view to extract the COM data. This will be a sub-view of 'Setup Design' or 'Components'. 3. When you add new files in a transform, it should ask you if you'd like to stream it into a cab inside the *.mst. 4. ICE errors are documented in our helpnet as well as MSDN. If you click on the ICE error when validating, it should link to some information on how to resolve it. ... View more

If the *.msi is an Installshield build package, there should be a series of custom actions that handle setting the All Users profile location. That said: 1. In 'Files and folders', right click 'Destination Computer' 2. Select 'Show Folder', and then 'ALLUSERSPROFILE' 3. Create a folder under this called 'Desktop' 4. Add your files If this msi isn't an InstallShield based setup, you might want to look into copying the custom actions and Directory table entries so that you can make this work in the same way in your transform. ... View more

Ah yes, it would have been an "Advertised" shortcut. That could certainly be an issue, as firefox has a tendency to update itself automatically. When an Advertised Resource is called (i.e. a COM Class, Shortcut, File Extension) it checks the integrity of the application, which will then want to Un-upgrade firefox. ... View more

KrakaJap wrote: Well I would if it weren't for two reasons... 1. it's branded with a third party logo 2. superiors say no 🙂 Any other ideas? You could use the AdminStudio Editor to change the branding...Or you could try repackaging 2.0 for Portable Firefox when it comes out--this is an easy repackage process: http://portableapps.com/apps/internet/firefox_portable ... View more

Not sure why they would not be captured consistently--like I've said, the transform wizard hooks the property table, and if they change, it should be captured in the transform. Do you see that it's inconsistently capturing the 'Uncheck' action you're doing? Because this is something I've not tested--this would undefine the property in the property table, rather than changing the value. I'd be interested to see if this was the case. Can you post an uncompressed copy of the *.msi package? This can be done by using the following command: msiexec.exe /a package.msi ... View more

Looks like there is a bunch of Custom Actions that aren't getting run during the UI sequence for some reason: MSI (c) (E8:B8) [16:57:10:832]: Doing action: CheckETACLTPrev MSI (c) (E8:B8) [16:57:13:352]: Doing action: SetCA_APPSWDIR MSI (c) (E8:B8) [16:57:13:914]: Doing action: SetECSDirScript MSI (c) (E8:B8) [16:57:14:336]: Doing action: SetINGNetDir MSI (c) (E8:B8) [16:57:14:667]: Doing action: FindCAI MSI (c) (E8:B8) [16:57:15:159]: Doing action: FindINGNET MSI (c) (E8:B8) [16:57:15:651]: Doing action: FindCAMCAFT These actions aren't present in the TRansform Wizard log, although I'm not sure why. If they were skipped because of their condition, there would be an entry similar to: Skipping Action: ActionName (Condition is false) These custom actions look to be InstallScript, and if the entry point numbers are any indicator, this is a VERY complex setup, as these start getting numbered at 'f1': MSI (c) (E8:0C) [16:57:10:892]: Invoking remote custom action. DLL: P:\TEMP\MSI2A1E.tmp, Entrypoint: f83 Difficult to say what exactly they are doing, but in a worst case scenario, you can see all the property changes that the custom actions are making in the log, and so you can account for this in a regular transform (although I realize this is very inconvenient). ... View more

Looks like what happened last time I ran into this was due to some files captured in the following path: [USERPROFILE]Local Settings I beleive there was a bug report submitted as a part of this to be addressed in AdminStudio 8.0. Do you see that there is data present here in your repackaged output? ... View more

Can you post the log you generated from the Transform Wizard? It should be possible to confirm whether this is the case or not. ... View more

I beleive if you leave the domain blank, and use 'Everyone' it should accomplish what you are trying to do. Per the LockPermissions documentation: "When you use Windows Installer 2.0 or later, the common user names "Everyone" and "Administrators" may be entered in English and are mapped to well-known SIDs." I beleive that this means that "Everyone" will always be referenced correctly, even when running on a non-enlish OS where the group name has been localized. ... View more

Logging still will help to address the issue. Since the response transform wizard is basically just launching the package, you can log it using the logging policy to see what's running amok. If you post the log, it should be evident what is taking place. ... View more

These are really, really tough to troubleshoot. Basically, you'll want to just start excluding file and registry data until it builds the *.ism successfully. Like a CS professor of mine once said, "Divide and Conquer". Start by excluding half of all data. Then when you find the half that lets you build successfully, exclude everything but one half of that subset, and so on... It takes a while, but eventually you end up with the culprit. I'll see if I can do some searching through old files and find the source of this problem the last time I had encountered it.... ... View more

This is possible with MSI, but fraught with little pitfalls. 2 things you'll need: Right click on the registry key when directly editing the MSI, or when editing the *.ism before building--this will allow you to configure permissions. This, quite often, gives some problems, so the second thing you'll need is the documentation on the LockPermissions table (which is populated by the above view): LockPermissions Table: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/lockpermissions_table.asp ... View more

I posted on this a little while ago: http://community.macrovision.com/showthread.php?t=157149&page=2&pp=5 Basically, sometimes properties are set by the setup.exe bootstrapper, and are necessary to avoid erroring out the UI sequence. Try logging it when installing normally and see what command parameters are passed. ... View more