Martin H

I just did some quick tests, and here you go... INF: [Version] Signature=$Windows NT$ [DefaultInstall] AddReg=addreg [addreg] HKCU,"Software\Microsoft\Multimedia\Sound Mapper","PreferredOnly",0x10001,1 REG: Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Multimedia\Sound Mapper] "PreferredOnly"=dword:00000001

To disable the prefetching feature of the newer Java versions('Java Quick Starter' service), then add this extra command-line to your NT command script: "%programfiles%\Java\jre6\bin\jqs.exe" -unregister

I've also not so long ago transitioned from Win2k to XP... I'm sure Win7 is a good OS, but i just don't like OS's with such a big footprint(backing up/restoring/defragging), so i also went with XP, which with all it's fluff disabled/removed, is an OS pretty similar to Win2k on the frontend, but still nonetheless, in the backend has several key kernel optimizations compared to Win2k(lower footprint, improved performance, optimized management of memory, registry and I/O subsystem etc.), and which supports all the newer apps and continues to recieve patches for several years to come... And as Siginet wisely adviced, defenetely go with a clean install!

What I personally pay much attention to, when selecting an imaging app, is if there's a command-line interface available, and if it's complete enough to provide support for fully unattended backup and restore operations... I've previously used Acronis True Image, but since it didn't had a command-line interface, and since there was big issues with the different versions(v8, v9 and v2009 worked for me, but not v10, and v2010), then i decided to change to the DOS version of Norton Ghost 2003, which is so small that it can be run from a boot-floppy, and is lightening fast and stable... (Note: I've read that Norton Ghost 2003 dosen't support NT6+) There are also some freeware apps with command-line interfaces also, but since the DOS versions don't generally support NTFS, and since the Win32 apps takes that extra time to get the job done, because of getting BartPE loaded first, then the DOS based Norton Ghost 2003 would allready have been finished backing up or restoring, and would allready be rebooted into the OS again, before those other apps would actually first begin to be starting their process... Maybe there's some linux based freeware alternatives with full command-line support, and which supports backing up only the used space on NTFS drives and not the full hdd capacity, but i've not encountered anyone yet... Just my 2 cents

Hi folks, and happy new year to nuhi and all nLite enthusiasts around the planet! Anyway, here's a bug-report to nuhi for just in case he ever returns to nLite development again(me crossing fingers!)... 1) I've read that you(nuhi) previously have added the capability of fixing the checksums of driver-binaries with borked pe-header-checksums, but i still got 26 checksum-related filecopy errors during install, when integrating the Intel 82GL40 Graphics controller driver: 'VGA_Intel_v6.14.10.5002_XPx86'. The files with bad checksums are of the type: '*.LR_' (uncabbed: '*.LRC'). If anyone else needs to integrate this driver, then i have uploaded a fixed version(7.95mb), with only the actual needed files referenced in the two needed INFs(one for graphics and one for HDMI), with the driver files pre-cabbed, so nLite dosen't need to spend time on doing that also: http://www.mediafire.com/?kgxtn2zxd4z 2) When integrating the Intel ICH9M/M-E SATA AHCI Controller textmode-driver: 'SATA_Intel_8.0.0.1039_XPx86_A', then during install there's a filecopy error about iastor.sys not being found. I then copied it manually into I386, reinstalled, and then the error went away... Thanks in advance. CU, Martin.

nLite uses the QFE branch where possible... Updates generally includes both a GDR and a QFE branch, whereas hotfixes only includes a QFE branch... When installing the updates on an installed system, then the GDR branch is used, and the QFE branch is only used if previously having a hotfix installed for the affected files. The difference between the two branches is that the QFE branch is cumulative and includes all the extra bugfixes from previously released hotfixes for the affected files, whereas the GDR branch doesn't, since those extra bugfixes hasen't been through enough regression testing yet, and also is only related to non-widespread and non-critical issues...

as -X- stated, then nLite won't overwrite newer files with older ones, so in general the order shouldn't matter... Also, as johnhc stated, then the msft provided slipsteaming method(the '/integrate' switch), which nLite reverts to on unsupported updates, also won't overwrite newer files with older ones... However, there can still be some issues where the order is relevant nonetheless(like IE upgrades and it's updates etc.)...

It's not related to accounts. It populates the 'Registered to' section seen when pressing Win+Pause... I myself prefer to use the default admin account as only/primary account. It's generally not recomended to do that, since then you won't have a backdoor into the OS if anything goes wrong, and also since you can mess things up if not knowing what you're doing, but as i frequently make backup images of my system partition and store all data on a second partition, then i don't see the point in making an extra "redundant" account... I'm not recomending to do that, but just explaining my motives behind it...

Yes, this is a nice way of slipstreaming drivers Just wanted to add that the INF edits can be automated with daddydave's Drivercab Helper tool found here: http://www.freewebs.com/daddydave/drivercabhelper.htm Also, keep in mind that when editing an INF, then WHQL driver signing is lost. This dosen't neccesarilly mean a problem, but will however influence the rank that setup assigns the OEM added drivers, when selecting between msft provided drivers and oem added ones...

A quick glance just reveals one error in : ECHO Iconising Taskbar START "" /B /WAIT "%systemdrive%\install\Install.reg" /Y You need 'regedit /s' to merge a regfile silently... Other than that, then for nitpicking: '/y' parameter is redundant in the 'copy' command when run from a NT command script. '/i' parameter is redundant in your 'regsvr32' commands. .cmd is more appropriate than .bat on NT systems. 'rd' is the same as the older 'rmdir'. lastly, maybe i'm wrong here, and just ignore this, but in my personal experience, then 'start "" /wait' dosen't make a difference, as the NT command interpreter by default waits for completion, and in cases where it dosen't, then that command don't make a difference, since it's because a program runs another process...

If using the msi installer, then add parameter: INSTALLDIR=<path>

The /integrate method actually also slipstreams the binaries, and isn't the same as the regular old svcpack.inf method... The installers are run at T-13 just for the reg-entries, cat files and possible post-install commands, and not for replacing files... Bloated/ineffecient - yes, but still slipstreaming however

Agreed(nLite allready does that btw), but there's also another issue... Quote from a post of mine: "On WinXP, then the 'Found new hardware' wizard will still be shown even though there are a driver available if the driver is either unsigned, or is only a compatible ID match and not a direct hardware ID match, so the wizard is shown for prompting if the end-user has a better driver available than this..."

When installing through winnt(32).exe, then the parameter: '/tempdrive:DriveLetter', specifies on which partition the temp files are placed AND where the OS is installed to... Yes, $OEM$ folders are supported through winnt(32).exe also, but must be placed under \I386. In your example in your first post, where you have a root folder named 'Unattended' with apps and a NT command script which installs them, then you e.g. add this line to ' \I386\$OEM$\cmdlines.txt': "..\..\Unattended\RunOnceEx.cmd" And then in RunOnceEx.cmd, then the path to all the apps to install is '%~dp0'. (=the Unattended folder...) If you want to have the 'Unattended' folder copied to '%systemdrive%', then it should be placed into '\I386\$OEM$\$1', and then cmdlines.txt + RunOnceEx.cmd needs changing to... You cannot use nLite's 'RunOnce' function to install something at T-13. For that you need to make an addon, or edit '\I386\SVCPACK.INF' directly, to run a CMD/INF. Or for T-12, run a CMD/INF from cmdlines.txt... I just use nLite's 'RunOnce' funtion, and adds this line to it: @rundll32 advpack.dll,LaunchINFSection D:\Unattended\install.inf,,1 And then the INF installs my apps from my 2'nd partition directly at first logon, without any pre-filecopying...

On WinXP, then the 'Found new hardware' wizard will still be shown even though there are a driver available if the driver is either unsigned, or is only a compatible ID match and not a direct hardware ID match, so the wizard is shown for prompting if the end-user has a better driver available than this...

I myself also install Windows from HDD(via a unattended BartPE bootCD, which formats my C partition in advance before starting winnt32.exe from hdd). Yes, DOS don't permit long filenames, but besides winnt.exe, there's also winnt32.exe which is the 32bit Windows version of the DOS based winnt.exe... The file-copy error you get is a nLite error, and you can fix it by deleting or commenting-out 'lhmstsc.mui' from dosnet.inf; as a workaround for the future, then add that file-name to nLite's "delete-files" section(under 'Advanced' in 'Components'), then nLite will correctly remove that entry from dosnet.inf.

Just in case nuhi ever returns to nLite development again, then here's a bug-report for v1.4.9.1: When removing terminal services, then 'lhmstsc.mui' isn't deleted from dosnet.inf, and hence, there's a file-copy error when installing through a BartPE/winnt32 based install-source. Workaround for others: Instead of editing dosnet.inf manually afterwards, then Add 'lhmstsc.mui' to nLite's removal file-list, which then deletes the entry from dosnet.inf... When using nLite in unattended mode from a NT command script, and when nLite has just been installed(with lite framework) and never has been run, then nLite stops alittle after the gui shows, and so i have to call nLite twice in the NT command script i.e. : "%programfiles%\nLite\nLite" /preset:"%%presets%%\Last Session.ini" /path:"D:\Temp\GRTMPVOL_EN" "%programfiles%\nLite\nLite" /preset:"%%presets%%\Last Session.ini" /path:"D:\Temp\GRTMPVOL_EN" Note: This is just on a completely fresh nLite install i.e. nLite may newer have been run before to reproduce this ! Lastly, then when disabling the 'component dependency messages', then 'DisableDepCheck' is written into the preset file, but when loading that preset into nLite the next time, then the 'DisableDepCheck' entry is ignored and isn't written into the new 'last session.ini' preset, and so 'component dependency messages' is enabled. Thanks in advance...

I would recommend that you check out hfslip or nLite for the task of directly integrating updates into your install-source... If you're not gonna use the extra nifty features of nLite, like component-removal and driver-integration, then hfslip would be your best bet IMHO, as it supports more updates for direct integration than nLite does...

When having direct integration enabled in nLite and when the updates is supported for direct integration by both nLite and HFSLIP, then they both replace outdated binaries in the source and updates txtsetup.sif/dosnet.inf accordingly if new binaries are added and so then, the most notable difference, is that nLite parses the updates INFs and copies the needed reg-entries into NLITE.INF which are run during install, but HFSLIP instead makes a new DefaultInstall heading on each of the updates INFs and copies them to I386 and defines them all to run during install.

Installing updates from svcpack.inf is IMHO an old and inefficient method of integrating the updates, as it will add extra overhead into the equation in terms of increasing the size of your install-source and adding to the total installation-time. Instead, I would suggest using nLite to integrate the updates directly, or using an update-pack instead, as it's a much more efficient method. nLite can then also be used as a convenient base platform for e.g. directly integrating custom drivers, defining unattended settings, tweaks and patches, enabling/disabling services and if wanted, removing unwanted components etc. etc. The nLite process can be run completely unattended through command-line switches(after having run it once manually to make a preset file), and there's a lite .NET framework available, which installs into the nLite program-folder, so that the full .NET package isn't even needed either. As a second best method IMHO, would be to use the updates own /integrate switch, which also will directly integrate the updated binaries into the install-source, but will then also need to run the updates at T-13 from svcpack.inf, just to get the needed reg-entries added and run any possible post-install commands(e.g. registering dll's etc). And then as the very last method of integrating the updates is IMHO, the standard svcpack.inf method... Just my 2 cents...

Besides MPC-HC, then there's the Guliverkli2 project by clsid, and that is where those newer MPC builds comes from which isn't labeled MPC-HC... Guliverkli2: http://sourceforge.net/projects/guliverkli2/ Doom9 thread: http://forum.doom9.org/showthread.php?t=128616 The project is meant for ppl which is content with the original MPC and just want's the newer library/security fixes. Personally though, i would use MPC-HC

I don't fully understand what you're refering to... However, if you want to integrate apps into your install-source to install at T-13, then you can make 7z or rar silent switchless installers and add them to the svcpack folder and reference them to install at T-13 through svcpack.inf. You cannot cab the installers as they won't run then. The nLite/RVM addons which ussually are cabbed, are uncabbed by nLite during the integration process...

hfnetchk works fine on a FDV'ed/hfcleanup'ed install and dosen't show any missing updates for removed components. The bad thing is that it dosen't support specific components, like e.g. dx, oe and newer versions of specific components...

I love ImgBurn, since it in addition to being freeware and leightweigh, then also has so many great options like e.g. auto-changing the filesystem based on which type of disc your writing, auto-seting the write-speed per MID or disc/drive-type, accurate layer-break placement, on-the-fly audio decoding/writing, advanced options for configuring practically everything to anything! etc. etc.

The 'RunOnce' tab of nLite is meant as a convenient way of adding NT commands to run at first-logon. nLite exposes a pre-defined variable named '%source%', which represents the root of your install-source. You can e.g. make a folder in the root of your install-source named SOFTWARE, and then place all your apps in there in subfolders, and then either add NT commands to install them all silently, one line at a time, in nLite's 'RunOnce' tab, or you could just make a NT command script or INF, which installs all the apps, and then place it into the SOFTWARE folder, and then call that NT command script from nLite's 'RunOnce' tab, like e.g. '%source%SOFTWARE\install.cmd'. Each command-line added, will by nLite be added to a NT command script named nLite.cmd, which is placed in '%systemroot%\system32' and defined to run at first-logon in winnt.sif's 'GuiRunOnce' section. Edit: About how to install your specific apps, then i will leave it up to yourself to do some searching on that, as there for the most apps are plenty of info on that both here at MSFN and otherplaces which can easilly be searched/googled...