BenjaminKalytta

As this implied, you missed to specify the description. ; Sub command 3 description.3=.NET Framework 1.1 (incl. deutsches Sprachpaket) command.3=msiexec.exe /i software\netfx.msi /qb selected.3=0 description.3.0=Something command.3.0=msiexec.exe /i software\langpack.msi /qb hidden.3.0=1 Benjamin

Ah now I understand your problem ... what kind of message is this? Messagebox? Benjamin

Everything is possible, but I won't add too much special features ... btw. why should %curdir% replaced by %temp% ? Benjamin

This is because of an inconsistence in file version data. This mean that I have to modify the version detection algorithm. This will be available in version 2.0.40.0. (2.0.40.0 will be the last beta before I release final 2.1) Benjamin

No it seems not as this is an error message by cmd.exe whichs says that this isn't possible. Benjamin

Don't overvalue this exit code ... it doesn't necessarily mean an error because the exit code doesn't always reflect an windows error code. Benjamin

Date: 22.08.2004: Version 2.0.47.0 Bug in /ini= switch was fixed Keyword workdir.x was added. This may be used to specify alternative working directory. WIHU variable %INIDIR% was added which points to directory where current ini file is located. Date: 21.08.2004: Version 2.0.46.1 Bug in disable.x/enable.x operation was fixed Date: 19.08.2004: Version 2.0.46.0 User profile directory will also be deleted on delete.x [users.operation] Bug in UseCurrent INI [settings] was fixed Date: 18.08.2004: Version 2.0.45.1 Minor bug in dimension.width/.height was fixed Date: 18.08.2004: Version 2.0.45.0 Minor bug in /SkipSettings was fixed Date: 17.08.2004: Version 2.0.44.0 Minor bug in software selection list was fixed ... [users.operation] was showed as installable software. Date: 17.08.2004: Version 2.0.43.0 dimension.update=0|1, dimension.width and dimension.height ini file keywords was added to [settings] section. WIHU will adjust it's size corresponding to this settings when loaded. dimension.update=1 forces WIHU to write it's current Windows size to ini file after exit. Date: 17.08.2004: Version 2.0.42.0 Entire feature for loading and editing existing Windows User Accounts which was added in 2.0.40.0 was removed and is replaced by a much simpler one. New keywords are disable.x=username, enable.x=username, rename.x=from, to and delete.x=username which must stay in [users.Operation] section in ini file. This section must stay in same file as [users] section. Specifying existing users in [users] section is btw. still possible. Usage: [Users.Operation] delete.0=TheUser@MyDomain delete.1=ASPNET disable.0=Administrator disable.1=... rename.0=Administrator@Domain, TheMaster /Verbose=<level> switch was added. Verbose levels are: 0 = Don't display certain status messages and don't print sub command descriptions 1 = Print certain status messages 2 = Print sub command descriptions in log view 3 = Print all messages Date: 17.08.2004: Version 2.0.41.2 Bug in command.x execution was fixed when /SkipSettings was used. Date: 16.08.2004: Version 2.0.41.1 Following command line switches are also available in INI file [settings] section: Computer, Workgroup, User, UserPwd, Admin, AdminPwd, Owner, Org, Log, SkipSettings, SkipSoftware, SkipRestart, NoCancel, AutoLogon, Verbose, NoRestartChange, Beep, AutoInstall, AutoExit, RestartWait /Workgroup=<name> switch was added. Name length restrictions are following: User name = 20 characters User password = 100 characters User account full name = 100 characters Path names = 260 characters User account comment = 200 characters Computer- and Workgroup name = 15 characters Date: 16.08.2004: Version 2.0.41.0 Workgroup membership can be changed now. Fixed minor bugs in user account settings Date: 15.08.2004: Version 2.0.40.0 /users=<ini> is now defaulted to install.ini which means, install.ini should contain the [users] section in future. If /users=<ini> is specified, users are loaded from this file only! WIHU Window is now resizeable New [users] section keyword OldPassword.x To change password of an existing windows account you have to add this keyword and initialize it with the current password of the specified account. In case you want reset the old account password or to change this without knowing old password, just set OldPassword.x=*. In this case Password.x will be applied. To delete an existing windows user account just create a new user.x and add 0x80000000 to it's status.x. Example: [users] user.0=ASPNET status.0=0x80000000 New Group.x behaviour: If corresponding user account does already exists then: Group.x=1 -> Move user to "Administrators" Group and remove it from "Users" group Group.x=0 -> Move user to "Users" Group and remove it from "Administrators" Group Group.x=2 -> Don't change Group Otherwise if corresponding account doesn't exists yet then: Group.x=1 -> Move new user to "Administrators" Group and remove it from "Users" group Group.x=0 -> Move new user to "Users" Group and remove it from "Administrators" Group Group.x=2 -> Don't add the user to any Group Existing account vs new account: It's possible either to specify an existing windows account or to specify a new account that will be created by WIHU. 1. The first case: You will not be able to change user profile settings like shellfolders or user environment with WIHU for this account. 2. The second case: WIHU will disable this user later after modifying user profile. /Beep=<seconds> switch is now available. This could be usefull for unattended windows installation to hint the user to enter WIHU settings before WIHU auto installation begins (/AutoInstall) or WIHU exits (/AutoExit). Benjamin

That's no bug, that's intended. If you logon as current user (which may be Administrator) and you disable this, it's normal that you can't log on anymore if this is the only one account.Other things I'll implement if I got time for this. It's normal, Guest can't be logged on by default. Benjamin

@bilemke: Which fields do you mean, or which things should be initialized? Shellfolders (if not specified) will always created automatically by windows at %USERPROFILE%\ShellFolderName. Remains Home and Profile directory whereby both will created automatically by windows on correct place %SystemRoot%\Documents And Settings\NewUser Or did I missunderstand you? Benjamin

@IceBlackIce: Just test new version (web site). Should work there. Please note: If parent of a subtree isn't checked, none of it's children will be executed later. Benjamin

**** ... look at me ... im the 4th Benjamin

Just take a look at the version information. On the web page is the latest version. Btw. also take a look at an older posting ... I mentioned there that I changed "DefaultHome" to "Home", this seems to be your problem. Benjamin

@midiboy: Which bug? Benjamin

Sorry, Now it is really fixed Benjamin

Sorry, both things are fixed now;) Benjamin

@t-o-m-m-y : I fxied it. Please download from web page. Benjamin

@visaversa: Thank you. Benjamin

No if Group.x=1 is specified WIHU will not change anything after install. Only if Group.x=0 was specified WIHU will first assign this new user full access rights during installation which will removed later after first logon of this user. I changed "DefaultHome" to "Home" because of consistency reason. Sorry for that, but's already beta Benjamin

Nice to see you here visaversa No that's not fully true ... it is fully unattended if you start it with /autoinstall=0. No user interaction is needed then. Benjamin

@all: Ok I changed the selection behaviour now. Also: Primary user will be moved to "users" group by default since now. However this user will always have admin rights during installation which will be removed after first logon. (if "[ ] Add administrator rights to new user" was not checked) Benjamin

Hmm, you mean "Power Users" which is a Local Group, but no Account! This is a difference. But how should I call this user then? Benjamin

@booster: I changed Software TreeView Control behaviour 2 times now ... this time I won't change this unless everyone her wishes this. Or just suggest an alternative way. Benjamin

Yes that's the way it is. It's because x.0.0 is a subtree ob x.0. If you uncheck "Total Commander 6.03" (in your example) it will also unheck it's subtrees "Total Commander Settings" in this case. [x] Tools [x] Total Commander 6.0.3 [x] Total Commander Settings If you don't want unheck "Total Commander Settings" when you uncheck "Total Commander 6.0.3" than just move "Total Commander Settings" a level higer to command.0.1. [x] Tools [ ] Total Commander 6.0.3 [x] Total Commander Settings @all: A question. I think naming the user created on first page "Default System User" is a bit confusing because an account "Default User" already exists in Windows. What about naming this "Primary User" (german: "Hauptbenutzer")? Benjamin

That's it Benjamin

@booster: Very strange. Error 21 means "Device not ready" after calling "LoadUserProfile" API. May be calling this at T-13 stage isn't allowed?! Do you use roaming profiles (think not)? Benjamin