Software Deployment

Hey renio,

Yep for both of your examples I would use a VBScript Custom Action. You can either embed the code into your MSI or include it as part of your installation and execute it at the end. As long as you have written your script with some decent error checking you shouldn't have any problems. You can also use Wise Script if you like but I prefer VBScript.

Regarding the uninstall side, you just have another Custom Action to clear up what ever you want (for example to remove the entry from TNSNAMES.ORA again) and condition the CA to only run on uninstall.

For applications that don't have a shortcut, I'd include a VBScript file (just a pop up message to say "App Installed OK" or whatever" as part of the installation and have the shortcut point to that. Then any broken keypaths will cause a component repair on first run, writing any missing current user stuff. Of couse for this to work properly you have to ensure you've contructed you package properly and validated / fixed you ICE errors etc. There are other ways around this (such as Active Setup) it just depends on how you want to handle it and what your company standards are...

Hope this helps,
Rob.

And now for a completely different point of view...

Since you're going for a 100% standardized environment w/ deployed MSI packages, both of your examples should be avoided as bad (or inefficient) practices. Custom actions should also be avoided, if at all possible. I'll go through your two examples to explain why, and I'll throw in CAs as a 3rd example.

Example 1: Oracle's TNSNAMES.ORA

IMHO, The default TNSNAMES.ORA file should only be used by Oracle developers, never clients. Look in Oracle's docs. The TNSNAMES.ORA text file in the Network\Admin directory is one of the last places Oracle looks for TNSnames resolution. The FIRST place Oracle looks is in the TNSNAMES.ORA file in the application's working directory. All of my packages that depend on Oracle have a TNSNAMES.ORA file included in the package in the working directory. That way, instead of 1 global TNSNAMES.ORA file, you have 1 per app tucked away in the MSI package. It turns TNSNAMES management into a no-brainer.
On rare occasion, you have an app with no working directory. Put those entries into a network based shared TNSNAMES.ORA file. Much easier to maintain. It also helps you maintain standardization because it prohibits you from having the same name pointing to different locations on different machines.
We have 3 levels of TNSNAMES resolution. Primary level is TNSNAMES.ORA in the app's working directory. Secondary is the global TNSNAMES.ORA file. The last is "Self-Managed", reserved for developers, which is the default TNSNAMES.ORA file in the network\admin folder. The "Self-Managed" TNSNAMES.ORA file is never altered by software distribution, it's literally self-managed.

Example 2: Mapped drives

Mapped drives are standardization killers. It's legacy technology, strongly limited by the alphabet, and usually highly inconsistent. A mapped drive can be defined differently on every machine in the enterprise. It's impossible to manage efficiently. If you convert them all to UNC, every machine is in sync. Retiring a server? Redirect with your DNS server. 1 change, easy as pie. Not so with mapped drives, which can literally be thousands of changes.
Sometimes you have a legacy app that just has to have a mapped drive. Well, then you just gotta do what you gotta do. But if you weed out all the apps that do not fall into the "must be mapped" catagory, you stand a good chance of not running out of letters. If you can erradicate the use of a mapped drive, do it. You'll make your life much easier.

Example 3: Custom Actions

CA's are a "last resort" feature. MSIs and CAs have a major fundamental difference. An MSI is a database containing the definition of an application's structure on a machine. It can be re-referenced, cross-checked, etc. i.e. When AppX is installed, this is what it needs to exist. CA's are a script, not a definition. i.e. "Set it and forget it". These can't be cross referenced like an MSI. Just an extraneous "by the way" in a self-repair.
Of course, CA's are essential. Sometimes it's the only way to get things done. But overuse will only hurt your standardization. If it can be accomplished in the format of an MSI definition, don't do it in a CA. CA's not not bring you closer to your ideal environment, where every machine starts out identical and has clearly defined "plug-in modules" (i.e. MSI packages) added to meet every functionality need.

... + what about user configurations for applications that don't have a shortcut (so no advertised shortcut that allows the config to be triggered)?
Forgot this one...
First, self-repair checks are envoked when an entry point into the MSI is envoked. Entry points are tied to keypaths in the MSI, so it doesn't necessarily require a shortcut to do what you want here.

An easy solution to this is to add a dummy .exe to the package that does nothing, just launches and terminates with no GUI interaction. Add a shortcut to it in the all users startup folder, put it in the same feature as your user configurations. If the user configuration features of your package are missing, that will trigger the self-repair for that user at login.

Thanks MSIPackager, VikingLoki and Wildhair for your responses.

The main purpose of my post was to see if I can get convinced that everything can be done by the MSI package itself (if needed via custom actions), because... 'in the past' we used to be able to handle anything (really anything) using VBScripting and a little mechanism that is triggered during user logon (run-key, which launches a script which checks sub-scripts to see if those have already run for the user logging on, if not execute the script(s) and thus enforcing user configurations).

So my worries are not in detail about how to handle this and that, but globally: can we do our thing purely in MSI... as I've read until now the answer is: no, you'll have to preserve some alternative to MSI.

Correct?

That's pretty much the case. I've just been on a Wise Repackaging course and was told that MSI cannot edit text files, except INI files of course. You can do most things in MSI, but certainly not everything.

Yes, it is unreasonable to expect MSIs to do everything. Think about how best to apply settings in your environment. I've been asked to "do a package" for some pretty weird things. Also, after applying user profile settings with an MSI they'll stick around unless you do some real fancy scripting to get rid of them. Usually this is harmless, in fact it is by design so that user settings aren't wiped out during an upgrade.

I like Viking's comments, but I think there are ways to manage CAs and TNSNAMES.ORA. If you have Wise you can put your CAs in a template for standardization. As for tnsnames, I like the idea of having one for each app, but if you're rigorous about managing your global tnsnames, you can handle that as a standalone package. Then, all oracle apps reference their own name in the tnsnames file.