Software Deployment

when you run MSIEXEC /x {PRODUCT GUID} then Installer actually uses the local cached copy of the originally installed MSI, so even though you may have edited your deployment source MSI, that'll have no bearing on how your uninstall behaves. I think you'll have to find a way to put the System Variable Path back onto machines you uninstall this MSI from.

I am aware and agree with you posting. I have gone way from the msiexec /x{Prod ID} due to the problem identified and mentioned. But I would like to fix the MSI if at all possible...

I have done the same misstake creating a msi that remove registry etc when u uninstall. The only way to solve it is to make a batch file or VB that first uninstall the product then copy the files that has been removed and adds the registry kyes that u need. Ive run a msiexec /x..... /qb then copythe files u want to have and then u do a regedit /s ... to import the registry key i should work.
//Kallebaah

Well, maybe another way to tackle this is to alter your deployment MSI. Change this System Variable's "On Uninstall" value to "leave" then redeploy your MSI, then when your ready to pull the package from your fleet it'll leave that System Variable behind.

Thanks KalleBaah for your responce. I have created a VBS file doing this. I am hoping to fix the MSI so I can learn from someone else's mistake. Thanks again...

Fosteky- I am using AdminStudio and I'm very interested in your responce...I'm assuming the System Variable is the Registry entry in the MSI. How or where do you go into the MSI to incert an entry "leave"? I have gone into the Registry Table to try and correct this. I've also go into RemoveRegistry Table to see if the entry is list. In the RemoveRegistry Table their is no such entry. I'm thinking I am looking in the wrong table or area and I'm thinking that the +, -, and * are the wrong commands to use.

Here is what I was basing my theory off of.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/registry_table.asp

I think I found it. In the Component you want to leave you have an option Permanent (YES/NO). I have sellected YES. thanks for all of your help...

Why is leaving a Environment variable so important... To me leaving behind a setting in the environment variable section is sloppy, but this goes for any component, you should never leave behind anything that is not shared. The answer is simply and I think most people will agree...

Include your system variable in your new version of Oracle. Then if a user is getting rid of Oracle from their machine, they are actually getting rid of it, not just the parts you thought they should get rid of.

You said it best when you said "you should never leave behind anything that is not shared."...So what I am hearing you say is there are exceptions and this would fall into the exception category. If I removed the REG string other issues would come out of it. FileNet has an entry in the Environmental Variable Path. When Oracle got uninstalled via the MSI broke FileNet. This was not my project but I got called in when everyone seemed to have no answer to the problem. I have identified the problem as the Environmental Variable Path string got removed. This removal was done by the MSI. I have looked at the MSI and the Registry of the MSI to find the registry key/string was in the MSI. The actual resolution to the problem was to create a VB script to copy and append this information. A back up plan it to call on the updated Oracle MSI and do the MSI. Another possible scenario is to copy the registry string and use it after Oracle has been uninstall and the new version of Oracle has been installed.

The bottom line is the MSI created was most likely either created by a novice Windows Installer Packager or the intent of the MSI was to only be installed on newly built/imaged machines as the string is basically removing the path string and creating a new one in HKLM...What the packager should have done is created the string to create if not present and if it was present then it should append a value to it. My next goal is to find a way to append the string if not present. I'm hoping to find someone who has done this before to see if my syntax is correct. I believe using [~] in front of the string value in the MSI will do this but I don't have much history/experience with this variable in MSI's...

I appreciate your concerns with creating clean machines and this is my goal as well...


Thanks,
John

Please look up "Formatted" in the MSI.CHI.
Using "[~]" in the Registry table will only be replaced by a null character for REG_MULTI_SZ entries, thus append or prefix. A good example for this would be the Sources entry under "HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application".

For environment variables you should use the Environment table instead.

But to solve your uninstall issue I/we would need to know how you deploy/uninstall the package (AD/GPO, SMS ...)

We are using Altiris for the distribution of the package. Thanks for clueing me in on the Environment Variables.

I'm getting crazy results from the uninstall Oracle. As of right now there are two Oracle MSI packages. There is the old Oracle.msi that is the poorly written MSI and there is a new Oracle.msi that leaves the key/string behind. If I run either MSI to load the product and then go through an uninstall of the new Oracle.msi the key/string is left behind. If I have a machine that already had the old Oracle.msi loaded on it...Going through an uninstall of new Oracle.msi still removes the key/string. This is weird behavior. At this point we are using a VB Script to (export and import) (copy/append) the key/string. I'm using this problem as a learning tool to better our Windows Installer environment. At this point it doesn't look like we can use a MSI to leave this key/string behind without jumping through hoops. I am unsure why the uninstall of the new Oracle.msi doesn't leave the key/string behind?

I plan on working a little with the Environment Variables area of the MSI to see if I can tweak it to leave the key/string. This is critical to the deployment since the Environment Variable Path is used by some many different applications and how do you know if an application uses it or not?

*=name in the Name column would create the system env var name but would not delete it on removal. that's probably what you're looking for. there is no easy way I know of to know if any app uses a particular path; easiest just to leave it in, if in doubt.

*=name in the Name column? I'm unsure what I should be looking for? Are you trying to say look in the Component and at *=name? I'm sorry I don't understand...

sorry, I meant in the Environment table of the MSI

Very Nice!!! Thanks again for you wealth of knowledge and helping me build my knowledge base. I have run some tests and it looks like you still need to load the MSI with the logic in it prior to the correct removal of the app. I appreciate the time each of you have spent on this and I am striving to be the best packager I can be. Next year I plan on attending some Window Installer classes and a Wise or AdminStudio class. If you know of any other classes that might help my skill set let me know.

Thanks again to all,
John