Software Deployment

It has been said before by many, but it's importance cannot be over emphasized: it is more important to understand what should be included or excluded - and when and why - than it is to have a perfect exclusion list.

A fairly well known example would be including certain hardware registry keys when repackaging Acrobat 5. There are others, though, that require thought and knowledge that a simple exclusion list cannot provide.

So, yes, anyone else's exclusion list - like the one I referenced above - should be used as a point of reference and not a point of authority.

Craig --<>.

Thai, in our SOP for creating the package, we declare some files and registry entries that should not be in the package becaused they might have adversed effect when the package is uninstalled. You will need to create a policy for them when you can just delete them in the package!

The 2 reg entries that you said can be removed.. You can check out your newly created image of your operating system and you'll notice that they exists in the registry... I can give you other entries and files that should not be in the package but it could be different in your needs... [:)]

I'm familiar with a lot more of them, just curious how others have handled it - do you have a standard list that you axe from all of your packages? I'm building one such list, I can post it on here if anyone is interested in seeing it. I'm curious what some of the keys do though - has anyone taken the time to look up Bags to see exactly what it does?

Just a sunny Friday conversation

You're right. We have a standard list that we called "bad stuff".. Some of these entries do not have effect in the machine even if you do not include it in your package becaused they already exist there... Except if the values are changing and you know it is being used by your application. Don't know what those entries are for but they are included in our list... [:)]

we have a standard list of files and registries that need to be excluded in the package.
these fiels/registries are excluded during the final snapshot. some of the entries are not excluded if i feel they are not needed then i would check in a clean machine and if they exist i delete them this is how i make my decisions on these uneeded registry/file entries.

Thaiboxer,

Here is a thread you can reference that has an extensive list of excludes.

http://itninja.com/question/what-do-you-usually-exclude-when-capturing?&mpage=1&key=᤮

I always exclude the two specific branches you mention.



Craig --<>.

I have to mention PackageCleaner - this is a tool designed to identify this kind of junk in your package and explain it to you so you can determine if it should be removed. Currently the demo only lets you clean a provided MSI package, but I have it on good authority that a new "trial" version will be available soon where you'll be able to clean up to 5 of your own packages to get a better feel for its value.

http://www.packagecleaner.com

Is PackageCleaner keeping that royal PIA licensing strategy? We stopped using it because I became sick and tired of having to call them every time it was moved to a different or rebuilt machine. How about SOME level of trust that we won't exceed our license count, huh? The Big Brother approach pushed it right out the door.

I'd definitely recommend building your own exclusion list from scratch - can't be a good idea using someone else's as their environment / base OS build may be considerably different from yours...

This white paper covers lots of best practices - including creating your own initial exclusion list from scratch.

Regards,
Rob.

Wow! Thanks to everyone for the great responses!

Some of the exclusion lists I've seen are much more extensive than the one I have in place, but I totally agree with Craig that you need to understand "why" you're exluding something - don't just exclude it because someone else does.

Thanks again for all the input!

One of the easiest ways to determine up front worthless reg keys is to package a reboot. Simply start a pre scan, reboot, and post scan. This is commonly known as reboot trash.

ORIGINAL: craig16229

It has been said before by many, but it's importance cannot be over emphasized: it is more important to understand what should be included or excluded - and when and why - than it is to have a perfect exclusion list.

A fairly well known example would be including certain hardware registry keys when repackaging Acrobat 5. There are others, though, that require thought and knowledge that a simple exclusion list cannot provide.

So, yes, anyone else's exclusion list - like the one I referenced above - should be used as a point of reference and not a point of authority.

Craig --<>.


I totally agree because some apps....like adobe ones have a habit of slipping in keys that to most apps don't matter at all but they do in this case. If I capture an app and have any issues getting it to just run locally from that cpature....I'll recapture it with no exclusion list and lo and behold...sure enough its a few keys from the exclusion list that I needed.

Again in agreement - it is this knowledge that PackageCleaner aims to provide by describing and providing recommendations for any suspect items in your MSI.

One big limitation in evaluating PackageCleaner as a product was that you could only use it to "clean" the package provided with the demo. Now, a new trial version that lets you clean five of your own packages has just been released: http://www.packagecleaner.com/download

I love the "Reboot Trash" idea, Radia. I never thought of that, but will use it going forward.

Thanks!