midiboy

Hi Nanaki, sorry, but the 0.8.4 version still does the same thing. I left the installation running over night. When I returned next morning, the program had terminated. I have removed the /s switch by the way. I will now try this with a 32bit OS but I don´t think thats the problem.. Bye, Alex

Hi Nanaki, thanks for your quick reply. I have downloaded the 0.8.4 version (32bit) and will test it. Yes, the /s switch is for "sound making" , actually I forgot about it and thinking about it I never heard any sound so I removed the switch again :-) The version in the WPI Tools archive is 0.8.5 by the way. Any idea what was added to cdswitch in that version ? It is a bit larger too :-) I will let you know if the problem still appears with 0.8.4 PS: I took the 32bit version even though I am on x64 currently but I need this to also work on a 32bit Windows version and the 64bit code probably won´t have any advantages on the 64bit system performancewise Bye, Alex

Hi Kel, thanks, I wrote a message to Nanaki. As for the long time: Well, I agree but still, the program should not time out or anything .. it can happen that an installation DVD is left over night and continued the next day. Bye, Alex

Hi ! Don´t know if this is the right place to post a problem with the cdswitch tool in the Tools archive of WPI. I have used this tool for months now without any problems but today I found out that it seems to terminate in an "abnormal way" if it is called like this start "" /wait "%WPIfolderDVD%\Tools\CDSwitch\cdswitch.exe" AIW_APPS %CDROM% /d /s and then waits for a prolonged period of time until someone switches the DVDs. It works ok if the switch to the new DVD happens soon after the program was started but if the PC is left alone to install for a few hours and one then comes back to it, cdswitch has died. Just tested it again, it seems to happen after about 2 hours. Any idea what causes this or how to prevent it ? Bye, Alex PS: This is on Vista x64

Hi Kel, well, you call them annoyances, I call them problems The thing with Microsoft apps is an unsolved problem. A few weeks back you were able to reproduce the problem with Office and Livemeeting and the silence in that thread tells me there is no solution. You call this an annoyance ? Come on :-) The problem with Microsoft apps is severe enough that you either have to dump WPI or use a way to work around it and the only certain way around it is to install Microsoft apps after WPI seperately. Obviously either you guys do not use a lot of those apps or you have learned to live with it but I still think this is a major problem especially in a corporate environment. For instance, during an unattended installation, I can work around it by setting a Runonceex entry and install all MS apps after a reboot but there is no way I can use WPI as an unattended application installer throughout the company that way (although it would be ideally suited for that) because people needing another program to be installed won´t necessarily reboot their PCs. The other problems mentioned are maybe just annoyance but you see, you can never rule out that tomorrow yet another program will appear causing problems. When will the point be reached where you will think about a real solution ? I mean, yes, you can blame Microsoft for causing the problems with the Microsoft apps, you can blame Ahead for causing the problems with Nero but you will have a hard time getting those companies to change. And there may be more down the road. So why not think about solving the problem by not relying on an infrastructure you obviously cannot rely on to the 100% ? Anyway, I am not pushing the issue further, it was just an idea. I know that a complete redesign would probably be far too much work but since I cannot see any other real solution to those "annoyances", I though I´d try to offer my thought on this issue. Bye, Alex

Hi Kel, Of course Just thought that maybe WPI could just create that file in a temp location if WPI source dir was write protected and windowoptions.js was missing instead of throwing that error. Bye, Alex

Hi guys, just an idea ... you don´t have to approve but I wanted to bringt it up. Obviously WPI has a few problems (two come to mind: Problems with Microsoft apps and problems if Nero is/was installed or IE is not the default browser) that seem to come from the fact that WPI relies on some other programs in order to work (mshta.exe, IE). Wouldn´t it be possible to change the design of WPI so that it works on all systems, regardless of the installed or not installed programs or even if another program being installed replaces files currently needed by WPI. Of course it is cool that WPI works with a browser and consists mostly of html/js code but once you are faced with problems you cannot seem to resolve and seem to be "by design" it may be a good idea to think about the basics and maybe change them. I mean, honestly, I never had or heared of any such problems with WIHU, a similar tool but not based on html/js scripts. Unfortunately, Wihu is not being developed anymore and does not work with Vista but the fact that it did not rely on any other Windows program made it much more resiliant to system specific or program specific problems. Well, just an idea ... probably does not change much but it is really bothering me that for instance Microsoft applications are such a drag to install with WPI. Thanks for listening, bye, Alex

Hi! Just wanted to say that I am getting the "Could not be saved: ....\windowoptions.js" box again with WPI 7.1 But only with a network installation, not when installing from DVD. Should have tested that with the beta Any way around this now ? Do I understand correctly that I just have to copy some older windowoptions.js file into the WPIscripts folder and everything will be fine ? I am wondering why it says that the file could not be saved. Usually you cannot save a file to a DVD and most unattended installations will be run from a DVD Bye, Alex PS: Write access to this network share is also prohibited for the user connecting to it ...

Hi Dynaletik, mhh, strange, regedits for me work fine with the release 7.1 version but I do not associate htafiles with the 64bit mshta.exe anymore, just tried that as a test. Not in a script because the first "%" would get expanded, no ? Of course if you add that line directly into a cmd.exe you would only need one "%". But maybe I am mistaken on that one ? Bye, Alex

Some Addons: In case you need some way of 64/32bit checks in your own scripts here are a bunch of codelines I am using. That way you can easily adapt your scripts (only cmd, no vbs or powershell yet) to a mixed 32/64bit environment: This will check for the OS version (64/32bit) installed: IF /i %PROCESSOR_ARCHITECTURE%==AMD64 goto Vista64 IF DEFINED PROCESSOR_ARCHITEW6432 goto Vista64 The first line of code does not suffice because the 32bit cmd.exe will not report "AMD64" on a 64bit system. So if you happen to start that script on the 32bit cmd.exe or if your call gets redirected because you started it from a 32bit program, you want to make sure that you get the right answer. Therefore, on a 64bit system, always check for the outcome of a script in both the 64bit and the 32bit cmd.exe. This will set a variable called %PROGRAMS% depending on the installed bitlevel OS. This will point to the "C:\Program Files" folder on each OS: IF /i %PROCESSOR_ARCHITECTURE%==AMD64 set Programs=%Programfiles% IF /i %PROCESSOR_ARCHITECTURE%==x86 set Programs=%Programfiles% IF DEFINED PROCESSOR_ARCHITEW6432 set Programs=%ProgramW6432% The code below will do the same but point to the "C:\Program Files(x86)" folder on each OS (if applicable): IF /i %PROCESSOR_ARCHITECTURE%==AMD64 set Programs=%Programfiles(x86)% IF /i %PROCESSOR_ARCHITECTURE%==x86 set Programs=%Programfiles% IF DEFINED PROCESSOR_ARCHITEW6432 set Programs=%Programfiles(x86)% You could do the same thing for the Common Programe files folder. This one is the folder where the 32bit programs go on a 32bit/64bit system: IF /i %PROCESSOR_ARCHITECTURE%==AMD64 set ComPrograms=%CommonProgramfiles(x86)% IF /i %PROCESSOR_ARCHITECTURE%==x86 set ComPrograms=%CommonProgramfiles% IF DEFINED PROCESSOR_ARCHITEW6432 set ComPrograms=%CommonProgramfiles(x86)% And if you need to prevent some 32bit program from starting up on bootup you may need this: IF /i %PROCESSOR_ARCHITECTURE%==AMD64 REG DELETE HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run /v Test /f IF /i %PROCESSOR_ARCHITECTURE%==x86 REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v Test /f IF DEFINED PROCESSOR_ARCHITEW6432 REG DELETE HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run /v Test /f Feel free to add some of your own :-) Bye, Alex

Hi guys, Since I did most of the beta testing for mritter´s "64bit compatability code" in WPI 7.1 I am going to tell you all I know about how you can make use of it and what you need to know in order to successfully install a variety of applications (32&64bit) on a 64bit system and make registry changes etc. Introduction: Windows 64bit (Vista, XP or Server) comes with two sets of dlls and programs for most of the onboard functionality: the 64bit code and the same thing again as 32bit code. The 64bit code will be in the same place where the 32bit code resides on a 32bit system : The %windir%\system32 folder, the %Programfiles% folder or in the registry, the "HKLM\Software" tree for instance. The 32bit code otoh will be in different folders: %windir%\SysWoW64, %Programfiles(x86)% and in the "HKLM\Software\Wow6432Node" tree. If you are thinking, alright, that´s easy, just start the "%windir%\system32\cmd.exe" on a 64bit system if you want to start the 64bit cmd.exe then this will work if you double click on it in Windows Explorer but for some strange reason, this may not work from within another application, script or WPI for that matter. The reason for this is redirection. Windows will usually redirect your call to the 32bit programs automatically if you start the call from a 32bit program. Lets say you want to start a script from WPI that adds the serial number of a 64bit application to the registry: First, you start the installer of the 64bit application. It will install fine but it will expect its registry settings in the HKLM\Software tree in the registry. Now, next thing you do is call the "regedit /S reg.reg" code from WPI or a cmd script. What usually happens is, Windows will see that you started the script from a 32bit application (WPI) since even on 64bit Windows, wpi files are by default associated with the 32bit mshta.exe in the SySWow64 folder. So instead of going to the HKLM\Software tree, your registry code will get redirected to the "HKLM\Software\Wow6432Node" tree. Of course, your application does not expect its code at this place and won´t be registered. So what you have to do is make sure that on a 64bit system, WPI is started with the 64bit mshta.exe otherwise you will not be able to start any 64bit process on the system (without turning off redirection and to my knowledge that is not possible for simple scripts) and folder and registry redirection will then occur. In addition, from version 7.1 on, you can now specify in WPI what cmd.exe or regedit.exe to use for your scripts. If you activate the "64bit processing" switch for any application, this will tell WPI you wish to use the 64bit cmd and regedit.exe in the "%windir%\system32" folder. If this switch is not activated for an application, WPI will use the "%windir%\SysWoW64" folder path to access cmd.exe and regedit.exe which means you always get the 32bit versions of those programs even on a 64 bit system and even if the 64bit mshta.exe is being used. The latter is necessary if you wish to install a 32bit program and want registry code to go where the 32bit application excepts it on a 64bit system, in the "HKLM\Software\Wow6432Node". Conclusion: So what do you need to know if you are installing a mixture of 64bit/32bit applications on a 64bit system while pertaining compatability with 32bit Windows versions: 1. Make sure to start WPI the following way in all cases (32bit and 64bit windows): "%windir%\system32\mshta.exe" "Path to wpi\wpi.hta" That way you will make sure that on a 64bit Windows, the 64bit mshta.exe will be used, which as stated above is a necessity for the "64bit processing" option in WPI to work. On a 32bit OS, this will always work also, so no harm done. If you wish, you could also associate wpi files with the 64bit mshta.exe prior to starting WPI. You could do that using the ftype command like this for instance: ftype htafile="%windir%\system32\mshta.exe" "%%1" However, this would change the association system wide and you may not want to do that. (I don´t). 2. If you are using any other way of starting WPI, make sure to start it from a 64bit process. (or have a way to turn of redirection -> if you are a C programmer you can, I think). For instance, if you are starting WPI from a an application compiled from a script (like with bat2exe etc.) you will almost always get a 32bit exe. If you start WPI from that exe you will never be able to access the 64bit paths/registry trees from any script started in WPI. 3. If you are installing a 32bit application in WPI, you do not have to activate the "64bit processing" switch for that application. If activated, the 32bit application will still install fine, however if you then add scripts or registry edits afterwards to add settings/registration info etc. the 64bit cmd/regedit.exe will be used and the code will most likely end up somewhere where the 32bit application won´t find it :-) 4. If you are installing a 64bit application you should activate the "64bit processing" switch for that application. It will also work when that switch is not enabled but only the program itself will then install fine. Any registry edit etc. will not be at the right place afterwards, as written in detail above. That´s more or less it. It may seem a bit overwhelming at first but once you are getting used to it, it is not much of a deal. Hope the above helps! Bye, Alex

Hi guys, I tell you why a 64bit compiler would be necessary. I am starting WPI from a batch file that checks for the existence of a network share and maps that share if it exists. Since it includes credentials I don´t want the script to be easily readable hence the conversion to an exe. Now, the new WPI version 7.1 allows for 64bit processing, meaning, you can control if the 64bit cmd.exe/regedit.exe is being used on a 64bit system or the 32bit cmd.exe/regedit.exe. However, you need WPI to run with the 64bit mshta.exe in order for this to work. You need this to silently add the serial numbers or configs etc. for an application via a "regedit /S reg.reg" command. If the application is 64bit it needs its registry settings in another place in the registry than a 32bit application on a 64bit system. Now, the problem is: If WPI or any other application is started from a 32bit application, it will never be able to use the 64bit cmd.exe/regedit/mshta.exe. Even if you specify the correct path to the 64bit application, redirection will occur and the 32bit version of the program will be started. It took me days to find out why WPI was always started with the 32bit mshta.exe. I finally figured that the reason for this was the 32bit compiled exe. So on a 64bit system, in order to avoid folder redirection or registry redirection with your compiled scripts , you need a 64bit exe. Bye, Alex

Hi guys, sorry to use that old thread. :-) Looking for a cmd to exe compiler that creates 64bit executables. QuickBFC doesn´t seem to do that. Any other ideas ? Thanks, Alex

Hi Mark, I would like an option to successfully install Microsoft applications ;-) Just kidding *g* No, seriously, I already gave you a few options a while back: - option to hide the Exit button in WPI - option to hide the Cancel button in the installer Bye, Alex

Hi Kel, any news ? Sorry if I am pushy :-) I am wondering: The first time you tried it, it worked for you. How did you recreate the error or what did you change that caused the error for you ? Thanks, Alex

Hi Kel, how were you able to recreate the error ? Did you use my settings file or was it something else ? I could use your settings file if you think it is related to that. Tried it, no difference. WPI still dies during the lmconsole.msi installation. Any other ideas ? Thanks, Alex

Hi Kel, i have no idea why this thing works for you but not for me. I have done a dozen tests today and it never ever works in my case. - I have taken out all Vista updates. I am now using a normal unattended Vista SP1 installation from MSDN. - I have taken out all additional software (Net Framework Updates, DirectX Updates, etc. etc.) - I have taken out all Update from the Updates folder in Office 2007. - I have used your Autoit Code from your thread, made an installer.exe and started this in WPI instead of my cmd. Still, each and every time when Live meeting is installed, WPI dies. I can only think of a few reasons now: 1. This is somehow related to the language of Vista or Office 2007. I am using a German version, yours is probably English. 2. Our Office settings files are the key to the solution and differ significantly. 3. This is somewhat related to the test machine. (I am using VMWare workstation 6.0.4) or the amount of memory, CPU cores or some other hardware option. Other than that, I cannot think of any reason why this works for you but not for me. Do you or anyone else ? Bye, Alex

Hi Kel ! what the ... How the hell did you get those things to install ?!? Can you maybe send me you Office 2007 settings file you used ? Maybe it is some optional component (I am installing all components). I can also send you my settings file if you are willing to do another test run. Two other questions: Is this Vista with SP1 integrated or the RTM Vista ? (I am using vista SP1) ? Did you have any Vista Updates installed before installing Office 2007 ? Or anything else like Net Framework Updates etc. ? Bye Alex PS: Thanks for your time !

Hi again, back with some results from the testing department ;-) 1. Runonceex has nothing to do with it, the problem is the same if WPI is manuelly started after a fresh Vista installation. 2. The more interesting point is this: I have two ways of installing with WPI: A script checks if a certain server is available. If it is, a network drive is created and WPI plus all applications install over that network. This is what I did all the day now and this is where the script error mentioned above appears during the Livemeeting installation. Now, out of curiosity, I disabled the network connection on the virtual machine and installed again, this time, the server was not found and instead WPI started from DVD and installed Office and Livemeeting from DVD. Interestingly enough, the error message changed now. WPI still died during the Livemeeting installation (at the same time as before) but the message was different. Now, the old "reboot config" message appeared (see picture). This in fact means, that this is still the same problem but depending on installation medium used, the message is different. Does this help in any way ?

Hi Kel, Thanks for your help. I am using Vista Ultimate SP1 (integrated) but the problem also happens with the Enterprise Version so I doubt it matters. After Vista is installed, I am starting WPI from a FirstLogonCommand in the autounattend.xml. Actually, to be precise, I am starting a cmd there, that installs a few prerequisites like Net Framework updates etc., then reboots the PC and then starts WPI using runonceex. I have tried installing Office and Livemeeting manually (without WPI), of course everything is fine :-) Next, I will try to start WPI manually after Windows has fully loaded (not during runonceex) and install Office and LM from there to see if it matters. (doubt it but who knows). What I really don´t understand with this whole matter is, why the hell WPI cannot protect itself from these things. If an msi is dying as you said in the first post, why does WPI have to die with it ? ;-) Also, why does the msi die only if it is started from within WPI, not when it is started manually or from within a cmd ? And if some update tries to kill mshta.exe why can´t WPI lock it while it is running so that the update is not able to exchange it directly but during the next reboot ? Those may be naive questions but I am wondering why WPI has so many problems with Microsoft applications even standard msi packages. Bye, Alex

Hi Kel, I don´t use the livemeeting.msi you use but the lmconsole.msi seems to be the same (Livemeeting 2007). As for the process ... It may be ok if Office 2007 is already installed but have you tried installing Office 2007 and then Livemeeting with WPI right after one another without rebooting in between ? That will cause the error right at the end of the lmconsole.msi. By the way, thanks for your time in testing this ! Alex

Hi Kel! With run manually you mean not using WPI ? Just doubleclick on the cmd´s manually ? Running it reverse would not make much sense since Livemeeting has a plugin for Outlook (which does not get installed if Outlook is not installed) but I will try. As for my second post: I just would like to know if I did this right (first, a cmd for the jscript code watching the cmd script and then a second cmd in config.js for actually running the script) Bye, Alex

Hi again, maybe I am doing this wrong, but I just tried the new jscript code: prog[pn]=['Office Live Meeting 2007']; ordr[pn]=[90]; uid[pn]=['LIVEMEETING']; dflt[pn]=['yes']; cat[pn]=['Office']; forc[pn]=['no']; cmd1[pn]=['JSCRIPT=TimedWaitForFile("%root%\\Microsoft\\LiveMeeting\\silent_install.cmd",40)']; cmd2[pn]=['"%root%\\Microsoft\\LiveMeeting\\silent_install.cmd"']; pn++; Is this how it should be working ? Is cmd2 still necessary if I want WPI to wait until the silent_install.cmd is finished ? It did not make any difference with the dying WPI though ... Bye, Alex

Hi Kel, thanks for your reply. Can you elaborate a bit ? 1. As for the hotfixes ... You mean the Office 2007 hotfixes or Windows Vista hotfixes ? I don´t really think that you are right with that assumption though because as I have written, I have taken out all the Office 2007 updates (even SP1) and WPI still dies if Livemeeting is being installed. 2. Can you tell me how to use the jscript code in this case ? What exe or process should it be watching ? The Livemeeting msi files in this case ? Or the Visio setup.exe ? I am not sure I understand the problem though. I am starting a cmd with WPI. This cmd is still running when WPI dies so where would it help if WPI waits for another process to finish ? It is waiting for the cmd anyway. No ? But why does it only happen if Office 2007 was installed before ? If I only install Livemeeting, the same code, the same installation works fine. Thanks for your help ! Alex

Hi Mark, Kel ... :-) Just came across another deadly error with WPI (7.0) while installing Microsoft applications on Vista(32bit) . (I should stop doing that but the fact is, I (we) simply need them installed). Now, I have taken out all Updates from the Updates folder of Office 2007 and install them later on (after a reboot) with a script. This actually worked. Office 2007 installs fine now with WPI. Now, if I install any other Microsoft application afterwards (for instance Livemeeting, which is just a simply small msi package !!), WPI dies again but this time, the error message is different, some talk about an illegal character in line 1. (see picture) The script for the Livemeeting installation itself cannot be the reason for this as it will install fine on it´s own (if Office 2007 was not installed before). The problem only appears if Office was installed sometime before. Since I cannot do a reboot between every Microsoft installation (and we have a few, I am stuck again. Btw. I am starting a cmd script in config.js to install both applications so WPI is actually watching the cmd´s and not the msi/exe´s itself. I also tried adding wait commands etc. but nothing helps. The WPI log does not say much although it reports code 259 for the Livemeeting installation. Here´s the content of the config.js for the two apps: pn=1; prog[pn]=['Office Enterprise 2007 (Updateinstallation nach Reboot)']; ordr[pn]=[2]; uid[pn]=['OFFICEENT']; dflt[pn]=['yes']; cat[pn]=['Office']; forc[pn]=['no']; cmd1[pn]=['"%root%\\Microsoft\\Office2007\\silent_install.cmd"']; pn++; prog[pn]=['Office Live Meeting 2007']; ordr[pn]=[90]; uid[pn]=['LIVEMEETING']; dflt[pn]=['no']; cat[pn]=['Office']; forc[pn]=['no']; cmd1[pn]=['"%root%\\Microsoft\\LiveMeeting\\silent_install.cmd"']; pn++; And here are the 2 cmd´s installing Office and LiveMeeting (I have reduced them to the bare minimum (no cmdow, echo commands etc.) REM Office: cd /D %~dp0 start /wait .\setup.exe /adminfile settings.MSP REM LiveMeeting: cd /D %~dp0 start /wait .\LMConsole.msi /passive /norestart ping -n 30 127.0.0.1>nul taskkill.exe /F /IM outlook.exe start /wait .\LMAddinPack.msi /passive /norestart ping -n 30 127.0.0.1>nul exit Any idea what "illegal character" the error message could be about and what to do ? Btw. WPI dies right before that command in the second script is finished: start /wait .\LMConsole.msi /passive /norestart That means it dies while that msi is still running but almost finished. So the sleep command that I have included afterwards does not really help and comes too late anyway ( by that time, WPI has already come up with the error, see picture). Bye, Alex