Software Deployment

Hi Blueboy,

Hmmm interesting, seems a rather convoluted way to ensure users can't install software when you could use the method of making people member of the Users group, therefore not having rights to install software anyway. But I'll assume you have good and just reasons for not doing that.

Instead of having a script that asks the user, that then launches the MSI, if I had to do it this way I would set it up as follows:

1. Launch the MSI, which runs a custom action (VBScript) that asks the user for the password
2. Have the script set a key in the local machine registry with the password in it (possibly encoded if you are worried about them using their l33t hax0r skills to read the registry, which is all the more reason to take them out of admin groups I say)
3. Have another script that reads that registry key and unencodes it if required, and sets a property equal to that value:

Dim WShell, DISKID

Set WShell = CreateObject("WScript.Shell")
PW = WShell.RegRead("HKLM\SYSTEM\Software\Blueboy\Password")

Session.Property("PASSWORD") = PW

The above script was lifted from an excellent post from Scotty.

Have the first script that asks the user run ONLY on install. The other one that checks the key and sets the property must be run on install AND repair AND uninstall. I think that should work. Maybe. Make sure you test install, repair and uninstall though.

Hope thats helped

Rgds

Paul

Thanks for your suggestions but here's the reason we're doing it this way.

We are using a deployment server and groups to manage the installation of this application so it works fine for 80% of our environment, however, there are some users, primarily laptop/remote users that do not connect to the deployment server unless they are on a LAN connection. So we send out CDs to techs to install maintenance for all the applications they might be missing. Hence, the need for a password on the MSI package. The CD that will contain the MSI package has some logic associated with it to uninstall the previous version of the application then install the newer version, but the password that I am trying to incorporate into the MSI is intended to stop users/techs from exploring the CD and inadvertently running the application install on his/her own and modifying the install settings we are deploying. Prompting the user/tech for a password isn't fesible since we don't know how many CD's are going out and we can't just advertise the password to everyone.

By adding a PASSWORD property, setting it to "null" and adding a Launch Condition, PASSWORD ="h4x0r" we can incorporate the password in the install line:

msiexec /i oem.msi TRANSFORMS=install.mst PASSWORD=h4x0r /qn

This is embedded in the autorun script on the CD so the user/tech will only have to insert the CD and let it run to install the application with the customizations we want in the environment. Some users/techs in their wisdom will think they can install it on their own and will try to use the MSI but they are not 1337 so they won't have access to the password that allows them to manually install the app and deploy the wrong settings out to the enviroment.

Now, my problem is not embedding the password or installing the application but the REPAIR function of the application does not seem to work with this package. I have done it in the past with other packages with success, so I suspect that this vendor MSI is missing a command or has some condition in a different order. I am looking for help or advice in allowing the application package to Repair itself in case any components are corrupted or deleted from the user's computer.

I hope this clarifies my problem. I appreciate your help and advice in this matter.

Hi Blueboy,

OK I think I understand what you are trying to get at now, basically you don't trust your own techs to not install the software on more PC's than you want? I still think what you are trying is a pretty weak defence, anyone with any kind of knowledge should be able to work out how to install it but I can see its about best efforts and layers of security and all that. All of that aside, you have a problem and need a technical solution.

Are you dedicated to the password solution? I can think of many other ways of obscuring how the installation happens that will not require a password that would be easier for you and harder for the end user/tech to figure out how to manually install the software, change settings etc. Off the top of my head, using iexpress.exe from the IEAK to create a self extracting .EXE that runs the installation with command line options you predefine in the exe is one good way...

Possibly letting us know what the application is, or posting the relevant actions and conditions on said actions and the sequence might help if you are still keen to follow the password method. Or perhaps others will chime in with even better ideas...

Not knowing your situation or anything, every organisation I have done work for has had the same issue of remote support, and we have pretty much always cut CD's/USB hard disks/whatever, with an installation .vbs, or .cmd file that runs the installation with the options we want and given the techs documentation on how to install the app. I have very rarely found problems where they decided not to follow the documentation and manually install the product choosing different options, and when this has occured its highlighted issues with the staff competency - its about trust within your staff. That said, I have no idea what your situation is and I can think of a few scenarios where this might be a little too much trust :)

Sorry I can't be of more immediate help.

Rgds

Paul

A Up,

I think one way to stop the LaunchCondition be evaluated during a repair would be to add the NOT Installed (case sensitive) condition to the LaunchConditions action in the InstallExecuteSequence and InstallUISequence tables.

Cheers Nik[:-]

A up duck.[;)]

There's another issue here.

Public property values used on the command line during installation are not remembered for subsequent reinstalls/repairs. Unless you have a way of dealing with this, you could face similar issues again in future. By using a custom action to store your public property values in the registry you could solve this problem as well as other problems in future.

Um...

I must be missing something. Is there a reason why you wouldn't bypass the whole password stuff if INSTALLED = True? All you're really concerned about password protecting is the install, right? Skip it for everything else.

Seems like a no-brainer.

Trying to explain why we are putting a password on an MSI is a irrelevant because it's policy here for any critical application that has to go out to remote users, trust or no trust. Sometimes the best intentions don't always turn out favorable, so it's not that we don't trust our staff, we must ensure that our application is deployed properly - with the settings intended to be deployed.

The app in question is AT&T VPN Client which is not the most friendly package out there. It is also a vendor OEM MSI because of it's complexity and custom actions we are only using ORCA to modify it. Thus making the PASSWORD solution the easiest to apply. (ie. Add a property and add a launch condition).

We also use RADIA as our deployment option, and it's definitely not the easiest to work with in terms of deploying MSI's, and it's even worse with EXE's so creating an EXE is not a desired option. As a packager there are many things I'd like to do in our environment to make the application deployment process more efficient but I do not outline the corporate policies for our system environment.

Cheers!

Ah, I see. You have to look at the MSI script through the convoluted ORCA view. Yes, that makes no sense to normal humans.

The vendor is probably adding tricks of their own and it's conflicting with your trick. Have you looked at the MSI in Wise or InstallShield to see how your launch condition is fitting in? You may not want to use the results that either of those editors would produce, but there's no reason why you can't use it to get a better idea of what's going on, and where your trick is fitting into the picture. You may see that you'd want to change the InstallExecuteSequence number.

If you see that your launch condition is in a spot that doesn't make sense, change it in the "big" editor and see how it changes the tables. Translate the relevant changes to ORCA, minus all the proptietary bells & whistles.

Thanks for your advice. I have used Wise to check the MSI and used ORCA to edit the values in the table and save the changes, therefore not recompiling the vendor MSI. I think Nikolas' advice helped me out a lot, the package will now self-heal without checking for the launch condition.

Thanks for the help Nik, your solution worked wonderfully and it was very simple.

Cheers!
Blue