
BenjaminKalytta
MemberContent Type
Profiles
Forums
Events
Everything posted by BenjaminKalytta
-
No not really. But I don't modified wihu log file behaviour. Well do it may be on weekend. I could add this. May be on weekend. Benjamin
-
Danke dir, habe ich natürlich sofort geändert Thank you, I changed this immediately. Benjamin
-
You are right "my2001" But it is also possible to do this in new WIHU UI now. Benjamin
-
auto-prompt to change password
BenjaminKalytta replied to prathapml's topic in Unattended Windows 2000/XP/2003
@prathapml: What is you excat purpose? Do you only want to change User Account Flags in this way that this user have to change it's account password each logon in future? If I understand you right you don't want set this in "Computer Management >> System Tools >> Local Users and Groups >> Users" but you want this to be done by a script? I'll create little tool then Benjamin -
Yes of course, the same way as you can do it with batch files, or runonceex and so on. Benjamin
-
As showed in http://www.kalytta.com/images/wihu.0001.png user may edit following things (that might also be edited during normal windows installation): 1. Primary Account Name (Daily use account) 2. Owner and Organization Information 3. Computer name 4. Workgroup name As showed in http://www.kalytta.com/images/wihu.0002.png and http://www.kalytta.com/images/wihu.0002.1.png user might create additional user accounts or edit existing ones including user account shellfolder paths and user specific environment variables. Main purpose as seen in http://www.kalytta.com/images/wihu.0003.png is the software installation interface. This will install additional software which was specified in a config file before. User may select software components that should be installed on particular system. Benjamin
-
Ok, I'll add this next days. Benjamin
-
No Software has not to be on CD. You may install it from network for example. Benjamin
-
It's up to you when you want to start WIHU. I prefer running in GuiRunOnce in winnt.sif. File version checking is a nice feature which could be usefull especially if WIHU isn't started as a part of unattended installation. But also in unattended mode it could be usefull after CD Slipstreaming for example. WIHU config file has not to be adjusted after slipstreaming ... may save time. Yes that's it. Me for example want full access over each additional component which may be installed by WIHU after Windows installation for example. As an example, if you install windows on several systems and you want install different software on different systems you could use WIHU to adjust software installations manually or let them install default components which should be installed on each system ... /autoinstall switch may be usefull here. Benjamin
-
Please consider to use /autoinstall=<seconds> switch and you'll see it. Benjamin
-
Why should WIHU delete %systemdrive%\install Directory? No there is no such operation. Just take a deeper look at your install.ini, there must be the problem. May be you added a command which deletes install directory after WIHU finished. Benjamin
-
Where is custom.mst stored? I would do following btw: [Office XP] command.0 = %SRCDRIVE%\soft\officexp\setup.exe TRANSFORMS=Custom.mst /qb- workdir.0 = %SRCDRIVE%\soft\officexp selected.0=1 Benjamin
-
I had to revert changes I made yesterday because this causes some more parsing problems. Take following example: [My Section] test.0.0 = wihu.exe test.eval.0 = 0 command.0 = ... description.0 = ... selected.0 = if.true, inherit disabled.0 = if.false, inherit test.0.0.0 = wihu.abc.exe test.eval.0.0 = 0 selected.0.0 = if.true command.0.0 = ... description.0.0 = ... If we presume that test.eval.0 returns TRUE (wihu.exe) exists, we will select this item. So further we presume test.eval.0.0 will return FALSE. Here is the point. Which state should be set to selected.0.0? If we inherit it from selected.0 (checked) we will check this item although test.eval.0.0 returned FALSE. Othwerwise if test.eval.0.0 would have returned TRUE this item will selected too. This doesn't make any sense. Benjamin
-
Yes, sorry you could be right I'll fix this tommorow (GMT). Benjamin
-
I fixed this. Should work now as intended. Benjamin
-
Hi rokey, you are testing for "CurrentVersion=5.0" here which only returns TRUE if, and only if you are using Windows 2000. So only if you are using Windows items get selected and enabled. So once again, if "Hotfixes WinXP" is unchecked then, NONE of it's subitems will be installed although it's subitems may be checked. So dont worry about this. But may be I should modify WIHU for consistency reasons. selected.x = v, inherit should also set it's subitems to "v" Benjamin
-
Ok, I''ll change this. Benjamin
-
Sorry. Im working on a new english version, but this will take some time. Each command is listet in example install.ini as commented text. Benjamin
-
No here it doesn't show any information but Im using version 3.30 may be that's the reason. But I found your Problem. They left out String Version Information which will be tested here. If this is not found, nothing will be displayed ... this should be fixed by rarlab because this inconsitency is very uncommon and more than seldom to find. But I'll try to change WIHU. Btw. what about just sending them a nice e-mail with request for providing string version information? Edit: It will work now. Integer version information will be read if string version will not be found. But in future I'll add additional comperators ?ProductVersion and ?Fileversion to be more specific. Benjamin
-
Which winrar file do you test? You know, winrar.exe don't contain any version information. Benjamin
-
Was a bug, is fixed now. Benjamin
-
So I changed it this way: 1. If file doesn't exists, it will return TRUE 2. If file doesn't contain version information it also returns TRUE I also added ?size keyword to compare file sizes and ?date to compare file creation dates. ISO 8601 date/time format is allowed like "1993-02-14T13:10:30" or "1993-02-14". To compare only for year and month it is also allowed only to specify something like "1993-02". Benjamin
-
No this was intention, but there is no problem to change this behaviour. Should I do this? Benjamin
-
@amigaman: Instead executing batch file, you should use subcommands which may be hidden/locked to prevent someone from select/unselect them. But IF you use batchfiles you have to prevent that more than one installation process is running the same time. This has nothing to do with WIHU, it is Windows specific. Please use "start.exe" for this purpose then. Btw. why dont you use following: [Nero & Other Apps] description.0 = Nero Burning command.0 = "%SystemDrive%\install\nero63125.exe" /sn=xxxx-xxxx-xxxx-xxxx-xxxx-xxxx /write_sn /silent /noreboot /noui Also here, you should use subitems like this: [x] Nero [x] Nero InCD It's just a simple command.0 and command.0.0. Benjamin
-
Hmm, this is a completely other situation. You should had said that you use /Ini switch and /SkipSettings. Nevertheless, bug is fixed now B) Benjamin