/build/static/layout/Breadcrumb_cap_w.png

Validating MSIs in a small environment

I am trying to gauge the value of performing ICE validation on MSIs in a smaller environment of about 1000 users. I rarely see larger environments performing ICE validation or conflict checking. I know ideally you should be validating your MSIs all the time but in a smaller environment do you think this would be too much overhead to the application packaging process to really see a benefit?

0 Comments   [ + ] Show comments

Answers (11)

Posted by: rpfenninger 17 years ago
Second Degree Green Belt
0
That's a nice one. I never cared about the 'why'. It's just as plain as day that we always validate our .msi's in our company (1.500+ users and 450+ apps).
Furthermore we use a QA tool to check all packages against 100 more rules and we do the conflict checking (but only on Standard apps i.e. the ones we deploy to everyone).

It's our policy to resolve almost every ICE message that appears. Even some of the cosmetical ones.

I guess, we do more than really necessary but I feel good about it!
Posted by: kkaminsk 17 years ago
9th Degree Black Belt
0
If you talk to the Windows Installer team no MSI should have ICE errors and there is benefit in doing it. The issue in selling this approach is that you are fixing issues before they happen and that sort of stuff is hard to put a price tag on unless your environment is full of MSIs that are conflicting, not uninstalling correctly, etc... Unfortunately most companies I have done work for don't bother at all.
Posted by: AB 17 years ago
Purple Belt
0
When I first started using Orca - oh, many years ago now, I thought
"Hey, lets validate Orca.msi with Orca!"
You can imagine the results :)
Regards,
Al
Posted by: AB 17 years ago
Purple Belt
0
Pick an MSI, any MSI
Oh, you picked a Micro soft MSI...
Let's do a magic trick with it...
Let us validate it using their own logical rule set...
Humm....
Repackagers are more consistent than developers with regards to this type of stuff
Developers, even RobMen (in fact he's a big culprit), don't obey their own own rules
MSI = resources and relational database
Relational...
That's mainly what the validation rules are checking
But they are dum
Just like software developers who don't know the required stucture of an ini file
It's not rocket science - it's an ini file
I'm ranting - ignore me or listen and agree or disagree
Software vendors are often poor craftsmen
Packagers live off of their incompetenceYet still they moan "blah bah"
I want to visit the Adobe dev guys and laugh at their efforts and then hold their holds whilst they wait for their mums to arrive to take them home from work...
And I'm giving up drinking for New Year...
Blimey
They keep my mind active (working out what the hell they thought they were doing when they.....)
And I love them for it
Now, what was the question again?

We are software cleansers... validate... play by their rules... sleep soundly'er... 'ish

I do hope I'm not alone on this one...
Regards,
Al
Posted by: AB 17 years ago
Purple Belt
0
Before I leave - doesn't this beg the question...
Validate the major MSI's from the Masters - do they conform to the rule set?
Does anyone challenge this state of affairs?
Does anyone repackage - at the expense of non supported software?? Whatever that means - most s/w support I've experienced is pretty much down to the individual anyway...
Something has pressed buttons on me to prevoke this type of response
But I must say that I do get fed up with the................
Arghhhhhhhhhhhh...
Damn...
Adobe will take over the Moon... not coco colo
Al
Posted by: AngelD 17 years ago
Red Belt
0
I would recommend validating even in small corporate environment as you could prevent as little as repair loops. Such as mixed user/machine resources failing a repair if the user is not local admin. The validation and fixing the (only) errors doesn't take that long time.

1000 users isn't that small as in having a techy running around and fixing an application that has been deployed to all of them crashing something that a validation could have shown.

The customer I'm at right now has about 30000 users so there exist strict rules through the packaging process, such as fixing errors through validations and rigorous testing before deployment. They even have package quality verification to verify that the packager hasn't done major sidesteps with the package.
Posted by: AngelD 17 years ago
Red Belt
0
AB,
u must be drunk [;)]
Posted by: aogilmor 17 years ago
9th Degree Black Belt
0
It is often not straightforward how to resolve the errors when you do check for them. ICE 33 is the most common, IIRC. I also remember one (forgot the number, but using Wise Package studio) that happened in every single package. It would tell you there are files/folders in <some directory> and not any RemoveFile entries. WTF? i thought windows installer removed all the files it installed. IOW, if it installs the file, it removes it (during a removal) by the RemoveFiles action. Maybe it was just Wise's implementation of ICE validation, or the fact that I was the only packager, but I did not find it very helpful.
Posted by: AB 17 years ago
Purple Belt
0
Dude I'm not drunk on wine
I'm drunk on software...
It's intoxicating dude...
It - shhhh - it makes me want to - shhhh - repackage it
Because it's parents were absent and did a poor job raising it and so I try to keep it from going to jail
Do not pass Go
Do not collect £200
Bless time tones...
Very Best Regards,
Al
Posted by: kkaminsk 17 years ago
9th Degree Black Belt
0
That brings up a good point. I do believe that there should be some sort of peer review or QC process prior to releasing a MSI into production. I am going to try out enforcing ICE complaince since I am architecting the environment and see how it works out. I guess my worry is that there are no packagers where I am at and I hope that this QC process is not too much for a junior packager to understand while they are just learning the ropes with Windows Installer. I guess this is the fun of doing project work.
Posted by: AngelD 17 years ago
Red Belt
0
The benefit will be saving money on preventing protential problems that tech-people may have to fix and/or maybe totally reinstalling computers when something goes down the drain that could (maybe) have been prevented in an earlier stage. Conflict management is also recommended but if you can't sell this then just use the conflict database when something goes wrong to try to pinpoint which applications that may have cuased the problem(s). If you have junior packager(s) then make sure to set up guidelines for packaging (process) and technical test as in install application, test some buttons maybe some more functionallity of the application of course and restarts to make sure everything works afterword.. same goes for uninstall of the applications. Also documentation of the package so future versions may be easier to create or just having it as a reference for the record.

Don't know what packaging tools you/they will use but Wise Package Studio will have the conflict database to play with, guess InstallShield has something similar.

As you will design the packaging environment you will have the chance to make this easy on them preventing them or some other guy from redesigning it all ower again due to bad planning.
I wish you the best of luck!
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ