File Overwrite Problem

[JXBURNS]

a) Have a MSI built (by me) using a third party installer which is installed on (XP SP2) clients from Group Policy on (WIN 2003) server. Installs fine.

b) Now have a new version of application to install and having abandoned the third party app, am using SUFWI (1007) to create from scratch. The MSI on a clean system works fine.

c) I now need to remove the old app in Group Policy and install new. I initially tried forcing a removal and install new in same session i.e. when client rebooted I could see 'removing' and 'installing' one after each other. However found the old version still existed and files from the new MSI, which did not exist previously, had been installed but not any newer versions of the same file name.

d) Then tried the GPO option of having both MSI's in the Software Installation list but changed the properties on the new MSI to force a uninstall of the old one first. Still same problem. Then altered the upgrade properties to replace the existing application - still same.

e) Then tried running new MSI manually leaving old version installed. Only the repair (and remove) options existed (to be expected). Chose Repair and system went through process but still the files were not overwritten. As a test did a remove, then deleted folder manually, then installed new MSI manually and worked OK.

f) Not knowing why GPO is not removing the old application first I would have expected the MSI being manually run to overwrite the files that exist already. The verbose log indicates nothing about failing to overwrite.

g) As a further test, on clean system, manually installed old MSI, manually installed new MSI, (same problem - original files not overwritten), uninstalled new MSI and found it not only removed the files it had installed but the ones installed by the old MSI which had not been upgraded by the new MSI.

h) Tried making the newer files set to VITAL but made no difference.

I know Windows Installer standard is to overwrite a file if newer and I checked the third party app to make sure the original install was not set to permanent. So I am at a loss why the newer MSI is not overwriting files installed by the older non-SUFWI MSI either through Group Policy or manually.

Any thoughts?

Thanks - John

[Brett]

John,

Do both the new and old installers have the same product code? What about the upgrade code? Are both products installed to the same folder? Do all components have the same GUIDs?

I need to know more details about how you authored the new version in SUFWI. You see, if you just add the files and set the destination folder (INSTALLDIR and subs) the same I can see why that would not work because the component IDs would be different between them.

As I see it, your options are:

1. Try performing a major upgrade by using the upgrade codes (see the help file).
2. Install the new version to a different folder on the system.
3. Either include a bootstrapper or manually uninstal the old product first before installing the new one (msiexec.exe /x{OLD-PRODUCT-CODE})

-Brett

[JXBURNS]

Brett,

I think you have misunderstood me. The original MSI was NOT built using SUFWI but another company's installer therefore all of the GUID's will be different between the two.

The new MSI was built using SUFWI so Windows Installer should consider them completely different products and should not care less about version control other than overwriting if newer files being installed. It works for brand new files so I do not understand why it does not overwrite the older files. Obviously in SUFWI there is no 'always overwrite' as in SUF7.

If they were both built using SUFWI then I would not envisage any problems as per your suggestions. Note that the final installation is under Group Policy where there is no manual intervention as pushed out to clients at boot time.

Thanks - John

[Brett]

John,

I understood you. The other product was made in a non-SUFWI tool. I was just wondering if you went to the trouble of making all of the component IDs match up manually - which you didn't (and I don't blame you one bit) ;)

Although I do not know the inner workings of the Windows Installer engine, I assume that it has a rule internally that doesn't allow a component to be installed to the same directory with the same filename as one that is installed as a different component.

So, as I see it you are down to two options:

1. Find some way outside of MSI to make sure that the old app is uninstalled before the new one is installed.

2. Install the new version to a different folder on the system.

[JXBURNS]

Brett,

Most definitely did not match up GUID's.:) Even if I wanted to the other installer does not list them like you do - one of the many reasons I dropped it.

I think the strange thing here is when I tell Group Policy to uninstall the old one and install the new, all the indications from log files, event viewer etc. suggests this has been achieved in the correct order. It is now obvious it does not do the job properly. If I tell it just to uninstall the old package, it does it brilliantly. I have a few GPO books here so off to dig deeper...

I also suspect there are two problems. One is the GPO not doing as I expect it should. The other is Windows Installer thinking it knows best and will not allow the same named file to be overwritten unless it is part of the same MSI package (or a major upgrade of a package).

As this is all supposed to be automatic with the user just having to reboot their PC once to uninstall old/install new. It now looks like it will be a case of remove old package from Group Policy, tell all users to reboot, install new MSI, tell all users to reboot.

I just love Windows Installer!:D Thanks for your help.

[Eagle]

John, would the Windows Installer Cleanup Utility have a possible
use for you, if you have the Old {Product Code}.

just a thought, may save a second reboot .

[JXBURNS]

Good idea but already done that bit. It does not list the original MSI after it has been uninstalled (or at least told to uninstall) even though the files/folders still in place. Have used that as well as the equivalent MSIZAP without success. To be honest I don't think Windows Installer is being that intelligent - or perhaps it is. I suspect there is a simple flag that says 'do not overwrite files in same folder as I am installing into unless the MSI I am processing put them there in the first place'. It could be argued that Installer should be allowed to totally handle things but I do like a bit of flexibility.

I think I may have a workaround based upon Brett's suggestion of using a different install folder. Was hoping not to have to due to icons being in several users roaming profile folder on the server but I also have a SUF7 project to build to install WSUS updates to the server. So can add a bit of scripting to that & alter the existing icons to point to the new folder. So should be a case of having the administrator (actually the ship's captain) run the SUF7 setup, get him to remove the old MSI from the GPO, add the new, tell the remainder of the ship's staff to reboot their clients and system should uninstall old, install new and I will be a happy bunny (hopefully!).

I will be back if I come across any other problems...

Thanks - John

[Eagle]

Yeah, short of bootstrapping a 'hard file delete' post cleanup util,
but thats gett'n rough as ... I would be interested in any other
solutions to the apparent lack of overwrite with winstaller, you
come up with, short of Brett's angle of attack and yours thus far.

tks

[JXBURNS]

Not trying to let this beat me...

I took the product GUID of the original MSI and applied it to the SUFWI version. Then took the 'Revision Code' from the old MSI which looks like it is the same as the upgrade code in SUFWI. Added this both as the Upgrade Code in Project Settings plus into the list of Upgrade Codes setting the minimum value to 1.0.0 and inclusive. The original app is version 1.0 and the new one is 5.0.1. Created a build.

On client installed the old MSI, checked working and then tried to manually install the new MSI. System now tells me that 'another version of product is installed and installation cannot continue' telling me to remove old version via control panel. This is encouraging but I had hoped it would uninstall the old version automatically due to the upgrade codes being the same as the original revision/upgrade code.

I believe there is a way to force the system to uninstall the old version first probably by setting a property value but I have no idea what to set and in what sequence. I checked out REMOVEEXISTINGPROPERTY action in MSDN without any success as relates to a script based system. Any further ideas?

Thanks - John

[Brett]

John,

In this case you want to look at the UpgradeCode property in the old installer. Open the msi file in Orca and then in the Property table, look at the value of the UpgradeCode property. You will want to use that same value as the Upgrade code field in your SUFWI project. You DO want to change the product code in the new installer though. Changing the product code but keeping the upgrade code the same will result in a major upgrame situation.

[JXBURNS]

Thanks Brett. I'll have a look at it again tomorrow as my server has gone to bed for the night and so must I.. Rgds John

[JXBURNS]

Brett,

OK changed the product code in the new MSI and then added the 2 upgrade codes (I have 2 previous MSI). Built and run. This time system came up with the normal install procedure (nothing about upgrading) and afterwards, same problem exists in that the EXE is not being overwritten.

Having looked at differences between what the 2 x MSI's are trying to achieve the only change is the one EXE; all of the other files are either new or same as previously. So thought perhaps I could make the EXE's GUID in SUFWI version same as older versions. However neither in the 3rd party installer software nor in ORCA can I see the GUID in the old MSI. In fact in ORCA there are no files listed under FILE and only one entry in COMPONENT so how it knows what to install I do not know. The SUFWI MSI has listed these OK.

So on a different tack I started to delve down into the MSI install log and found an 'existing file has a newer version' entry for the EXE. The earlier logs never had this and I never bothered to check the EXE file versions - why would you when suppliers stated they are newer? Checked the versions and for reasons unbeknown to me the new file has a lower file version than the older one (0.8.1.515 vs. 3.8.0.253). Hence the reason it is not overwriting.

So I guess I now need to ask if there is any way to force an overwrite regardless of file version previously installed? Or any tool that will allow me to change the version of the new EXE - I tried with a hex editor but could not find any of the versions anywhere.

Thanks - John

[Brett]

Ah, checking the log file - always a good idea. To change the executable's version, you can use a resource editing program such as Microangelo (http://www.microangelo.us/) or Resource Hacker (http://angusj.com/resourcehacker/). However, one thing that you could try is changing the version in the File table in the MSI file using Orca.

Open Orca, find the File table, locate the executable in question and then change the Version column value. I believe this will force a "hacky" overwrite. The best option would be to change the executable's resource info directly, but this might work as well. Let me know how it goes.

[JXBURNS]

Brett,

Have had success finally albeit with hiccups. Thanks for resource editor links. My googling this did not find - obviously keywords I used. Changed the exe to new version and SUFWI showed OK. Rebuilt. Tried installing manually and bingo, version was updated OK.

So then back to clean system, reinstalled original MSI through Group Policy, proved worked & correct version, then added the new MSI again through GP without removing the old. The properties in both GPO objects updated automatically to show new MSI would upgrade old whereas before I was adding this manually. Rebooted client but strange. It removed all the files installed by the old MSI OK but did not install any that were common between the two instead leaving just the additional files from the new MSI that were not in the old MSI. The MSI log has no words of wisdom.

Ran the new MSI manually again, it went into repair mode, and the files were installed OK. No idea why it failed first time round.

Then started again with clean, installed old, rebooted client but this time I told GP to remove the old and install the new in one go. Voila. It did exactly as I asked and installed all the new files. So happy bunny.

I'm sure there is still something not quite right as should be able to add a new MSI into GP as it obviously works out what to update from the upgrade codes. I know none of this is a SUFWI problem which appears to have done exactly what it should have. More a case of a steep learning curve for me on how to upgrade an old MSI to new. It would have helped if I understood it does not matter who or what created the MSI in the first place.

Thanks again for your patience and help. I know have another non-SUFWI project to upgrade to SUFWI so I can practice my education.:lol

John