Software Deployment

It depends on the size and complexity of the application. For example is the application just has files and few registry keys I would happily goahead and repackage the msi. But if the vendor given msi has lots of services, custom actions, and system32 files I'll try to modify with a mst.

I agree that few of the vendor given msi's lack in quality. But over the years it has improved- Adobe Acrobat related msi's are an example. They provide customizable msi's. Hopefully the vendors will realize to provide good msi's as software installation is the first impression a software can create for it's users.

Praveen

I think the best way to proceed is to come here to the community for assistance.

If this is a leading question for a recommendation to edit the MSI directly I don't think you'll find it here. The bottom line is that there is nothing you cannot do in an MST that you can do by editing directly. If there is added complexity because you are working with ORCA or some other basic tool, I highly suggest investing in proper tools.

Repackaging an MSI is against best practices for a reason as it is highly likely to result in issues down the road. Again, if something is wrong with the MSI, you can make any change you need via an MST. Then when the next update or patch comes out you will be able to apply it without any repercussions. If a situation arises where it starts making sense to repackage an MSI I would do it, but then don't use it. By that I mean, if you are really lost as to how to proceed you could very well repackage it in order to analyze what you've captured. Comparing that against the vendor MSI could expose where things need to be changed.

Finally, complain to the vendor! If nobody ever lets them know the trouble they are causing with their poor setups, they will never know to fix them. If only a couple of people complain it will not be seen as a worth-wile effort for them to fix either. If a setup is really bad, I recommend posting a form letter or email template detailing the problem here at the site. You can then request that the community help your problem be heard by also contacting the vendor with the message-- if a vendor gets enough complaints, they will see there is a real problem and the will find someone with the skills to correct these setup issues.

RE: >> If this is a leading question for a recommendation to edit the MSI directly I don't think you'll find it here. The bottom line is that there is nothing you cannot do in an MST that you can do by editing directly

I am trying to learn the thought process behind the folks here if they were faced with this issue.

Such as ... I would use this method ... , or this tool ... , to test this action ...

RE: >> If there is added complexity because you are working with ORCA or some other basic tool, I highly suggest investing in proper tools.

That is part of the issue. What tools to use, and why. I am a network administrator, not an application programmer, so when I open up an MSI in ORCA, I am opening up a raw database, with no idea what the data means.

The gist of my question was to learn more about alternate tools and methods.

RE: >> Finally, complain to the vendor!

Good answer, and in the past that has been the best tool available. The biggest issue on this front is getting to the right people in the vendors organization, and then getting the help, can be very time consuming.

Thanks for the input, greatly appreciated!

"There are applications that come with MSI's that don't work properly."
That's the first ;)
[/align]
[/align]"The problem is, the orginal Software Vendors do not create MSI's that comply to Microsoft standards. (Ton's of errors regarding wrong use of profiles and registry keys)."
Well, even Microsoft don't follow their own windows installer standard rules/guidelilnes.
I guess you are referring to ICE validation.
Start by test-install the package, if the application works then don't bother correcting the package if you don't know what your doing. It's more likely that it will get "corrupted" then fixed.

If the installation throw up an error the starting by installing with verbose logging to pin-down the action or resource (table entry) causing the error.
[/align]
[/align]"Best practice says, if the MSI already exists, don't recreate it, use an MST to modify it. When the MST that we create with Admin Studio doesn't work properly, we get into the dilemma's of what to do next."
Sometimes you need to break the rules and repackage the existing MSI as it may not work in your environment.
If you do repackage an MSI or modify it (directly or through a transform) in a manner that will change it too then the vendor upgrade/patch won't work in any case.

There is no general guideline to follow except try to fix it through a transform first for "smaller" changes/fixes or see if the vendor site has any support information on the current issue.

If nothing seems to work then try to repackage it, just have in mind that the original installation logic may be difficult to reproduce this in the new MSI if any.

ORIGINAL: bkelly
Finally, complain to the vendor! Give yourselves a treat and d/l the Client Access beta MSI from IBM. Quite apart from the fact that there are features missing from this installation compared to their InstallShield-driven one (only little things like 'Navigator', mind!), it is - or was when I last looked in November - an absolute mess, almost an object lesson in how NOT to build an MSI. Heaven help me, there were features still called 'Feature1', 'Feature2', etc! Now, I don't know about you guys but I kind of expect a company with the resources which IBM has to get the basics right.

I sent a detailed email to IBM (to a named contact I got from an ex-colleague at an old client) and even offered my MSI (which is feature-complete!) to them but I got zero response. I resolved to double my price if they ever did get back to me which, to date, they haven't.