antoineL

Thanks, this is useful.

Surprise! Yesterday (2009-08-07) I spotted this download as available on Microsoft servers (in English, French, German etc.) The page (http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=60A07E71-0ACB-453A-8035-D30EAD27EF72) is widely advertised all over the web. But today, all the links are 404 (including direct downloads). Is it possible that MS shall upgrade the WAIK to the RTM release in the next few days?

Thanks to Strel (and TC76 and all the people involved) for this useful tool. I was trying to use only the .NET 1.1 part, and I got small pitfalls. First, while my targets include Win2000 and Vista stations, I was building on XP64, which is seen as NT5.2 i.e. 2003 server (they share the same kernel). Even if I use WIN2K=YES in the .ini, the logic which discovers WIN2K3 according to the VER command operates, and then prevents the 1.1 installer to be built. The fix is obviously to check about the version only if there are no explicit settings in the .ini. See attached patch to this effect VerCheck.patch.txt (GNU unidiff, against the version 20090316b.) I am guessing the setting WINXP=YES will do the job to build a 1.1 installer for Vista, but I do not have checked it yet. Second, for bare bones W2k targets (SP4 w/o IE6, which only have 2.0 Windows Installer), the /passive and /quiet and /norestart switches are not acceptable. It took me quite more time to come with a acceptable patch , which doubles the %VERBOSITY% stuff with a %QSWITCH% (either qb or qn). It is still not perfect , since for example it enables the Cancel button (and I do not know what /passive does, but I guess it doesn't). Also I broadly replaced throughout the script, but an educated guess is taht .NET 2.0 might require Installer 3.x at least, thus making it moot. Anyway I attach it in case anyone is interested. VerbosityMSI2.patch.txt Much more complex was the aim to have several 1.1 language packs (of course I am thinking about servers here, or MUI-enabled workstations). I succeded at manually building an installer which does that (by manually renaming the langpack.msi after their adminstrative installation), but I did not even try to enhance the script this way. Is there any interest?

This is news to me. Care to expand on this? Windows Server 2003 products may use a boot loader file named "Osloader.ntd" (NTLDR and NTDETECT.COM may still exist). I am uncertain between the relationship between the different boot loaders of Windows Server 2003. Well, Osloader.ntd is ONLY used when booting from ADS: http://support.microsoft.com/kb/843536/en-us Probably just like SETUPLDR.EX_ is used instead of SETUPLDR.BIN for PXE/RIS installs/PE's. Close. In fact, you should compare it with OSLOADER.EXE, which is (as Jaclaz already knows is the second part of NTLDR (the first one being the StartUp module which brings the computer into 32-bit mode). So if you compare them, you'll find they are extremely similar, they even have the same .PDB referenced; the only differences are in the PE header: there is a supplementary section, named .detect the ImageSize is bigger the checksum are different (better have to, since they are checked ) Now, if you consider the extra baggage at the end of OSLOADER.NTD, it is around 46 KB, and it is... NTDETECT.COM So I believe it works this way: PXE ROM, STARTROM.xxx sent with TFTP, asks for "NTLDR" but expects a .EXE (this is standard behaviour of Microsoft's PXE infrastructure), the server sends this OSLOADER.NTD packaged as a single file and the OsLoader works alone, without need to download a further NTDETECT.COM later. What I do not understand yet is how OsLoader does to "know" it should either load_from_disk/ask_via_tftp for NTDETECT.COM (normal case), or just have a look in memory behind itself (osloader.ntd case). The evident way to do it (just inspect the COFF header) is not that evident, since I did not see any reference to ".detect" in the binary; perhaps it does that by direct inspection to entry #12, without checking the name? OK, next stage is to build some frankenboot, i.e. paste StartUp and OsLoader.ntd as NTLDR, removing NTDETECT.COM and see if it works... Another try is to "append" ntdetect.com to setupldr.bin (or renamed version of it, like cmldr ) and see if Setup is able to boot without needing the ntdetect.com extra baggage... PS: I am a newbie here, so if this should be redirected to another thread (or a new one), please do; also I'd appreciate pointers to similar researches already done about OsLoader.NTD.

The first starting point is how to troubleshoot "Stop 0x0000007B" error messages that occur when you run Windows [...] Setup. I assume you saw it and this did not cover your case, even remotely. Officially, you cannot perform an unattended installation of mass storage drivers when you run the Setup program from the Windows CD ; Note however the small point saying In plain English, it means that this should work , and furthermore it is so widely known it works that MS updated the KB .However, since this is a common problem, PhreeZ devised another solution which might be easier to apply in your case (not sure). Hope it helps, Antoine

Hi guys, Marvelous reference site about unattended installation, so chapeau bas. I have discovered the [OemInfFiles] method, which seems to be the ultimate best to deal with newer disk-controller drivers. However, while experimenting a bit with it, I discovered a problem. We know we can feed WINNT32 with a Unattend.txt pre-cooked file. Furthermore, WINNT32 will do essentially nothing with the content of this file, it just parse it to recognize the sections and copy the result to winnt.sif inside $win_nt$.~bt, with two exceptions: sometimes a [setupParams] section is added/modified, for example to deal with /cmd: switch which is simply transformed to userexecute= option, or /copydir: switch which raises optionaldirs= option; or the accessibility options. The [Data] section is completely revamped... And this is where there is the problem. It seems that the line [Data] OemDrivers=OemInfFiles (which will raise the "installation" of the mass storage drivers at the next stage, textmode setup) is NOT PASSED THROUGH by Winnt32 . I have just played with single instance installation (local), but I fear similar problem could occur with networked or perhaps remote installation. Any comment? Something obvious I missed? EDIT According to trainee's neat description of the TEXTMODE method M2, I guess I should be able to force the inclusion of the drivers for the next phase using [OEMBootFiles] section, which will be copied from $oem$\textmode into $win_nt$.~bt\$oem$ by winnt32.exe, and then used appropriately (long description of this well-known process). However, it seems to me this is going to be girdle AND straps, isn't it? Antoine

CONGRATULATIONS Add me to the list "This topic should be pinned/sticky" At the start (January) of the project you were to build two "things", one being only the hotfixes (about 30 MB then) and the other one the "enhancements", including IE etc (I saw lists with 20 items). Right now the USP50SR1 I just downloaded is a 238+ MB package, and I fear it won't go with my Spanish computers... Am I the only one that sees interest in a 30-60 MB update with core things only?