Make leaner .msi's
I've created quite a few msi packages that are being pushed out through Active Directory. They all go unattended, and users do not get any UI. It's been working great, but I'd like to take it a step further and optimize those msi packages.
Our infrastructure is pretty standardized, so I don't have to deal with Win9x types of OSes
So far, to improve distribution performance, we adopted some practices:
When creating a package from scratch with Wise, I can reuse a stripped down template - that works great. With snapshots, I have to manually go and do the damage. I'm looking into making this task a little bit easier...
Does anyone use or know of any msi optimization tools?
Our infrastructure is pretty standardized, so I don't have to deal with Win9x types of OSes
So far, to improve distribution performance, we adopted some practices:
- We as a rule do not store files inside the msi (i.e. we use "store uncompressed files externally" option).
- LIMITUI=1 whenever possible.
- I routinely use InstallShield repackager and Wise for Windows Installer, and my favorite thing is going through tables and stripping things out: dialogs, controls, events, resource binaries, entire tables. That makes packages lighter. Not a big deal when the application is pushed out through GPO, but it improves end user experience whenever self-healing kicks in.
When creating a package from scratch with Wise, I can reuse a stripped down template - that works great. With snapshots, I have to manually go and do the damage. I'm looking into making this task a little bit easier...
Does anyone use or know of any msi optimization tools?
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
Ilikebananas
18 years ago
Here's a tip if you want to use your template for snapshots:
- Have a copy of your template ready at the location where you will be working on your package.
- In the first dialogue of the setup-capture, in the field "Target Installation" specify the copy of the template that you have prepared in the previous step.
- In the same dialogue check the "Add/Update Resources in Existing Installation" option.
Now, the snapshot will be added to your custom template, instead of the default (wise) template.
Ilikebananas
- Have a copy of your template ready at the location where you will be working on your package.
- In the first dialogue of the setup-capture, in the field "Target Installation" specify the copy of the template that you have prepared in the previous step.
- In the same dialogue check the "Add/Update Resources in Existing Installation" option.
Now, the snapshot will be added to your custom template, instead of the default (wise) template.
Ilikebananas
Posted by:
DavidLock
18 years ago
Great post revizor.
Can you explain your reason for using uncompressed external source. In what way does this improve performance?
Do you have list of tables that you always strip out? How much would you say this effects performance?
Can you explain your reason for using uncompressed external source. In what way does this improve performance?
Do you have list of tables that you always strip out? How much would you say this effects performance?
Posted by:
revizor
18 years ago
The reason for external sources:
#1 - I can update files without the need to recompile the package. I use this a lot for apps that are getting minor updates on a regular basis. Just overwrite the files at the package distribution source, and GPO will do the rest of the magic.
#2 - when self-healing kicks in, msiexec rescans the .msi file and analyzes the tables to determine relationships between features and components. With external files, the size of the msi file is always smaller, so less time is spent reading data & discarding binaries. Therefore, progress bar moves faster.
As far as numbers go, it probably becomes noticeable once your msi's reach 500-700k in size. The smallest msi I ever compiled was around 90 K (wsi for it was 110ish). It was a configuration package for another application + some custom actions & active setup script.
Just for experiment, make a copy of an existing msi. If you 99% sure that your package is not going to raise any non-standard conditions, it should be a good candidate for optimization. Delete "Dialogs" table and run validation. You'll get tons of ICE errors, most of those will be clustered in related tables: controls, controlevents, etc. Drop those tables too. You'll get fewer errors. Then you'll get to the individual rows in the tables. Be careful with those. Test it before you roll it out.
You can also strip bitmap files out of the resources - those average 100K in size, and do not compress too well...
#1 - I can update files without the need to recompile the package. I use this a lot for apps that are getting minor updates on a regular basis. Just overwrite the files at the package distribution source, and GPO will do the rest of the magic.
#2 - when self-healing kicks in, msiexec rescans the .msi file and analyzes the tables to determine relationships between features and components. With external files, the size of the msi file is always smaller, so less time is spent reading data & discarding binaries. Therefore, progress bar moves faster.
As far as numbers go, it probably becomes noticeable once your msi's reach 500-700k in size. The smallest msi I ever compiled was around 90 K (wsi for it was 110ish). It was a configuration package for another application + some custom actions & active setup script.
Just for experiment, make a copy of an existing msi. If you 99% sure that your package is not going to raise any non-standard conditions, it should be a good candidate for optimization. Delete "Dialogs" table and run validation. You'll get tons of ICE errors, most of those will be clustered in related tables: controls, controlevents, etc. Drop those tables too. You'll get fewer errors. Then you'll get to the individual rows in the tables. Be careful with those. Test it before you roll it out.
You can also strip bitmap files out of the resources - those average 100K in size, and do not compress too well...
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.