my2001

@prathapml: odd enough: forcing new passwords for user accounts is already possible using WIHU ... but I didn't know it either. first had to ask WIHU's developer about it one has just to use following ini directive in WIHU: status.x=0x800000 this marks the passwords of account no. x as expired

Would it be possible to implement a new feature in WIHU which allows to specify for each user account separately if its password must be changed with next login?

Cool thing ... I needed that, too ... just a day ago this wish arose. I've been anxious to see the solution of this thread, and here we go. thx 2 shuter!

Ah, thanks for that hint! But unfortunately I'm not very skilled in using security templates. Maybe u know where I can read more about that or gimme a link?!

Using gpedit.msc (gpedit menu: computer --> settings --> ...) I can give any user account the right to change the system time. I need this because I've got one program running which needs this right. But how can I achieve this desired setting using a registry tweak or something like this since I wanna do an unattenden install? *hehe* thx!

Sometimes some programs go mad and mess up my unattended installation. WIHU creates a log file if used with /log parameter but if the error occurs during wihu operation and I have to reset my system since it's no longer responding there is no log file because wihu only writes it at the end of its process. So couldn't u let it write the log file entries right after each installation step, i.e. not at once at the end of the whole process? It would make it easier to troubleshoot problems. thx

Here's another hint ... WIHU - a tool developed by a board member

ic ic ... but thanks anyway! There's no hurry at all 4 me.

Are there SP2 shell packs available?

That's not as easy as you think, but I'll change the code next days. Benjamin But why change this? It is just usual behaviour that batch files are called by cmd /c, isn't it.

Hi! Very simple in fact, I don't have to send many emails: Firstly I had started WIHU with your supplied install.ini, i.e. with the included user and environment settings, etc. Secondly I loaded a completely new install.ini in the last WIHU-dialog before installation process starts. This new/my install.ini includes no users-section at all, no shell folder settings, only some general settings like AutoInstall, beep and so on and, of course, the usual installation directives. But apparently WIHU didn't forget the user settings, etc. from first install.ini although there weren't any of these settings left in my new install.ini. This produced the error code since I guess these settings are not valid at T-12 mark. Of course, if you still need the files to look at I'll send them to you.

Yes, by all means! workdir.x directive does work independendly of using which command ever. It just tells its related command.x-program in which directory the latter one should search for probably needed files such as configuration files or something like this. maybe also interesting: posting in another WIHU-forum thread

Explain what?

Hi! I don't know because I didn't test but most likely your second code example won't work and your first might. *hehe* Although there is no reason to use any of both examples because there's no reasonable case in which it makes sense to call msiexec by cmd. Msiexec is available from everywhere within Windows since it's stored in system32 directory and why not call it directly? Moreover I assume workdir-directive is confusing, indeed. But this comes because it didn't come up to our expectations. Workdir is quite the same as the "Ausführen in"-thingy; right click on a windows shortcut to see what I mean. So there's no real need for recoding - at least according to my opinion. workdir.x has just been misinterpreted.

Yeah, you already found it on yourself: batch files (.cmd, .bat, ...) have to be called by ... command.0=cmd /c @batchfile.cmd workdir.0={relative path to batch file!!!} Besides I recommend calling MSI-files always by ... command.0=msiexec /i msifile.msi ... workdir.0={relative path to msi file!!!} ... and MSP-files by ... command.0=msiexec /update mspfile.msp ... workdir.0={relative path to msp file!!!}

Hi! I was about to post a new thread about workdir.x directive since I face exact the same problems as you described. But u've been faster! [For those who don't have time to read: just compare the last two code examples in this posting, they cause the same.] I guess I found out the following: Obvioulsy the workdir-directive doesn't set the let's call it "main directory". This remains always the same directory where WIHU.EXE is located. So, if you want to call an application it is NOT sufficient to set the appropiate directory by workdir.x-directive and merely call the installation executable by command.x-directive without any path. You always have to use command.x-directive with a relative path to WIHU.EXE! workdir.x-directive doesn't seem to affect this. So, when does one need workdir.x? Well, let's assume WIHU.EXE is located one level above a folder called "Inst" and you use the following line: command.0=msiexec /i Inst\Prog\Acrobat\AcroPro.msi TRANSFORMS=unattended.mst /qr - Here you must not forget to specify the (relative) path for AcroPro.msi or elsewise WIHU won't find the AcroPro.msi. (I told that earlier.) - If you DO NOT specify workdir.0 line in this example WIHU will search for the unattended.mst file in it's own directoy, i.e. where WIHU.EXE is located! And (only) this particular behaviour can be changed by workdir.x-directive! So you've got the choice between: command.0=msiexec /i Inst\Prog\Acrobat\AcroPro.msi TRANSFORMS=Inst\Prog\Acrobat\unattended.mst /qr or command.0=msiexec /i Inst\Prog\Acrobat\AcroPro.msi TRANSFORMS=unattended.mst /qr workdir.0=Inst\Prog\Acrobat\ Hopefully I'm right and maybe this explanation helps a bit.

Okay, I think I found out what's the matter: in the last dialog before installations start I loaded a new install.ini. The old one included some shell folder specific settings which weren't present in the newly loaded install.ini. I thought WIHU would "forget" those old settings after loading a fresh install.ini, but apperently it didn't; maybe a bug?!?! So WIHU tried to apply some configuration settings not valid at T-12 installation mark which produced the reported error messages. That's what I think must have happened. So from my point of view my settings in the environment section are independent of the error messages, it were just the "unforgotten" leftovers from a former install.ini which caused the trouble.

I thought WIHU could start msi files on it's own without a "msiexec /i msifile.msi" at the command line. But I'm facing problems when I try to install .NET Framework for example. I have to use msiexec /i on command line to get it working. Is this intended? My install.ini says (example not working): (...) DESCRIPTION.0.0=.NET Framework 1.1 inkl. deutschem Sprachpaket & SP1 command.0.0=netfx.msi /qr workdir.0.0=InstCD\Komp\NetFramework\ selected.0.0=0 hidden.0.0=0 (...)

At the very beginning of my WIHU installation log (level 3) there it says two times: Error 997: Shell folder environment strings are disabled. This very likely refers to the following lines in my install.ini: [Environment] ComProgs=HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs StartUp=HKCU:SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Startup I run WIHU at T-12 stage during Windows XP Pro Setup, there are no user related settings in install.ini, only section [environment] and some uniquely named software sections. What does error 997 mean? What's not working then since the two variables from above do work for me on my system. thx!

Hi! First of all: this is definately the wrong sub-forum for your particular question. You'll get more help in another forum. To your problem: Well, I haven't had this situation and hopefully never will have, but I guess there is no way to add or modify user accounts without admin privileges (this is intended behaviour, indeed). You have to search for other ways ... in other forums. Try to use search function first, please.

Wow! Yeah, some things sound good, indeed.

@Benjamin Okay, and that does mean what for the user/usage of WIHU?

I sometimes face this problem, too: I double click on a program icon, but nothing happens. I've never encountered this with WIHU. I can't tell you what causes this strange behaviour but it's been always due to a more or less "corrupted" Windows system. As soon as I "repair" it, problems disappear. So it is not related with WIHU directly, that's what I can tell so far safely. Unfortunately I can't give you more precise hints. Maybe it helps to drop your current hotfix installations and subsitute them with SP2 which actually includes all of them.

Described so often before: just start your downloaded installer (here that one of Framework) and then look into your temp folder of your current logged in user account. Voilá! And here's an overview of available command line switches:

... at runtime, i.e. can the user make any choices while xplode's running or does xplode stick to its script?