AdminStudio does not recognise InstallShield MSI as one.

[yakboy]

Folks,

I must admit I am new to this packaging game, I've been playing with ORCA for a little while but I now need to do a lot more. One particular rogue package I am sure is an InstallShield MSI, I was expecting that the repackager within AS would detect it as one and launch the conversion. Alas it doesn't and simply reports "The current setup is an MSI setup..." (this occurs whether I use the Install Monitoring or indeed the reccomended single-step snapshot).

I believe the MSI to be an InstallShield MSI since it exhibits the following traits, if there is any other way of identifying an IS MSI I would love to know!:

1. You have to run a setup.exe to make it install
2. There is an msi in the same install folder but if you run it it demands that you first install the requisite isscript.msi from the install folder.
3. If you look at the msi in 'Customize' and look at the 'summary Information Stream' the author is 'InstallShield Software Corporation'. So it looks to have been developed using InstallShield.

Is there any way of forcing the conversion? I honestly don't think that in it's current state it's ready for deployment. I remember trying to deploy it to a few dozen users in the past in this MSI form and the vast majority failed. I pinned this to those clients not having the requisite ISScript.msi installed to work with this msi. Certainly can't push this out to several hundred people.

Any help much appreciated, still running on a trial at the moment and am totally stumped until I can get this thing coverted!

Tom :confused:

[Christopher_Pai]

I'm not sure what you are trying to do when you say convert it. Are you making a transform or trying to repackage the MSI?

It sounds like you have all your files needed to just push it with a simple command line.

Whats your deployment tool, AD GPO or SMS/Tivoli/etc....?

[yakboy]

Chris,

Cheers for the reply. For reference we will be using SMS for deployment. The past test was simply a GPO/AD deployment.

I am trying to convert an InstallScript MSI (my apologies just realised that these things are InstallSCRIPT not InstallSHIELD MSI's). If you look in AdminStudio helps index:
Converting
InstallScript MSI

You can see what I am trying to achieve. I really do believe that this particluar install is an InstallScript MSI and I just really want to convert it to a basic MSI to both standardise and to aid deployment. It is this ability to convert InstallScript MSI's that makes we want to fork out for AdminStudio instead of simply sticking with the free SMS edition and using a much cheaper package.

[dhogan]

yakboy,
If what you have is an InstallScript package, then it should have .msi file.
Only thing is, you're not going to find it in the setup folders.
Do this:
Run the setup.exe and when the Welcome dialog comes up, stop. Don't click next or finish, just let it sit.
Next, browse to C:\Documents and settings\\Local Settings\Temp
Your .msi will be in here somewhere. You can then take and put it out on your source folder for distribution via SMS using the standard .msi command line.

[Christopher_Pai]

This is assuming that the clients targeted by the advertisements collections also have the ISScript engine installed. You can always define two seperate programs and chain them together, or just use setup.exe to take care of it for you.

[dhogan]

yakboy,
When you ran your snapshot, do you recall if it prompted you to use InstallScript Scan to convert the setup?

[yakboy]

Christopher Painter wrote:
This is assuming that the clients targeted by the advertisements collections also have the ISScript engine installed. You can always define two seperate programs and chain them together, or just use setup.exe to take care of it for you.

That's the thing Chris! I've already got the msi visible but in the past when I attempted to deploy the msi using AD with GPO it failed on the majority of clients since they didn't have the requisite isscript.msi alreaady installed.

My appreciation of this conversion process was that it would leave me with a *standard MSI that could be deployed without any other packages. Perhaps I'm wrong. I was really hoping to be able to deploy this application as a standard msi.

[yakboy]

dhogan wrote:
yakboy,
When you ran your snapshot, do you recall if it prompted you to use InstallScript Scan to convert the setup?

dhogan, that's what I'm saying bud. When I run through the process exactly as described in the help files I get no conversion pop-up at all... simply states "this package is already an msi, we don't reccomend re-packaging msi's" and it backs up.

Any ideas?

[dhogan]

That's pretty strange....

Couple of questions:
1. Do you really need to repackage the app or can you use the default install?
2. Does the setup.exe have a silent or no-prompt switch? (run setup.exe /? to see what the options are)

The reason I ask, is if that's the case, you could just drop the setup files into your SMS source folder and run setup.exe with a switch and you don't have to bother going thru the whole process.

3. Since it seems you do have some sort of .msi file to work with, have you tried using it to make a transform?

[yakboy]

dhogan wrote:
1. Do you really need to repackage the app or can you use the default install?

Default install doesn't contain the product key required for install, I had created a transform for the msi before my last 'deployment' that included this key and it worked OK. Also there is a bunch of keys that should be created in HKCU that set the default paths. I was hoping to populate this information on first use of the application. It does not do this currently. And to top it all off I need to include a local folder creation script and a cusomised ini file.

dhogan wrote:
2. Does the setup.exe have a silent or no-prompt switch? (run setup.exe /? to see what the options are)

If it has then it's because InstallShield put it in there. When I asked the company about what keys to transform to do a bunch of different stuff they couldn't tell me which to affect. I had to go and find them myself (using ORCA, no easy task). My guess is that they have literally (due to customer demand) run their old setup.exe through intallshields install creator process a single time and dumped it onto their CD's. They know absolutely NOTHING about msi technology. Useful eh?

dhogan wrote:
3. Since it seems you do have some sort of .msi file to work with, have you tried using it to make a transform?

Yep and I can make one, I was just really hoping to remove a layer of complexity from my packaging learning by making this a standard msi to start wtih. For the life of me I can't figure out why AS doesn't see it as a installscript msi?

[dhogan]

I think maybe I wasn't clear enough on point #2.
Go to the folder or media containing your setup files and copy the path to your command line, then add /? after setup.exe
ex: \\server\share\folder\application\setup.exe /?
Run this to see if there are any command line switches that might allow you to bypass the serial number dialog.

BTW, what is the app you're trying to rollout?

[yakboy]

dhogan wrote:
I think maybe I wasn't clear enough on point #2.
Go to the folder or media containing your setup files and copy the path to your command line, then add /? after setup.exe
ex: \\server\share\folder\application\setup.exe /?
Run this to see if there are any command line switches that might allow you to bypass the serial number dialog.

BTW, what is the app you're trying to rollout?

Yeah I did that and you can indeed put the serial no. into the setup.exe /.... command line. What I can't do is sort out these paths in HKCU for each user of the machine, nor specify the creation of this nice empty folder, or change the path in the ini file to point towards this the network file protection.

The application in question is ASTA Powerproject.

[dhogan]

Tried to take a look at the ASTA Powerproject KB, but the tech support page needs a login ID and serial number. You might take a look in there.
From what I can see here, I would go the transform route and see if you can't get your ini, folder and user settings to stick in there. If not, you can run your transform from a batch file and include commands to import the reg settings and create your folder and ini file.
Another option is to see if you can't make an SMS package out of it or capture the setup with another tool like WinInstall Lite (free at MS) or Wise.
I'll keep my ear to the ground and let you know if I have any other ideas.
Good luck

[Christopher_Pai]

yakboy wrote:
That's the thing Chris! I've already got the msi visible but in the past when I attempted to deploy the msi using AD with GPO it failed on the majority of clients since they didn't have the requisite isscript.msi alreaady installed.

My appreciation of this conversion process was that it would leave me with a *standard MSI that could be deployed without any other packages. Perhaps I'm wrong. I was really hoping to be able to deploy this application as a standard msi.

This is why I like to use SMS 2003, you can chain installs. I'm not sure how to go about doing this in GPO. You might just have to advertise the IScript first or you might have to make a fake MSI that has some custom actions in it that sequence your two MSIs. Windows Media Player 9 deployment kit did something like this. Basically it was a setup.exe that was non-msi. They put together a wizard that generated a WiX project to build an MSI. The MSI had a product code so GPO would pick it up but all it really did was stream the setup.exe out of the binary table with a custom action. Very hackish, but thats what you have to do to get around the limitations of AD GPO.

Keep this in mind.... AD GPO is 6 years old. Wouldn't you rather be using SMS 2003?


BTW, you might want to read my opinion on Repackaging...

http://chrpai.blogspot.com/2004/12/chriss-rant-about-repackaging.html

[yakboy]

Chris, thanks for the link. Your views on packaging are damn similar to my own...I thought the task was very difificult to do well. You seem to edge towards the "nigh on impossible" view.

I have tried to express this view to my boss and dept. they don't seem to be accepting this is the case.

I will avoid re-packaging at all costs.

Don't get me wrong I really don't want to make my life more difficult by re-packaging an application that doens't need it. I was simply trying to cut a single stage out by having this as a proper msi.

By the way we have SMS2003, I might give this "deploy multiple packages in one go" thing a try.

Just wish that adminstudio would see that this installscript msi is in fact an installscript msi....

[dhogan]

Under the Advanced tab of your Program Properties, you just click the box for 'Run another program first' then put in the program command line.
I use it a lot.

[Christopher_Pai]

I wouldn't say impossible, but I would say it requires a skillset that few systems administrators and developers have. This is because Setup Development requires a mix of both development and administration experience and knowledge.

[dhogan]

I have tried to express this view to my boss and dept. they don't seem to be accepting this is the case.

Don't get too discouraged...All SMS guys have to deal with this type of thing once in a while. I had Senior VP once tell me he didn't trust SMS or the data it produced. When I asked him why, he didn't have an answer- just 'because'. Trying to actually explain how SMS or repackaging works to someone that like that can be frustrating at best. All you can do sometimes is nod your head and tell them you'll do what you can.
In your case, you may be able to explain that, according to one of the posts you read here on this board, the application in question may be coded incorrectly and therefore may not fit the standards of current msi repackaging practices.
...worth a shot.

[Christopher_Pai]

Oh the horror stories of I could tell of people trying to blame problems on "SMS Pushes"..... of course some of them would actually be true. 🙂

Repackaging and SMS Administration is a thankless job.... least it pays well. 🙂

[dhogan]

So true. It can be stressful sometimes, but I really do enjoy this type of stuff. (My dream job of throwing computers off of buildings to test their durablilty was already taken) 😞

[yakboy]

Thanks to both of you for your replies. I am going to give this "run this other program first" option a try.

The main re-packaging drive will soon be driven forwards... Hopefully by working with the boss on a few he can see what exactly is involved.

Thanks again and I'm pleased to have seen so many responses. Always good to find a healthy online forum. Give it a few months and hopefully I can be helping others too.