Possible isscript error fix...

[em-jpk]

I am battling the isscript error pretty much every day at the moment. We deployed Isscript7 with group policy in 2002 and have been suffering the consequences ever since. ie not being able to install any other applications that require a newer version of isscript. only solution has been to rebuild the computer, install required software then allow isscript to install so we can install the app (Mathcad 11) that required version 7. Have just had success using a suggestion I picked up on this message board.

Modify the original msi by merging the isscript merge module (redistributable) of the correct version. (version 7, 8, 9 or 10) - with most of my applications its working brilliantly. I'm not sure of the technical definition but it seems to nest the isscript within the package. So the application installs it as part of the install rather than before commencing the install.

Now I'm backtracking trying to add the version 7 merge module to my initial Mathcad package so we can get rid of the initial source of our problems. doesnt seem to be working as it requires version 7.4.0.377 and the merge module is version 7.0.

If anyone has any suggestions, I would be most greatful.

[beaucoup]

We had this same problem, and i got the same response as yourself defly silence (i think what we are trying to do is frowned upon round here;). We also tried using the msm's and came unstuck just as you are (the msm had a lower version than what we needed installed.) We have found a solution, and I've been meaning to share with this forum but never quite got around to it. Now here's a chance (sorry it took so long I don't keep up with this forum as much as I'd like)

The reason (as far as i could tell) that installing the isscript.msi's via GP is causing problems is the way the isscript(7-9)msi's are created. They all have the same GUID's this isn't a problem when running them from the command line or as part of the setup.exe (the reason for this is below), but when deploying them as an assigned application via software installation, group policy does its "keep the application installed even if the user tries to uninstall it" thing.

Because isscript7.msi has the same guids as 8 and 9, the additional isscript.msi's aren't able to be installed as windows thinks its already installed, and causes alsorts of mayhem, If you have a look in the arp list / hklm\software\microsoft\windows\currentversion\uninstall\ you'll probably see a listing for isscript7 or its guid. These aren't normally there when running the setup.exe or even msiexec /i isscript.msi /qb as some how these bastardised isscript.msi's automatically uninstall once the relevent files have been added / components registered.

The solution we came up with is to wrap a msi around each of the isscript.msi files. Basically we created a isscript8installer.msi which had custom actions to install the relevent version isscript.msi file) these can then be installed using group policy and because the isscript.msi is called from the msi gp is controlling rather than from gp itself it can do its install-and-remove-itself trick which gp still being able to control the initial installation. we now have one of these for each version 7, 8, 9, 10, 11 they have different product keys to allow each version to be install at the same time. if a new version is released the version of the wrapper is increased and rebuilt, and gp is then used to do an update. easy (sort of;)

We did have some problems with the version 7 isscript.msi because is didn't use a short filename on one of the files inside the msi. so an mst was created to change this. from there it worked fine.

We had this same problem, and the forum remained silent while we battled though it (i think what we are trying to do is frowned upon round here ;). We also tried using the msm's and came unstuck just as you are (exactly the same as your problem the msm had a lower version than what we needed installed.) We have found a solution, and I've was meaning to share with this forum but never quite got around to it. Now here's a chance (sorry it took so long I don't keep up with this forum as much as I'd like)

The reason (as far as i could tell) that installing the isscript.msi's via GP is causing problems is the way the isscript(7-9)msi's are created. They all have the same GUID's this isn't a problem when running them from the command line or as part of the setup.exe (the reason for this is below), but when deploying them as an assigned application via software installation, group policy does its "keep the application installed even if the user tries to uninstall it" thing.

Because isscript7.msi has the same guids as 8 and 9, the additional isscript.msi's aren't able to be installed as windows thinks its already installed, and causes alsorts of mayhem, If you have a look in the arp list / hklm\software\microsoft\windows\currentversion\uninstall\ you'll probably see a listing for isscript7 or its guid. These aren't normally there when running the setup.exe or even msiexec /i isscript.msi /qb as some how these bastardised isscript.msi's automatically uninstall once the relevent files have been added / components registered.

The solution we came up with is to wrap a msi around each of the isscript.msi files. Basically we created a isscript8installer.msi which have custom actions (type 23 (New nested MSI -> On Source Location), which are only run during the install execute sequence with an install exec condition of (REMOVE<>"ALL") to install the relevent version isscript.msi file. These wrapper msi's can then be installed using group policy and because the isscript.msi is called from the msi gp is controlling rather than from gp itself it can do its install-and-remove-itself trick with gp still being able to control the initial installation and updates. We now have one of these for each version 7, 8, 9, 10, 11 they have different product keys to allow each version to be install at the same time. if a new version is released the version of the wrapper is increased and rebuilt, and gp is then used to do an update. easy (sort of;)

We did have some problems with the version 7 isscript.msi because is didn't use a short filename on one of the files inside the msi. so an mst was created to change this. from there it worked fine.


Hope this makes sense, if you would like some more info a look at our wrapper msi's, plz message me 🙂

Regards

Andrew

[em-jpk]

thanks for the reply and suggested workaround. Would be helpful to see what you have done, I have tried following you custom action instructions but keep coming unstuck. Every time the file I specified in the "on source location" is not added to my package.

thanks 🙂

[beaucoup]

Sorry it took so long to get back about this.


Setting it to on source location won't add it to your package. You need to copy the isscriptXX.msi files into the same directory as the installer msi.

If you want the new installer to build the isscirpt files into the package (into the binary table), you just need to use the New Nested MSI -> "Inside this package" instead of "on source location".


Doing it on source location means if deploying via GPO you can just copy a new isscript9.msi file into the directory with the installer and choose thhe redeploy option, rather than having to build another msi each time a new isscript file is released, then setting the GPO to do an upgrade.

Hope this helps 🙂

[Minkus]

Hi,

I have posted instructions as to how I created an MSI wrapper for ISScript8.msi using free tools (WIWW and Orca) to AppDeploy:
http://www.appdeploy.com/packages/detail.asp?id=725

Hope this helps anyone else trying to do the same.

Chris

[Christopher_Pai]

You should check out the InstallShield 12.5 Beta2. InstallScript has been refactored to compile into Type 1 Custom Actions ( Windows Installer DLL ) and the entire ISScript.msi is deprecated.

[bilbus]

I have found a fix for the install shield (isscript) nightmare.

If you deployed isscript via AD and now having problems installing anything with a isscript.msi i have a fix!

Install and run the "Windows Installer Cleanup" on each computer.
remove "isscript" or what ever you named it inside of AD.

now the windows installer is no longer linked the isscript file!