Odin

Thanks for your replies most helpful. I do want to run it from a *.BAT/*.CMD (called from i386\svcpack.inf) however I could write an EXE tool to expand the "%1%" if there was suitable API to do this. It doesn't appear there exists either DirId or environment variable which cover what I am after, which is the C:\$win_nt$.~ls which is the location of the copied installation files done during the last part of the textmode part of installation.

What is the %foobar% or %12345% variable used to mean the local copy of the CD root that was copied to the %SystemDrive% (C:) during the text mode install part, for example like C:\$win_nt$.~ls\ where the directory C:\$win_nt$.~ls\i386 exists of a PXE based RIS installation ? Or more usefuly I am looking for a reference of all the value %99999% like environment substitutions that various Microsoft platforms have, ideally with which version of OS support each, what they mean, examples of what they expand too. What are they technically called by Microsoft ? I have seen EXPAND use in Registry types and also variable substitution. Maybe if I knew the correct phrase I could research some more.

Thanks for the replies. And ??? This is great thanks. Funny how the useful threads aren't sticky.

I gather there is no futher development of the tools known as HFSLIP by its creator. All the download links generally point back to a now nonexistant domain relating to it. However in my limited research on the internet I gather this tool was released under GNU GPL licensing and therefore wonder where the binary _AND_ source code of this tool can be found ? If the licensing information is correct it would allow someone else to take up the gauntlet and continue to maintain it, this is one of the benefits of the GPL that a package survival is no reliant on the creator. I have never used this tool so have no idea of its relative merit, nor understand why if its no longer being even distributed why it has a whole section on the message board to itself as it seems no longer relvant.

I'd like to know how to do this as well. Would come in handy in future. I guess there is a tool EXE I can run, with the target/suspect EXE to verify with some kind of X.509 security certificate. Also does the digital signature cover all bytes of the EXE file, maybe I can test it. So if I were to add bytes to the end would it detect that change. As some digital signature systems only cover certain sections of the EXE file, like the code/text/data/bss but not all of it. Maybe you know if webpage explaining how verification maybe performed.

Perfect Thank You. Completely forgot about catalog website.

I am after the very specific version of KB890830 from June 2010 since this is the last official version to support Windows 2000 since the end-of-life deadline. I am aware I can download the current and newer one (from the links I have included below). I am also aware for all intents and purposes it should continue to work on Windows2000 (even if not officially supported). However my request still remains: Does anybody know of a download link for the June 2010 release? Maybe you don't know the link but you have a private copy of the EXE but are unwilling or unable to send it, this is ok, you can still assist me. Could you please provide a MD5 or SHA1 checksum of the file you have. You may consider the following sites reputable locations to obtain the tool if you do not already have it http://www.etree.org/md5com.html and http://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html for Windows. Maybe you have a Linux system near by all systems installed within the past 8 years have one or both checksum utilities installed. Even if you see someone post their MD5 or SHA1 already to this thread please consider doing the same, if its not too much trouble. With enough independant reports this will allow me to obtain a copy of the EXE from a less reputable source than microsoft.com and have some confidence there is not some great conspiracy to infect me with malware with a trojaned copy. Thank you in advance. Please don't respond with any of the following URLs (I'm obviously already aware of those and can not find any way to nagivate to releases from a few months ago) : http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ad724ae0-e72d-4f54-9ab3-75b8eb148356&displayLang=en http://support.microsoft.com/?kbid=890830

Moving the order of KB955069 to the end of the list in svcpack.inf has cured the problem. Now the question remains, why are the patches applied in the reverse order to which they are "/integrate:" with ? This is awkward.

It is possible to use a Linux server backend to be the RIS PXE host. Maybe I should write up an article on that. DHCPD + TFTPD + SAMBA (This is certainly possible for Win2k+XP+2003 one click deployment; one day I might find a moment to work through Vista/Win7 matters to verify it can work too). I hear "gparted" might make a useful substitute for ghost. But if you already have ghost and it is doing everything you need/want. It just depends if having linux server side to deploy/install Windows would benefit you.

I used the "/integrate:C:\temp\mycdbase" /quiet with a bunch of Win2000 patches. The i386\svcpack.inf file lists the patches (but in reverse order to the integration sequence). This is not exactly what I want. Is the order of integration important ? Is the order in the svcpack.inf important, i.e. does it go strictly top to bottom ? Is there a logfile I can look at on the resulting installation which would allow me to see the order they were applied ? I perform the integration in the order of: * Roll up * Cumulative * Critical * Important * Moderate Within each section above they were integrated in the oldest to newest, based on MS bulletin number "MSyy-###" sequence. Which should give me approximate date order. I ask this because "KB955069.exe /q /n /z" was integrated but after first bootup is still shows as outstanding. So did something else undo the fix ? something I had expected to have been applied earlier. The svcpack.inf file has the Roll up patches at the bottom of the list (even though it was the first /integrate:C:\temp\mycdbase to be performed on top of a clean Win2000+SP CD media). Also does it matter if you perform the /integrate:C:\temp\mycdbase on a Single CPU machine or Multi CPU machine ? This is because the RIS PXE install complained that "i386\ntkrnlmp.exe" was missing. Which it is, the original Win2000+SP4 (no patches) CD has the file i386\ntkrnlmp.ex_ but after applying the /integrate (with additional patches since SP4); this file disappears and the file i386\ntkrnlpa.exe appears. The integration process was performed on a 2 CPU Windows 2000 system. When I started the RIS PXE based installation (on a system with 2 CPUs) I get the error, that it can not load i386\ntkrnlmp.exe over TFTP. "File ....\i386\ntkrnlmp.exe could not be loaded. The error code is 21. Setup cannot continue. Press any key to exit." This is very early on in text mode install, before hit F6 for storage drivers. I research the problem and find: http://support.microsoft.com/kb/262268 "Ntoskrnl.exe Could Not Be Loaded" Error Message on PXE Client" What I then did was disable one of the CPUs and restart exactly the same RIS PXE based installation on the same system and same data on server, and it installed just fine (it loaded "i386\ntoskrnl.exe" according to the TFTP logs). So something is making a choice here. Note that when I do an RIS PXE based installation of the original Win2000+SP4 CD media there isn't any problem with either 1 or 2 CPUs. Reading the txtsetup.sif is the most telling over ntkrnl{pa,mp}.exe being related to UP or SMP. Copying the ntkrnlmp.exe from the original SP4 media into the RIS share fixed the problem. Note the name of the file that is missing in my case is not exactly the same as the one in the KB262268 linked above, but non-the-less I think is serves the same function. Any thoughts on this one anyone ?

Thanks, yes this fixes the issue (version 7.4.7600.226). WindowsUpdateAgent30-x86.exe /quiet /norestart

Hello, I am trying to use Microsoft Baseline Security Analyzer Windows 2000 Server, to check a (new) installation has all the latest updates. However it has been a few months/years since I last did this and while I have installed all the updates I think I need from my repository, I'd like to be able to cross-check I have as many patches as possible applied. I installed MBSA 2.1 for it to complain "Computer has an older version of the client and security database demands a newer version. Current version is and minimum required version is 5.8.0.2678". I know MBSA 2.1 used to work with Win2000. So I isntalled MBSA 2.2. To get the same error. Obviously Win2000 is well past support from microsoft, so is the problem that microsoft have withdrawn the data or not kept things compatible ? Is it possible someone has a wsusscn2.cab file which is compatible with MBSA which is in effect the most up-to-date and working version of wsusscn2.cab for the Windows2000 series ? I believe I can manually install this file and have MBSA work with the offline copy (i.e. don't connect to microsoft.com to check for an updated cab and overwrite it). Alternatively what other tooling is available that understands the operating system patching/update system which can do a similar job ? Thanks

Using nLite to merge the driver in was the only cure. So whatever it does it does it more correctly than the manual attempts I had tried.

Arrrgggghhhhh! I would like to perform an _attended_ install of Win2003 R2a, on a machine which has no floppy drive and is located in a data centre. However Win2003 R2a does not support the 3WARE RAID card by default. I have PXE installs working (not using MS RIS but a linux based setup). Here are the approaches I have tried (all 3 of them, with the problems I faced with each) : Approach 1) Edit txtsetup.sif to copy the 3ware driver .SYS file. I followed all the instructions for this approach and the text mode UI works, allows me partition the drive, does a format, then a copy, then reboots. When it reboots I get a Blue Screen of Death very shortly after the Windows logo, presumably it doesn't load the RAID card driver early enough. The changes to txtsetup.sif look like this, the plusses denote lines I added: --- txtsetup.sif.orig 2007-03-01 00:26:17.000000000 +0000 +++ txtsetup.sif.mine 2007-03-01 04:26:30.000000000 +0000 @@ -724,6 +724,8 @@ 3dwns.cur = 1,,,,,,,,3,3 3dwnwse.cur = 1,,,,,,,,3,3 3dwwe.cur = 1,,,,,,,,3,3 +3waredrv.sys = 1,,,,,,3_,4,1,,,1,4 40291730.ppd = 1,,,,,,,,3,3 40293930.ppd = 1,,,,,,,,3,3 409.csv = 1,,,,,,,59,0,0 @@ -19450,6 +19452,9 @@ PCI\VEN_8086&DEV_3092&SUBSYS_00018086 = "i2omp" PCI\VEN_8086&DEV_0600 = "iirsp" PCI\VEN_1119&DEV_0300 = "iirsp" +PCI\VEN_13C1&DEV_1002 = "AMCC" +PCI\VEN_13C1&DEV_1003 = "AMCC" +PCI\VEN_13C1&DEV_1004 = "AMCC" [Map.Computer] sgiborg_mp = "*SGI-3" @@ -19595,6 +19600,7 @@ cpqcissm = cpqcissm.sys,4 hpcisss = hpcisss.sys,4 afcnt = afcnt.sys,4 +AMCC = 3waredrv.sys,4 @@ -21981,6 +21987,7 @@ hpn = "Hewlett Packard NetRAID-4M RAID Controller" perc2 = "Dell PERC 2/3 RAID Controller" perc2gat = "Dell PERC 2/3 RAID Controller (Gatling)" +AMCC = "AMCC 3ware 9000 Series SATA RAID Controller" Approach 2) Use $OEM$\TEXTMODE now this only works when I specify OemPreinstall=Yes. The problem with that is the install presumes I am running unattended (when I wish it to not presume anything about my configuration). The problem with that is that it automatically deletes any existing partition on the RAID array and create a new one that fills the entire drive. I do not want this. Approach 3) I have added various options to winnt.sif to stop the reparitioning but NOTHING I have found actually stops it. [data] AutoPartition=0 UnattendedInstall="No" [unattended] UnattendedMode=ProvideDefault OemPreinstall=Yes OemSkipEula=Yes Repartition=No I have also tried setting up the partiition to the correct size (using Approach 1) but then rebooting to use Approach 2. But again it deletes the existing paritition and overwrite it. I have also tried to create two partitions the first being the size of C: I want and the second the remainder of the drive. But it deletes them both and reformats with one big C:. The only option I can think of now is to install the OS using the entire drive and see if windows disk manager allows me to shrink the C:. I dont think it will. Just for clarify with Approach 2 or Approach 3, I am able to get into the remainder of the GUI base dialogs for installation. So this method works but my C: drive is much too big. So my question is this: Is it possible to have an attended install which is able to pickup my RAID card drivers and use them both during the text mode install and after the GUI reboot ?

Forgot to add... after chaning any paging file settings the system almost certainlty needs a reboot, to both sort out the allocated space in the file system and to sort out the memory layout of the kernel.

This is something that always struck me. How does a system administrator have control over their users trash can files. For example there does not seem an inbuilt way to automaticalyl reclaim trash can files if they are over a set age since deletion. So a guess maybe for you to check every user accounts trash can and empty it. The next thing maybe worth booting the machine, checking in task manager the amount of used memory and seeing if you can set the paging files to zero or rather turn off all paging support (not recommed with less than 256Mb RAM). A system does not need it until it runs out of ram for the acive set of data currently in use, since you can't use the system effectivly while defrag anyway this supposes your system is idle when you do all this. Then run defrag. again and again. Until happy. Then go back and put the paging file back to normal. Then reboot.

I did crack it. Basically for those interested, the Win2003 RIS unattended network install process works like this: PXE Boot the sytem directly into Win2003 SETUPLDR. I use PXELINUX to trampoline this, since that allows me to have a PXE boot menu (menu.c32) to decide what I want to load and do. Files (with md5sums): d30318675bfe947b5635b4f0a093c92 binlsrv.py 2afc0e70ab1c581192a1bb34d52a5edd infparser.py b26d94dc7ec3f3d771482482fb4e8b73 ntdetect.com 8fedbc02ae02d700c60082ec42be5ac0 NTLDR 4c137e64f0045e81985c8971c273d7db txtsetup.sif 4882e72ae46a1eea0d65c3b9e63c5830 winnt.sif 9a233c8f0af77bec3484bce62ee612b0 X86PC/pxelinux/pxelinux.cfg/default 48c4a984692a432401ad425f59108a0a X86PC/pxelinux/pxelinux.0 md5sum: X86PC/pxelinux/os: Is a directory md5sum: X86PC/pxelinux/os/win2003: Is a directory 71258dc24a2719d41e479b8568539f06 X86PC/pxelinux/os/win2003/startrom.0 8fedbc02ae02d700c60082ec42be5ac0 X86PC/pxelinux/os/win2003/NTLDR b085f12bb1e907cca68791d8f100bec7 w2k3std/i386/winnt.exe NTLDR is actually SETUPLDR.EX_ expanded, renamed and fixed from the ris-install.tar.gz package. startrom.0 is I386/STARTROM.N1_ expanded and renamed. In order to boot from PXELINUX its config entry looks like: label Win2003 Standard Edition [INSTALL] kernel os/win2003/startrom.0 In the winnt.sif file use the sample out of the ris-install.tar.gz package and edit. The [data] OriSrc = "\\SERVER\SHARE\w2k3std\i386" <..snip..> [setupData] SetupSourceDevice = "\Device\LanmanRedirector\SERVER\SHARE\w2k3std" <..snip..> I found the SERVER made little difference in the entire install process as it always tries to connect to the file sharing (SAMBA/CIFS) of the TFTP host, regardless of what you set the server name to. The SHARE name is important for 2nd stage of the install, but the subdirectory "w2k3std" is used as the TFTP prefix. Then on your TFTP server copy the whole install CD contents to "w2k3std", I also renamed every single file under there to be lowercase. I then configured the TFTP server (tftp-hpa) to always convert any UPPERcased request filenames to lowercase before looking on the file system. I also set it up to convert backslash to forward slash. Then make the TFTP root directory available to share on the SHARE you set in winnt.sif. The next thing you have to do is get RIS compatible Ethernet card driver available and installed into the I386 directory as *.SYS files and accompanying *.INF files. The example INF files I have seen seemed to be Unicode txt files no plain ASCII. This is because the simple BIOS call base NDIS ethernet card driver switches for the propert ethernet card driver (I suppose for performance reasons). Now you should be ready to run startrom.0 via PXELINUX. This will load NTLDS, ntdetect.com, ready the SIF and look for some optional INF files, all via the TFTP root directory looking for the names in the cases I specified above. Then once SETUPLDR started, it will send out a request on port 4011 UDP (PXE port with plug-n-play hardware information request, its bcaiscally asking the server if the driver for this systems ethernet card is available inside the installation catalog). See the ris-install.tar.gz package for information on the python infparser.py and binlsrv.py tools. You basically run one to parse and scan the INF files to produce a catalog cache file and then run the binsrv.py to act as a TCP server on port 4011 to answer the installation request. If SETUPLDR is happy you will get the usual F6 for 3rd party drivers. It will continue to load all the remaining files it needs via TFTP using your subdirectory prefix from winnt.sif before "i386\blah.fo_" maing "\w2k3std\i386\blah.fo_". Once the 1st stage install has completed you will be presented with F8 for licence agreement, then partition setup and format. Once the new C: system drive has been formatted (on the 1st disk) it will then start copying files into it, to allow for rebooting into the 2nd stage install (the GUI part). I can't remember if this copying was done via TFTP or from the network share CIFS volume. Maybe next time when i do back I will note it down. You are then rebooted. This time you dont PXE boot you bootup on C: that it just created. Before the GUI actually starts (while the Windows Server, on black screen is displayed) the system will be reading files via network share CIFS volume. It seems to keep trying forever at this point, that is, if you dont have the files or server setup the install just keeps re-trying to connect and get the file without displaying any kind of error to the installation operator. From here its pretty straight forward. I have one final problem with my method above.... my system drive is E: even through its located as the first partition on the first drive. This is because of my FAT C:\ staging partition that is on the second drive, first partition. Since I delete the staging partition from the system after the install, how do you make it do what I'd expected in assigning the new drive C: and moving my FAT to E:. Hope this is is use to others who want to be able to do floppy and CDROM less remote installations and get the same experience you get from the bootable CDROM to allow you to partition using SETUPLDR.

Ok i have learnt much about the setup process with Win2003. I have managed to boot into SETUPLDR.BIN via PXE, it then tries to contact a PXE server on port 4011 after loading a few files over TFTP. But I'm sure by tomorrow I shall crack it.

Thanks for the reference, still looking through for a suitable resource, but everything seems CDROM based or just floppy boot disks. There are two approaches to my problem I can see: 1) One based on someone with a better understanding than me of the Win2003 bootable CD / install process, that could possily help explain how to kickstart that process without actually booting from a CD. 2) Work around the problem from the other angle and somehow present the computer with a working CDROM driver that is able to load from an ISO image over TFTP. Infact this approach really interests me (for other useful situations). That is create an MSCDEX like driver that uses BIOS calls to the ethernet card, just like PXE/BOOTP does to make simple requests to a TFTP server for blocks of data out of the real ISO image stored on the server. This idea seems completely possible within a 64Kb driver to run under DOS.

Confirm the network address and subnet netmask are correct and configured into DHCP correctly. Confirm the router IP address option is setup in DHCP (to point to your standalone DSL router). Confirm the DNS server IP address is setup in DHCP (to point to your Win Server, presuming you have DNS enabled and setup, which is certainly a recommendation (if not a must) with Active Directory enabled), you can setup backup DNS to be your DSL ISPs, but make sure they are not listed first.

I'm looking for some advise on how I can go about bootstrapping the install process for Win 2003 (standard or web edition) without using the bootable CDROM method. I currently have a working PXE network boot setup with a IP based KVM with a number of rack based servers for which local CDROM access would be a problematic means to start a refresh install. I am able to sucessfully get a system into a state where they have a smallish (2Gb) Win98SE VFAT partition and the end of the disk with a cope of the entire Win2003 Std Edn CD on there. I am able to bootup and run C:\I386\WINNT.EXE and this appears to start the process of copying files into C:\$LDR$ C:\$WINNT.LOG C:\$WIN_NT$.~BT C:\$WIN_NT$.~LS C:\INF000.SWP C:\INF001.SWP C:\NTDETECT.COM C:\NTLDR However it appers to have skipped the F6 to load 3rd party drivers, F8 to accept license and the partition setup parts you get from the bootable CD method. I would like to experience the whole setup experience just like the CD install if possible. Does anybody know how ? Is the fact my base DOS version if from Win98SE causing me any problems ? Your advise and thoughts appreciated. Thanks.