Martin H

Hi Jeremy Thank's for the tip mate, and the VMware restore trick is brilliant I have never tried it out myself i must admit(adminstudio), but seeing as my only needs for such a program is to accurately capture traced reg-entries/files for making 7z sfx installers or to capture new tweaks to my regtweaks.reg file, then this Regshot unicode tool pretty much sums it up for me... Anyway, i confess that you've got me curious and i'm gonna try it out sometime soon, me thinks CU, Martin.

Update packs are IMHO a very nice concept, but personally, then i would rather recommend HFSLIP over an update pack for these couple of reasons : You decide for yourself exactly which updates and extra's to include and which not to include. You don't have to wait for an update pack to come out(most new updates are directly supported and if one isn't, then it can be placed in a special folder for being installed from svcpack) It is non-language dependant and the registry information is taken directly from the INF's in the updates. Since the script is open-source and written in plain cmd syntax, then you can see everything that's going on behind the scenes and you can even mod it if wanted. Not to say that the OP shouldn't use an update pack, but i just wanted to add another solution to the table, though (btw, HFSLIP also supports slipstreaming your custom drivers into driver.cab and integrating switchless silent installers, nLite/RVMintegrator addons/packs, codecs, appreplacements, REG, INF and CMD files + stuff like IE, WMP, DirectX, MSUpdate and WGA etc.) And yes, i admit that i'm guilty of being a complete HFSLIP fanboy

@Siginet: I just wanted to inform you that the thread title states that it's a Windows XP Post-SP2 pack Thank's for your efforts, mate

@Oleg Sch: When slipstreaming 7z SFX executables directly into the installation source(I386) and references them in TXTSETUP.SIF and DOSNET.INF to be copied over to the systemdrive during textmode-setup, then i get the following textmode filecopy errors for each of the executables : This problem can be fixed by running modifyPE.exe on them first(Thank's Tomcat76 ), but i was thinking if you would possibly consider changing the module so that the headers of the produced executables wouldn't appear borked to Windows Setup ? Thank's in advance.

Microsoft Security Bulletin Summary for April 2008 : http://www.microsoft.com/technet/security/...n/ms08-apr.mspx Jeez, some people...

Hi Cronic and welcome to the forum, mate For the next time, then please post in the nLite forum section when having problems with nLite'd installation sources(i'm sure this post will be moved there by one of the helpfull mods around here). When you post in the nLite forum section with a problem, then please also attach your 'last session.ini' file found in your nLite folder under the 'Presets' subfolder. I remember from when i used nLite, that there is a component removal-option for various command-line utilities like e.g. ping and xcopy etc, so make sure that you haven't choosen that specific component for removal, as that would obviously explain your described issue, then

As i said, then your 3. question is atleast clearly answered in that guide, but i wasen't sure about the two others, though...

3. Please read the MSFN unattended guide linked at the top of the forum. Chances are that your other questions are also covered by that guide, but i wouldn't know, as i have never personally been interested in that particular aspect of unattended installs(i.e. editing boot-screens/bill-boards) and just always used the classic Win2K setup routine(when i used WinXP)...

@ zeezam - For next time, then use '/?' to list available switches for a cmd command. The one you're looking for is '/y'(overwrite without prompting). Also, you need double-quotes when theres spaces in command-lines. Tip: You can set all wanted xcopy switches after eachother(like e.g. '/eh' instead of '/e /h'). Also, non-existing destination folders are always auto-generated by xcopy when using a backslash after the folder name. If run from CD(WinXP version) : @echo off setlocal enableextensions set src=%~d0\I386 set dest=%systemdrive%\I386\ set key=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup xcopy %src% %dest% /e reg add %key% /v "Installation Sources" /t reg_multi_sz /d "%dest%\0" /f reg add %key% /v SourcePath /d "%dest%" /f reg add %key% /v ServicePackSourcePath /d "%dest%" /f endlocal If not run from CD(WinXP version) : @echo off 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:\WIN51 set src=%%i:\I386 set dest=%systemdrive%\I386\ set key=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup xcopy %src% %dest% /e reg add %key% /v "Installation Sources" /t reg_multi_sz /d "%dest%\0" /f reg add %key% /v SourcePath /d "%dest%" /f reg add %key% /v ServicePackSourcePath /d "%dest%" /f I don't really understand how there can be files left in '%systemdrive%\I386\' upon a fresh install, but if you somehow have that, then add the '/y' switch to the 'xcopy' command-line. Edit: Sorry, after re-reading your post, then i can now see that you wan't to use the destination path: '%windir%\Driver Cache\i386\', so you'll then need to change the script alittle, then...

RyanVM's Post-SP2 Update Pack : http://www.ryanvm.net/msfn/updatepack-sp2.html Xable's Post-SP2 Update Pack : http://xable.net/xp-sp2-update-pack-contents.php

Hi Teh_Tech I recommended you the "$OEM$ folders + batchfile" method, since it's the easiest for beginners, but of course you can use whatever method you preffer(i personally use "RunOnceEx from CD"). Anyway, if you're going to use the "$OEM$ folders + batchfile" method, then you're right in that you just need to add that extra 'GuiRunOnce' section to 'WINNT.SIF'. As the guide also mentions, then the folder(s) in '$OEM$\$1\' will be copied over to the systemdrive during the installation of Windows, so e.g. 'XPCD\$OEM$\$1\install\', will be copied over to e.g. 'C:\install\'. Then you just add everything you wan't installed + a batchfile into e.g. 'XPCD\$OEM$\$1\install\', and in the batchfile you just add lines like e.g. : start /wait %systemdrive%\install\SomeApp.exe /S Also, it's important to note, that whenever you're using the '$OEM$\$1\somefolder\' method, then you need to set 'OemPreInstall' to 'Yes' in WINNT.SIF, as else the folder(s) will not be copied over during the installation of Windows.

The '*.CA_' files are cabbed(compressed) catalog files and not updates and you've got them as a result of having used some tool to slipstream updates into your source distribution. If you're having a problem with the slipstreaming process, then you need to make sure that you're doing exactly as intended with that tool and then try again with a fresh source. If you wan't to use the svcpack.inf method instead, then again, you need to start over with a fresh source...

I wrote a little batchfile for doing just that in a previous post today : http://www.msfn.org/board/index.php?s=&amp...st&p=751351

Thank's again Kelsenellenelvian Hi Tomcat76 Many thanks for your reply and yes, i could see from the code that subfolders are checked for existence in SOURCESS and isn't re-created if missing, but just wanted to know if you guys thought that it was allright to do so, or if you thought that it would be a bad idea or something, but of course it depends on myself and if i'm going to miss those missed binaries or not... Anyway, since i'm sure that i will not miss them, then i will just keep on using a SOURCE folder without those unneeded folders... Thank's again, mates

You could do something like this... Make a folder named 'Updates' with two subfolders named 'Type-1' and 'Type-2'. All type-1 updates goes in 'Updates\Type-1\' and all type-2 updates in 'Updates\Type-2\'. Copy/paste the contents further down into a batchfile and save it in 'Updates\'. Run the batchfile. @echo off title Installing Updates . . . for %%g in (Type-1\*.exe) do ( echo. echo Processing %%g echo Please Wait . . . %%g /q /n /z) for %%g in (Type-2\*.exe) do ( echo. echo Processing %%g echo Please Wait . . . %%g /q:a /r:n) Here is a version for WinXP-SP2 users, which defaults to the QFE branch for Type-1 updates : @echo off title Installing Updates . . . for %%g in (Type-1\*.exe) do ( echo. echo Processing %%g echo Please Wait . . . %%g /q /n /z /b:sp2qfe) for %%g in (Type-2\*.exe) do ( echo. echo Processing %%g echo Please Wait . . . %%g /q:a /r:n) Edit : Added WinXP-SP2 version of batchfile, as i linked this post to a WinXP user.

Thanks for your reply, Kelsenellenelvian Yeah, i know about the recovery console feature, and although it's a nice feature for many, then i would personally just rather re-image my system partition back to a working state with a recovery disc. I'm only deleting folders that i know for sure that i'm not going to miss... I'm using an answer file when running HFSLIP, so that the process is unattended(with a couple of 'PAUSE' and 'SET /P' commands deleted ) and at the end an ISO is made, so that's why i would much preffer to not delete the folders afterwards(and if i'm deleting them afterwards anyway, then shouldn't it then not be okay to do it beforehand also ?)

Thank you very much Kelsenellenelvian Much appreciated mate

I'm just having the following in my SOURCE folder : I386\ CDROM_IP.5 CDROM_NT.5 CDROMSP4.TST And then i have deleted the following folders from I386 : WIN9XMIG\ WIN9XUPG\ WINNTUPG\ LANG\ Now i then just wanted to make sure if this is allright when using HFSLIP ? I mean, if an update contains updated files for the 'I386\LANG\' folder, then i will not get them, but however, i'm deleting the LANG folder in the first place because i don't care about that folder anyway... So, if one of you guys would please tell me if it's okay for me to have those folders deleted when using HFSLIP(and when not caring about them), then i would really appreciate it. I just wanted to be absolutely sure about this... Thank's in advance.

I would really appreciate if i could please get a reply to this, thank's

You say that you've placed all your updates in the svcpack folder and that they don't install, but i can see that you have only referenced 3 updates to be installed in svcpack.inf and that the majority of your updates isn't installed from svcpack.inf, but has been directly integrated(slipstreamed) into your source distribution. Or is it just those three updates that you cannot get installed ? Btw, the GDR branch is always used if no prior hotfix has been installed for the files in question, so unless that's the case, then the '/b:sp2gdr' parameter is redundant on the following : kb933360.exe /q /n /z /o /b:sp2gdr Many people preffer to force the use of the QFE branch over the default GDR branch, since the QFE branch in addition to the GDR branch fix also includes all extra fixes from previously released hotfixes for the files in question. kb933360.exe /q /n /z /o /b:sp2qfe

Please read the MSFN unattended guide's hotfix section to learn how this can be done : http://unattended.msfn.org/unattended.xp/view/web/26/ Personally, then i would recommend HFSLIP instead, though...

Make a folder named 'setup' in the root and place everything you wan't installed into it. Download hidcon.exe and place it in 'setup'(2kb tool to hide the command-prompt). Make a batchfile in 'setup' named 'setup.cmd' : setlocal enableextensions set setup=%~d0\setup [...] endlocal Exchange '[...]' with whatever you wan't installed, like e.g. : regedit /s %setup%\hkey_user.reg start /wait %setup%\Some_Switchless_Installer.exe Add this line to '\$OEM$\cmdlines.txt' : [Commands] "..\setup\hidcon.exe ..\setup\setup.cmd"

Welcome to the forum, mate Please read the MSFN unattended guide and then come back here if you wan't clarification on something. http://unattended.msfn.org/ (Hint : The easiest route is to add your apps to e.g. '\$OEM$\$1\install\' and then call a batchfile from the 'GuiRunOnce' section of 'WINNT.SIF'.)

Like with every other user... Set the Administrator account to autologon and keep the logon-count as '0' i.e. unlimited.

@nuhi I'm curious about how nLite handles direct-integration of hotfixes, and so i would really appreciate if you would please answer two questions for me, then During direct-integration of hotfixes in nLite, then the reg-entries gets imported from nlite.inf at T-12, but how exactly are you capturing them ? I mean, are you on each new patch-tuesday then installing all the new hotfixes in a VM and then capture the added reg-entries and hardcode support for them into nLite, or do you manually retrieve the keys from the INF's of the hotfixes and then hardcode support fot them in nLite, or are nLite smart enough so that it parses the INF's for the 'addreg' sections of each hotfix automatically and then adds all the entries to nlite.inf ? HFSLIP for instance, strips the INF's out from all the hotfixes and adds them to I386 and then installs all of them from T-13 to get the correct reg-entries, but i don't see a bunch of INF's in the source of an nLite processed folder, so some other method is obviously being used here instead, then. Also, if nLite dosen't support direct-integration of a hotfix, then am i right in saying that it first tries to do '/integrate' on them(OK, using the '/integrate' switch is also "direct-integration", but as the *.exe's is still run and the hotfixed binaries is sitting uncabbed in I386, then i wouldn't call it a true direct-integration method), and then if that dosen't work, then it just manually places them in 'I386\SVCPACK\' and references them to be run at T-13 in svcpack.inf, right ? Thank's in advance.