pnkiller78

Yeah, you are right, in winxp d1 = \I386, I was using Win2K, and its dosnet.inf file has d1 = \ maybe that was the problem, didn't know that you was using xp for building your script.. I tested that way, old fashioned way, just to be completily sure, the I386 folder on CD Root, and the same result... I think will try using ms baseline... I have never used but I think it will not be too much challenge Another idea I was having, was to binary compare every UpdateRollup file againts the ones that are on the running system, to see which one differs and maybe if something is missing... For MDAC... I used the same (2.8 alone, no SP1 or SP2), and install fine via cmdline... I resolved the Q832483 thing, by decompressing ENU_Q832483_MDAC_X86.exe file, and recabing using IExpress only the 4 files actually needed by my system. telling IExpress to run the INF as the default command, everything worked fine... the file stayed there... my cmd file like this @ECHO OFF Title Applications Install FOR %%i IN (D E F G H I J K L M N O P Q R S T U V W X Y Z) DO IF EXIST %%i:\APPINST SET APPINST=%%i:\APPINST echo Installing Microsoft .NET Framework 1.1 SP1 rem start /wait %APPINST%\netfx\netfx.msi /qn /log C:\NetFx.log start /wait %APPINST%\netfxsp1.exe echo. echo Installing Visual Basic 6.0 SP6 Runtimes start /wait %APPINST%\VB6SP6.exe /Q:A /R:N echo. echo Installing MDAC 2.8 start /wait %APPINST%\MDAC_TYP.exe /C:"DASETUP.EXE /Q /N" /Q:A /R:N start /wait rundll32.exe iernonce.dll,RunOnceExProcess start /wait %APPINST%\Q832483.exe /Q:A /R:N rem register sqldmo.dll here cause until now it has all the .rll files in their proper location under System32\Resources start /wait %SYSTEMROOT%\SYSTEM32\REGSVR32.EXE /s %SYSTEMROOT%\SYSTEM32\sqldmo.dll echo. echo Installing J2SE Runtime Environment 5.0 Update 5 start /wait %APPINST%\j2re.msi /qn /norestart /log c:\J2RE.log echo. EXIT Will post what i found...

@tommy... No, now i'm only trying Cd install, clean Cd install and multiboot Cd install... actually it's the same..., just that the <CD Source Media Root> is moved from <DriveLetter:\> to <DriveLetter:\multiboot_path\> , the diference is actually the SetupSourcePath = '\' which is changed to SetupSourcePath = '\CUSTOM_PATH\' Well, hope everything helps, cuase HFSLIP rocks By the way, tommy, you think that maybe someday in the future, you can consider integrating MDAC (more recent version)... that would be totally cool... cause in fact MDAC 2.5 SP3 it's allready on win2k sp4...; i resolved my previous problem by installing in my CMD custom application file and calling RunOnceEx proccess inmediatly so all registering scheduled by MDAC are performed right after the install, after all, the mdac files are not used in that stage of installation, so it not hurts to register everything there.., hotfix it's not installed even if it run successfull (checked the logs), maybe some WFP issue (not sure though).

Well, if the files filename1.fi_ and filename2.fi_ are in the <SourceDrive>:\I386 folder during setup it will work fine, but if they are located in <SourceDrive>:\I386\FOLDER1 and <SourceDrive>:\I386\FOLDER2 respectily it will not work, at least that FOLDER1 and FOLDER2 are declared in DOSNET.INF like this [Directories] d1 = \ d2 = \folder1 d3 = \folder2 . . . [Files] d2, FILENAME1.FIL d3, FILENAME2.FIL [] I think that there's an error on Yzöwl's script, not completely sure, but in DOSNET.INF, under [Directories], d1 = \ refers to the <SourceDrive>:\I386 folder, the files are actually there, that's why in the [Files] section you only especify the filename, in Yzöwl's script he creates the DOSNET.INF like this [Directories] d1 = \ d2 = \I386\folder1 d3 = \I386\folder2 . . . [Files] d2, FILENAME1.FIL d3, FILENAME2.FIL I think that could be the problem because WinSetup would think that FILENAME1.FIL is in <SourceDrive>:\I386\I386\FOLDER1 Personally i don't like the idea of recreating the needed folder structure under the <SourceDrive>:\I386 folder. Well imagine this situation. You put this files under you HFEXPERT\SYSTEM32 folder... HFEXPERT\SYSTEM32\MyDir\DllVer.dll HFEXPERT\SYSTEM32\YourDir\DllVer.dll and suppose that the file in <MyDir> is a newer version that the same file in <YourDir>, when those files get installed there would be 2 version of the same DLL in the system, one being older that another... I don't know if that could create problem in WinRegistry, but for me would be better just put everything you need under <SourceDrive>:\I386, there will be no need to alter DOSNET.INF with extra source folder in the [Directories] section, just throw the files with d1, FILENAME1.FIL, there would be a more clean <SourceDrive>:\I386 folder, not those strange directories scatered all over the place... and the need structure would be recreated by TXTSETUP.SIF as far as I know, somebody correct if I'm wrong, one of the functions of DOSNET.INF is to copy the source files on the hard disk during the textmode part of windows setup, I think is uses a folde called $WINNT$.$LS$ or something like that; after that, the final location of those files in created by the [WinntDirectories] section on TXTSETUP.SIF. So, i think that cosmetically is unncessary to recreate the custom folder structure under the sources media. The logic in my script is just to throw the files in WORK\I386E, then let HFSLIP compress them and add them at the end of DOSNET.INF using d1, FILANEMES.FIL, then I insert the final (and so needed) folder structure in [WinntDirectories] section in TXTSETUP.SIF along with their proper filenames declarations in then [sourceDiskFiles] section. That way, you just end with one version of any file, the source files stay in <SourceDrive>:\I386, and the ultimate goal of all this is reached succefull. Oh, by the way, i tested the halmacpi.dll thing, and it didn't work too, this file, I think, it's the Hardware abstraction layer (HAL.DLL) that end in system32... but this particular file (halmacpi.dll) is for multiprocessor systems kernel... that why I think that have nothing to do with my problem, cause my test system is an UniProccesor system, the proper hal.dll I think it's halaacpi.dll, cause in fact TXTSETUP.SIF rename the file properly acording to the detected system during installation, you can check out this in [Hal] section in TXTSETUP.SIF... I suppose the during the hardware detection WinSetup detect the type of system and TXTSETUP.SIF install the proper file, in my case I'm testing on "ACPI Uniprocesor PC", so setup uses the halaacpi.dll, rename it to hal.dll an install it... I compared the expanded halaacpi.dl_ that it's my in my sourcess media against my installed and running C:\winnt\system32\hal.dll and both files are the same..., that why I think that halmacpi.dll got nothing to do with the UpdateRollup problem in WU... and another clue it that in your previous HFSLIP version HFSLIP_51017 there were no problem with WU... everything worked like a charm... also, in this version there are some application which I was testing to install via a CMD file launched in SVCPACK.INF that now doesn't install, these program (Paint Shop Pro 9, and TextPad 4.7.3) I install them using MSI files and now if use the /log switch to see what happened they abort with this error in the log DEBUG: Error 2103 : Coudl not resolve path for shell folder 26 MSI (s) (28:2C) Product JASC Paint Shop Pro 9 -- Internal error 2103, 26

OK, that's ok, but recreating that folder structure in the final SOURCESS\I386 would make that installation directory look a little overcharged... i see why you add the folder entries on DOSNET.INF [Directories] section, to allow WinSetup find the files in that folder structure inside I386 at install time. I would prefer just to compress the files and put'em on I386 using d1, filename.fil in DOSNET.INF, less cleaner I386 folder.. for this to you only have to modify the line 31 where you xcopy the files along with the structure to just copy the files.. maybe a simple copy "%DirName%" "WORK\I386E" /y>nul

@Yzöwl Wow... That script really kick my **s I tested and it does the job, just one thing: AFAIK the files doesn't need to be copied to the WORK\I386E folder along with the folder structure, you just need to copy the files plain inside WORK\I386E, cause after that they are compressed by makecab and incoporated into the SOURCESS\I386. After that, during Windows Setup the structure is recreated inside WinNT isntallation directory using the directory numbers information stored in txtsetup.sif (somebody correct my if I'm wrong); apart of that is great, by the way: I didn't know that cmd prompt can do that... Well, i suppose that if tommy wants to include something it will be yours, mine it more simple and easy to understand for begginers (like me), but yours is more pro... it doesn't need any dummy files nor third party tools.. great. By the way, where do you think I can read a more professional doc about Command prompt scripting for Windows..., i would really want to learn... Thank you.

No, that didn't do the trick, i renamed the file and run WU and still tells me that Update rollup is not installed.

@tommyp thank tommy for the ! alternative, it worked... ok.. I figured out how to make directory recursion and read the contents of files... increment the directory number and everything... for the directory recursion i needed an extra tool, called munge found on this page, it allow you to replace strings inside files, i put on HFTOOLS folder.., it needed cause when you issue a DIR command with a /S switch it prints the absolute path of the directories it founds.. so, here we are working with relative paths, so they have to be cutted to only include the relative path.. Sometimes, there are aplications (like SQL Server SQL-DMO) which requiries that certain files to be present within a folder structure hardcoded inside the application to work properly, and sometimes this structure have empty folders before reaching the folders with the actual files needed by the aplication. So, we must exclude those empty folders, and Windows Setup recreates the empty folders when it installs the files. To skip the folders not containing files (just subfolders), I had to put a DUMMY.FIL inside them, 'cause I couldn't figure out how to exclude empty folders in the final FOR inside the batch, so I created DUMMY.FIL file inside them and removed those folders with DUMMY files from the paths used in final list which will run the final FOR statement. One usefull thing with this it's that you can also put folders inside the system folders used by windows, and the script will include it the same way you create 'em, to test it try puting a folder inside system32 and you will see in TXTSETUP.SIFhere's the script Hope, this helps other people like me...

Wow, wow I figured out the problem with the incrementing thing in the directories... you have to enable DelayedExpansion for the command prompt to work, by default is disabled on Win2K, the script would look like this, pay attention on the bold enviroment, you no longer use "%", you use "!" ... that would take care of the directory thing in HFEXPERT folder... you could put any directory you want inside WinDir, one challenge would be how make directory recursion... by example how to create this properly on "WinDirectories" ...this must have to be traduced on this on TXTSETUP.SIF [WinDirectories] entry ...of course, this would have to include DIR1 only if it have file inside it i don't have any idea about it...

@tommy Hi.. I made an small modification on the little script, but for some reason the Directory number increase is not working, I started a new CMD prompt with /V:ON /E:ON paraments and nothing, even enable DelayedExpansion on the registry on LOCAL_MACHINE and still doesn't work..., take a look, maybe you could see if it and error on my script or and error on my computer Also... I tested the new version of your TOOL with Win2K Pro, and when I go trough WU it tells me that the UpdateRollup is not installed when in fact it is... in your previous version (HFSLIP_51017) WU was happy about it, didn't display any errors..., I read in the http://www.vorck.com site about some problem with this file halmacpi.dll, actually you delete the file when you extract it in your script in the :HFRU section... in both script versions, but the HFSLIP_51017 version works OK, new version not... I attached my reports... wu_errors.zip

@tommyp Hi, In your UPDATE LOG inside the HFSLIP you mention for this to fully work you also need to modify the FOR statement in the creations of the HFSLIP.CMD file in the :UPDATE_INIT sectionin this sentence a custom path must be declared to allow a multiboot image to work, by example ...this custom path could be an enviroment variable, so if someone wants to create 2 or 3 CD images, just especify this path in each HFSLIP_XXXX.CMD run and every image could be created with the correct path inside the CMD file. Will try this new version... excelent work Also, I'm trying to integrate components inside the sourcess for applications developed on VBasic 6.0, SQL Server 2000 and Crystal Reports, so the HFEXPERT folder has been my saviour, i could register OCX components for VB, Crystal.. but SQL Server's SQL-DMO requiries (at least in the documentation) that 2 Resources files are located inside [WinDir]\System32\Resources\XXXX (where XXXX is the country languaje code 1033 for English U.S.), so custom folders have to be created when installing the files from the CD... I made a little script which read the DIRECTORIES inside of the HFEXPERT folder and add them in the [WinntDirectories] but have one problem, don't know how to increment or decrement the Folder number in the statement in Bold I know that this is very specific for my case, but maybe other people would need to create custom folder inside WinDir to similar purposes, and your tool is in the right way for doing this, there are aplication that requiries specific path to be created from some point inside WinDir... ...ahh... could be possible that you add legacy support in your TOOL in HFEXPERT section to include windows Help Folder ([WinntDirectories] #21) And, as usual some "off the topic" question Have anybody succefull installed MDAC in Win2k calling it from inside SVCPACK.INF after slipstreaming the sourcess with HFSLIP, i'm trying with 2.8 SP1 version, tried with the original package, repacked with IExpress to be silent, and it doesn't install... no error, will try later to run it with parametter to see interface and watch any error that may occur...

Well, for the HFSLIPxx.INF you need to modified the CMD files located on the I386 folder and the other on the I386\SVCPACK folder, the lines you need to modify are just the ones with the FOR statement, by default these lines set an enviroment variable which point to the location of the INF files, in both files this statement is trying to find the I386 folder location, asuming that the I386 folder must be located below the root of the drive containing the sources, modify them and make them match the path you use when you map your network share. For the WGA1.dll and WGA2.dll you must be sure that these files are located on the I386 folder i guess, i'm not sure about this, cause right now I writing on another machine, can't see my test sources, but should work ok, I have installed using multiboot CD and everything worked fine for me... in these cases the I386 folder is not located below the root of the CD.

Well, I use the method described in this site Windows 2000 Multiboot CD After running the script I move the SOURCESS folder to the SETUP folder described in the method, rename the folder according to the version of the OS I'm slipstreaming (PRO, SERVER, ADVANCED <<I have not have tested ADVANCED>>) and modify the HFSL???.CMD files, just the line with the FOR statements from this... ...to this (this is the case when the sources W2k pro CD it's on this path) Like I said before is not big deal, just change the I386\HFSLIPWU.CMD and I386\SVCPACK\HFSLIP.CMD files I understand that in the FOR statement you are searching in which drive the standard I386 folder or I386\SVCPACK folder are placed... as a suggestion maybe you could read in an enviroment variable in the begining of the script if the user running the script want to place the sources on another path, maybe like the way you read the I HAVE READ THE INSTRUCTIONS statement, if he just press ENTER the standard path could be assumen, otherwise the ENVIROMENT variable would be used... just a suggestion of course... the only thing in SVCPACK.INF file that need to be changed is the initial backslash in this line ...to this Oh... and you copy the TXTSETUP.INF file to the BOOTDISK directory and change the SetupSourcePath line from this ...to this and leave the original copy in the I386 folder without any change... just copy the file in the BOOTIMAGES folder after that all work like a charm..

No problem tommy.. and by the way, I prefer your method. I have tried nLite, manual SVCPACK.INF, but not tried Ryan's Pack But your script seem's to be cleaner and more professional. Also, you explain everything in your guide, one can see how the script works and understand it (well, more or less ). Just have one sugestion.. for people (like me) who make multiboot OS disc, the line in SVCPACK.INF always end like this CatalogSubDir="\I386\SVCPACK" and has to be changed everytime to CatalogSubDir="I386\SVCPACK" for the [setupHotfixesToRun] to work so, you have to uncompress it, modify it and compress again , well it's not big deal, but without the first backslash works ok not matter if you want to use a different path sources or the standard X:\i386 the two cmd files the script creates have to be edited as well, but that's ok, cause they are uncompressed. After that it's excellent, but it could be outstanding and totally awesome if it could slipstream/integrate drivers like nLite, although I have read that you can run nLite to do that over SOURCESS folder. Thank you.

Here it is.. Tommy.. You think that it could be possible to make the script know the version numbers of the files it slipstreaming. I know that this is not a "magic wand" or something like that, but I was just thinkin' and many thanks for this tool, i'm administering a small 30-40 computers network and this had saved my day.. Oh, I have a question off the topic, obviously should not be asked on this forum Why the HfChkNet tool reports many files with the correct version number but mismatchet checksum? Could be an error on the cab file HfChkNet download from Shavlik's site? ..cause it's obvious that the tool does not modifies or tampered the files.. Thank you. PRODSPEC.zip

The version of the file rdpwd.sys i have on the SOURCESS\I386 is 5.0.2195.7006 My HfNetChk log shows the same version after I install the OS on VMWare. I'm just curious why the script dosn't slipstream this file. Also I downloaded the same hotfix from microsoft to make sure the file wouldn't be corrupted or something, tested with Winrar and everything was ok.. The kb899591.cat file is in I386\SVCPACK like the other files... don't know what happened. Of course, maybe I could compress manually the dll, but that the point of the tool.