Problems with Reboot and Autoit Scripts

[liviuzak]

Hello,

First, the WPI is run under a local admin account (administrator...). After the first reboot, I am getting a blue winow of WPI and nothing else on the screen (like it doesn't know where to cuntinue from). I can kill the process (mshta.exe) and the rest is loading properly under the domain admin account. The log shows that everything was OK with the first part and that's all, no end of course. If I restart the WPI from this admin account, it restarts from the beginning, reboots (after the reboot I am still under the domain admin accout because the first part is repeated), and this time it continues with the second part. After finishing the second part, I am getting that error:

=================

An error has occured on this script page

Line: 457

Char: 2

Error: Object expected

Code: 0

URL: file://C:\WPI\Common\Installer.hta

Do you want to continue runnung scripts on this page?

Yes No

=================

No matter what I press, it freezes again and I have to kill the process again.

What it is true that I did not test is with a real install with Windows, because it is a lot of time I have to spend, I tried only by launching the WPI by clicking on it.

I will make a CD with a short Windows and I will try it like for a live environment.

Regards,

Liviu

[mike_jrt]

Back in the days before WPI had the %REBOOT% command, I wrote a robust installer "Todo" list/reboot timer designed to survive reboot that could be called from WPI, WIHU, or any other front end menu list.

Reboot commands or additions to the todo list can be inserted into the todo schedule by the front menu program, or later on by scripts or applications applications as they were called in order. New items are added to the top of the list and are fired right away.

When the timer encounters a reboot in the list, it prompts the user with the choice of reboot now, manual, or continue (suppress).

In unattended situation the timer reboots automatically after the set interval.

If manual is chosen, the timer exits, then resumes after manual reboot, giving the admin the chance to make any manual adjustment before the process continues. Continue suppresses the reboot and continues to call the next items on the todo list.

When the timer is first run, it creates registry keys to restart at reboot. The timer logs each program as it is run, and will automatically resume the next item at restart even if the timer is force terminated or the computer unplugged. Thus you don't have to spend more time making your silent installs suppress reboots unless reduced total install time is necessary. If you can't verify the package installed in the same boot have absolutely no conflicts it may be best off to leave them in as a barebones winxp reboots quite fast.

The timer is provided as a separate application than the addtimer.exe which add items to the installation queue. You can simply call the addtimer.exe followed by the item you wish to add, as many times as you want, to build up the todo list. You can then run the timer.exe to start the installation right away or schedule it to begin on reboot. The script was compiled with AutoIT.

Now please excuse me while rant a little bit. The WPI developers have done a great job with WPI, with the extensible interface, the themes, inline manual, inline config file creator, all very nice, however the main problem is the whole thing is still dependent on internet explorers rendering of wpi.hta, and many times in the past our company has not been able to use WPI in clutch situations because something was nonstandard with the internet explorer installation. The use of javascript is nice because that is an open standard and could one day be used in other browsers, or better: a lighweight standardized browser only designed to render wpi.

Ideally the implementation would also support installing the latest packages from the web ala installpad and others. Installing web applications from a local repository doesn't make sense because web applications change so quickly. If you don't have internet access, you really have no business installing a lot of web applications, and you will be vulnerable as soon as you connect to the network for the first time, then have to go out and download each update one by one... while in the meantime your webchat program, email client, mediaplayer, p2p apps, etc are sitting there with an exposed attack surface from the last time you felt like compiling a unattended CD... how old is your unattended cd?

We are making a lot of changes to our UA install routine for the enterprise, small business, and home users:

Static apps, libraries, service packs, hotfixes affecting internet security installed via reboot timer on first boot(reboot, reboot). (Those libraries and hotfixes like to reboot alot)

Last line of reboot timer starts installpad for web applications install. These better not need a reboot

In the past we gave up on using WPI entirely in favor of WIHU and custom frontends because it did not support the complex dependency we needed. We are testing the current release and are still unsure if it will work for situations such as:

Gray out item unless .net 2.0 registry key found OR selected to be installed first above. (please note using the depends() wpi config line item does NOT work because then the item would be gray even if the item is already installed.

Also WPI is still lacking installed version tracking or awareness of previous installed packages, or field for uninstaller link. (Yes you can check for existence of files or reg keys, but how about FileVersion?) If this is possible it at lease needs to be better documented; I really can't explain the lack of documentation and conversation about the condition and graycondition functions in WPI, I would expect these to be fervently discussed in the forums but there's not much out there or in the help file for complex scenarios.

There is also the problem of rebooting, since many application installs and scripts require the desktop be loaded as documented above in this thread, and we have had mysterious problems with running wpi after reboot especially from network drives, even if they are permanently mapped. So until the reliability if improved we will use WPI as a pretty frontend menu and use it to call the reboot timer which will perform the actual installation.