forum.opsi.org

Hi,

I'm experiencing something rather strange with a new installation I am trying to perform (a simple MSI) : if I run my script logged on Windows (admin) and using winst32, it works perfectly.

But if I ask OPSI to install the product running the very same script, on next reboot or by executing it immediatly, the installer hangs during the process.

I even tried to use the local admin way, it is the same.

There a few popups which need user interaction, but I have covered that with AutoIt and it is working perfectly on "winst32 mode". Even in normal mode, the first ones are processed, before the installer hangs.

As I am using a virtual machine to test the script, I revert to a snapshot after every try. So it is always the very same environment.
It is using a normal amount of CPU and memory, but once it hangs, the cpu load and memory usage fall both to near zero.

I can play with ALT+TAB, but I see no new window of something like that. If I kill the stuck MSI, it closes and I only get the blue OPSI background, with a hung progress bar.

I have several dozens of MSI based installations running with OPSI, but none had such a problem.

Any idea of where I should look ?

Regards

Hi,

some AutoIt functions often don't work if the Desktop is locked, especially winwait, winactivate or send. Do you use one of these? You have to run the script in the context of a logged in user. I thought this would work with the local admin template. Maybe you can try the integrated Windows Administrator account?

Regards

Thanks for your reply.

I also tried without AutoIT, with "/qf" flags. I can answer all the questions manually, and the installation is successfull if I run it logged in.

But if I let the agent perform it, I can answer the questions but the installation hangs.

Naming the program you are trying to install would (maybe) help.
Any hints in the MSI-Log?
When using the 'local admin template', you are absolutely sure, that an user besides system is used?
Checking with ProcMon where the installer wants to write to might give some hints.

Hi,

please give us information about how to reproduce the behaviour (what software, used scripts, used winst version)!


Kind regards

Niko

The software is "LPKF CircuitPro PM".

Winst version 4.11.5.20 is used.

The command line used is something rather classical : I have tried to investigate with ProcMon but haven't found anything yet. As it is rather time consuming, I hope the problem is more trivial:-)

The local admin templates seems to be the one provided in the documentation. So, the local admin is created this way :
[DosInAnIcon_makeadmin]
NET USER opsiSetupAdmin $OpsiAdminPass$ /ADD
NET LOCALGROUP $AdminGroup$ /ADD opsiSetupAdmin

I have found a "trick" to get a working installation : the installation seems to be done, except msiexe never quits. So I added a timeout for the Winbatch directive When the time is up, I get a 259 error from msiexec. But I can go on.

The last msi logfile I can see is like this : And it never goes further.

is it not possible/easier to create an mst (msi transform) which answers your questions, or repackage your msi with something like appdeploy repackager, http://www.itninja.com/file/view/2

hi sbmk,

you can find a template uib created here http://download.uib.de/opsi4.0/products ... 0.6-1.opsi
you might want to download and then unpack (at workbench) : opsi-package-manager -x opsi-template-with-admin_4.0.6-1.opsi .

the script will create an admin install user, and run the installation with this user. your setup-script should be the one in CLIENT_DATA, which again names and then uses an install-script located in the localsetup folder. you can also specify if you want to lock the keyboard / mouse etc.
the new user will be deleted after the run.

It could be you need to set a few msi properties. It can also be the case the msi file is just a turd.
Too bad it's not free software so I can't look into the msi file

Hi,
Thank you all for your answers.
In fact, I solved my problem using a local admin setup and AutoIT, as command-line only MSI installation was not working, even with the local context opened.
I don't have time to explore MSI caveats, but maybe I'll try one day ...
Regards