Jump to content

mike_jrt

Member
  • Posts

    8
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

About mike_jrt

mike_jrt's Achievements

0

Reputation

  1. 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.
  2. Djé sent me an updated version of his install list tool, v1.0, hoping that my questions and the updated version would also be of help to the community at large. I am sharing his new version and our current implementation of it, which has been used for WIHU in the past but mostly now is used with WPI. I will also try to answer our biggest questions about path resolution and the current version of WPI in general in this thread. The link will be up shortly, msfn only allows 200k, and the config xls are 650k each. installDjé_1.0.xls installMRT_1.0.xls I believe Djé's install spreadsheet is superior to the WPI config wizard since it allows you to create categories for @98, @XP, @Vista, @Pub etc, then generate a config file only for files with that category checked. My biggest question was regarding the use of the wpi variables %WPIPATH%, %CDROM% and %ROOT%, and when to use each for a cd, network, or usb drive install. %WPIPATH% is hardcoded into WPI to resolve to the WPI directory, and so is suggested in cases where users use the suggested WPI/Install directory to place their installers. %ROOT% points to ../WPIPATH, or the directory located one level up from WPI, suggested in cases where your installers are located in sibling directories to WPI. (suitable in cases where you may be calling your installers from other programs besides WPI as well) In the current version of WPI %CDROM% is actually defined by searching for specific files normally found on the traditional XP install cd, so it's use is not reliable for Vista or custom multiboot CD installs, unless the standard xp files are added. I will post the exact lines from the config soon if the WPI developers do not comment or change this. More to follow soon! Djé, it would be super if you would post the batch command you are using with WPI injection to install your firefox extensions, as I have found the firefox.exe command switches to become unreliable in recent versions, and have reverted to repackaging the xpi's via CLEO for local installs or a html page with a series of checkboxes which downloads and installs the extensions from the web.
  3. If you use this detached program code, or any other for statement that does not require inline quotes, you can start a cmd or exe from the cd, or an attached external storage device. This storage device could be the source of your unattended program installation on computers without dvd drives. DetachedProgram = ".\system32\cmd.exe" Arguments = "/C START /min FOR %I IN (C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO IF EXIST %I:\OEM\detached START /min %I:\OEM\detached" A better version would stop the loop when the first source is found instead of attempting to execute all cases.. You can populate runonceex, runonce, and guirunonce from the detached stage by editing the registry or \windows\system32\$winnt$.inf file. I have found guirunonce necassary for proper post-install timing, since the run keys get executed around the cmdlines/svcpack timing and the local machine keys are parsed.
  4. Please see this post: http://www.msfn.org/board/index.php?showto...mp;#entry543686
  5. I see that the require other program is implemented, however ideally there would be one more field for a "Installed" test of file existance or registry value - this would display small graphic or text indication and disable the item. The addition of one more field for the uninstaller path shortcut would make a great target for the label. These features would make WPI provide much more useful feedback for real world mission critical complex environments and improve efficiency by saving time figuring out which software is already loaded. Thank you for considering this information. I hope to see WPI become as robust a tool for deployment as perl or conditional autoit, currently it's way more pretty, but not as functional.
  6. Restart and resume features would allow WPI to finally replace robust custom sequencing scripts or ktool for handling a long installation routine requiring multiple restarts for safe installation of service packs, hotfixes, frameworks, drivers, reg settings, etc. The ability to specify Reboot as one of many commands in a set for a particular checkbox would be very powerful. Also, a more active approach to implementing this by writing the current progress before running each command would allow for resuming at the correct point in the event that an installer forces a reboot the installation routine would not be comporomised. These next questions are not nearly as valuable as the restart and resume functionality, however, a few questions: Are subcategories possible with the current version? Are complex dependancies possible such as all of the following: Require other program be selected Require filexist or fileversion > * Require registrykey exist or registrykeyvalue = *
  7. I like your idea, I have been considering doing something similar with autoit for registry tweaks applied to individual users, all users, or the local machine. Please see my post here: http://www.msfn.org/board/index.php?act=ST&f=90&t=73626&st=0 With a sample script you can use to import all the .reg files in a directory If you have a sample script you think is particularly useful please post to improve this thread.
  8. Thanks to everyone who has contributed to WIHU and made the MSFN forumns such a great resource! I am trying to finish a more advanced deployment/maintainence user interface to apply the registry tweaks I have compiled over the years. As you know, many registry tweaks are made to be applied to certain areas of the registry which apply to all users, (such as HKEY_CLASSES_ROOT) while some can either be applied to the local machine (HKEY_LOCAL_MACHINE) or to individual users (HKEY_CURRENT_USER) I have previously used WIHU to script the importing of .reg files to the registry using regedit /s "regfilename" however what I would like to accomplish is a way to apply tweaks to the CURRENT_USER account the first time a user logs in on a computer. (allowing computer wide settings to take effect while leaving the LOCAL_MACHINE hive intact) This would allow a new fresh user account to be created in the event of user profile corruption without having to rebuild the LOCAL_MACHINE hive. I am planning on implementing this with the following: Use WIHU to import any checked tweaks that effect the LOCAL_MACHINE or CLASSES_ROOT directly Using WIHU to copy the desired CURRENT_USER .reg files to a directory on the local HD Using this script to execute all .reg files in the directory @echo off echo Importing Default User registry keys... for /f %%i IN ('dir /b .\files\regkeys\*.reg') DO regedit /s .\files\regkeys\%%i echo -completed I would trigger the execution of the CURRENT_USER scipt with an entry in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run to run the tweaks at EVERY login I was going to use a registry key check for the situation where you want the tweaks run only the first time a new user logs in (For the case where you want a preinstalled environment, but you want new users to be able to make changes later without those changes being overwritten) The script would set a registry flag once the tweaks were applied the first time, and close silently in the future. My main questions relate to wheither this is the most elegant and maintainable meathod to accomplish this. I have considered using an autoit script to accomplish this as well, or using variables in WIHU to substitute the CURRENT_USER or LOCAL_MACHINE part of the registry path, however I would believe this would require using the REG comand instead of regedit /s (and would do away with having to have a separate version of each .reg file for the local machine and current user) Are there people out there using REG in their WIHU ini files successfuly instead of regedit /s? There are some visual basic functions such as REGWRITE availible as well; is it possible to call this from WIHU? I hope some of you with more extensive registry or autoit experience will have some useful comments; till then I will be testing the above registry flag method and will try to compile some more useful snippets in this thread.
×
×
  • Create New...