Hi Simon, simplesi wrote: > I just run it as a logon script in c:\docs and settings\allusers\program > files\startup and don't worry too much if the install isn't silent. Man, I really think you should read a bit about user privileges and software deployment. If you're able to run software installation from the startup folder (which is run with user privileges) then this means that your users have full administrator privileges. If so, then you have much bigger problems than just some AutoIt scripts not running. At any time any user could change the software configuration, screw up some settings or change whatever they like. So you have absolutely no control on the environment and there are far more problems to be expected than just an installer popping up an "unexpected dialog box". Moreover these dialog boxes can be handled using AutoIt, just check for a windows with a specific name to pop up and if it does not pop up after a timeout, then it will never... However I don't like AutoIt at all usually. All installers I had to use now have silent options - or the app can be deployed silently using a set of scripts (cmd script + 7-zip + reg-files). > I go into each school for 3 hours/once a week and it is quite easy to make a > "small" change and then find everything goes horribly wrong the next morning > when the machines re-boot :( As said above. I think in your setup this could happen any time. Especially users could remove the packages manually - so you could run into exactly the same problems as with WPKG if users remove some files/apps. > Looking further at config.xml I saw the /noforcedremove flag and tried > setting that as its explanation of its use seemed to be what I'd like to > happen. > > But it didn't :( > > But I think it should do what I want - eg not remove the package from > wpkg.xml if it is removed from the profile or package database. The /noforcedremove flag has a different purpose. It disables removing of zombie packages. WPKG will still try to uninstall the software if removed from the package database. Just in case the uninstall fails WPKG will usually remove the wpkg.xml entry in any case to prevent remove-loops (each run WPKG re-tries to remove the package). > I have made a small modification to a copy of wpkg.js and it now does the > behaviour I'd like but it would be much better if was done "properly" :) The easiest way might be to remove the contents of removeSettingsNode() or replace return removeNode(getSettings(), packageNode); by return true; And then make sure your packages do not contain any remove commands (or remove the execution of remove commands from wpkg.js too). This way wpkg.js will never remove any settings node. But hey, I really don't see any legitimate use case for this. If the settings nodes stay within wpkg.xml WPKG will have a different state then the system might have. For example a package might be (manually) removed (remember you users have admin rights) but WPKG will run the checks of all installed packages to verify them on each run. So you will have no possibility at all to remove those package definitions from the systems. So any package you really want to remove you need to go to each machine and manually remove the software as well as manually edit wpkg.xml. This is really totally against the principle of software deployment. And everything just because you sometimes (by accident) mess up your server-side package database? I think you should seriously think about your testing procedures take more care about the package database. If you continue to use your changed wpkg.js (of course you're free to do so) I am pretty sure you will run into strange problems on these machines in the future. In worst-case this might end in an endless reboot of your machines. br, Rainer |