Software Deployment

Are you publishing or assigning the MSIs in Group Policy? Also, are these being installed to the computer objects or user objects?

They are assigned and to the computers.

ORIGINAL: JK1150
anyone have any tips on how to avoid these or prevent them when I build my MSI packages? If you want to avoid deployment to sites with restricted bandwidth and/or laptops, I'd suggest you make your OUs more granular and create the GPO links accordingly.

BTW, this post would probably be better in the 'Deployment' forum.

Well, to be fair, he did ask specifically for tips on packaging.
From your post i gather your biggest problem lies with the auto-repair of usersettings in a package, so the obvious tip would be to avoid putting usersettings (registry and/or files) in your MSI. A lot of software will work without defining these settings in the MSI, just test this thorougly with different testuseraccounts.

Another tip is to include the usersettings in the main (single) feature of the MSI package. Or you can split the MSI in two separate packages, one for the machinebased install and one for the usersettings (shortcuts, registry etc)

I thought about that before posting but, logically, either way, the package still has to be deployed and will thus prompt. If the prompt/progress dialog is to be avoided, then the entire deployment has to be avoided. You can't have one without the other. Even if you moved the user-specific stuff to, say, a push via some kind of script, the 'slow network/laptop' issue doesn't go away. Tricky...

True, true..
Maybe as last resort he could try some kind of local caching of the packaged MSI's. Still, with only AD deployment he would always have problems because of its lack of 'feaures'.