Scrapple

There are many ways, but I think the best and very modern way is to: 1) Unattended ----------------- from a Distribution share (with OS, tweaks, apps and drivers) is great for its modularization. I use it to install my master pc (a virtual machine). Sysprep is the last action before I capture the image. 2) Imaging -------------- Capture the image with Vista's WAIK ImageX from a BartPE-CD (ISO file that is also build from the Distribution Share)) to an Image folder on the Distribution share. 3) Deploy ------------ WIM-image to ANY machine (laptop, desktop...) by using ImageX from (PXE/CD/USB) using the same BartPE iso. I then run a tool that detects the HAL, massstorage, pnp drivers, and inject them+sysprep modifications into the image that has just been deployed but before you boot from it. 4) Boot ---------- the machine, it runs Setupcopyoeminf on the injected pnp drivers folder and then start mini-setup. Install extra apps from WPI or Group-policy. 5) Image Management --------------------------- I have 3 ways to alter the universal image: * Run the pre-sysprepped master PC (virtual machine with undo disk option) install updates... and sysprep/recapture * Rebuild master from modified unattended scripts and sysprep/recapture * Use WAIK's WIM-filter to mount the WIM image, throw in some files/scrips, commit/unmount it.

No, it doesn't. Binary Research's UIU cannot post-inject mass-storage drivers. They're installed on the master BEFORE the image is (re)captured. Just like sysprep does with a modified [sysprepMassStorage] section. But Acronis Universal Restore and Symantec's Livestate Recovery (incl. Restore Anywhere) CAN post-inject mass-store drivers. So do BartPE's plugin FixIDE, DDChanger, Platespin tools, WinOPK's MSDInst.exe, and just about any other Physical to Virtual tool (P2V), albeit specific virtual drivers. Injecting the right (mass-storage) drivers and HAL AFTER laying down an image but BEFORE you boot from it is the best way. I've studied this extensively and it ain't rocket science to make it yourselves by using BTS's driverpacks and merging of the following tools: Utility Spotlight: Automate Device Driver Integration PEcd.net FixIDE tool Check "Detect the HAL script from PE" in this article

Thanx, very nice of you to integrate setupcopyoeminf!

Ok man, no problemo, just solve your current problems and build things from there. About the devcon output... I don't know about that, but I think the devcon sourcecode is included in the DDK or the Platform SDK... so maybe this could help you...? I do have one question for you: How do you set non-WHQL to ignore from AutoIt? In batch I tried: reg add "HKCU\SOFTWARE\Microsoft\Driver Signing" /v Policy /d 0 /f reg add "HKLM\SOFTWARE\Microsoft\Driver Signing" /v Policy /d 00 /f reg add "HKLM\SOFTWARE\Microsoft\Non-Driver Signing" /v Policy /d 00 /f But that didn't work... auto-clicking it to "Ignore" from the XP-GUI "driver signing options" from within autoit is an option, but I'd like to know the "under the skin" way... :-)

Well, I'm not the suspicious kind, but I do hate reinventing the wheel because I'd like to adapt some of your prog to work in conjunction with seupcopyoeminf.exe. So what I mean by that, is doing a scan of all present hardware devices and integrating only the needed drivers. That way you won't need a devicepath setting, which is linked to 4096 chars. Another thing is the skinning/GUI. (less importance) I don't really care about having credit for any program, so I'd gladly give my extra source back to you to perhaps use the new ideas.

This seems handy! But I would appreciate the source-code... Written in AutoIT, isn't it? Thanx!

Just take a look at the UBCD4Win project... They have 2 driverpacks/methods: A - contains NICs/MassStorage B - use BTS packs with UBCD4Win You probably want A, unless you really know what you're doing...

....???? Wasn't nLite meant to make a original XP cd "smaller" or adapt (i.e. integrate stuff, remove components, etc....) I'm not sure, but I don't think it will work on an already installed system, which you actually seem to try. BTW 1.16 -> 1.19GB is 30 MB, not 300MB.

I think you can just download all driverpacks, extract them (i.e. C:\D)and run setupcopyoeminf.exe with that folder as input. That way every driver should be integrated in your existing XP install.

Glad you solved it. The "-pnp" switch is only necessary when you want to detect non-pnp (legacy) hardware. I don't know why this switch stopped the driver loading for key/mouse... If anyone have any idea why that happens, please tell.

Do not use sysprep -clean before resealing. What that does is remove all -non present hardware- drivers from the critical driver section in the registry, so they won't load on boot. You should only do a -clean in runonce when the image is already deployed. Besides that, I think I know what your problem is. I've had this problem before myself when I built my master-image in VirtualPC. It worked fine on a normal pc when I didn't include the virtual pc additions, but when I installed them in the virtual pc I wouldn't have working keyb/mouse on the deployed machine. I don't know VMWare, but I suspect it has some kind of additional feature -like the additions in VPC- which will install it's own virtual keyboard/mouse drivers/service, but for which there is no hardware-emulator present on the real deployed pc! So it's probably not the case that your input-drivers are not present in the image, but there's actually a virtual mouse/key driver loaded that wants to handle it. There's a driver/service too much!!! The likely solution is to NOT-install or just remove the additional easy-input functionality at all in the virtual machine, before you sysprep and clone it. That way the virtual input driver is not present and not loaded in the deploy pc. Let us know if it worked.

3 ways of doing this: 1) the driver for the mouse and keyboard pc is probably not in the image, so you should include them and set their paths in oempnpdriverspath (sysprep.inf) before sysprepping... (use the boards' search-function if you don't know how to do this) 2) you could also install the drivers before sysprepping with setupcopyoeminf.exe. That way makes sure windows driver-database knows about them. 3) If you want to have the drivers working really early in the boot-up process, you should make the settings under the [sysprepMassStorage] section. Yes, this will work with other drivers than massstorage too! (just like when you would add a mass-storage driver manually in sysprep)

"sysprep -bsdm" does NOT increase your image size substantially. It only finds mass storage drivers that are already in windows driver database and adds some references in the criticaldevices en services section of the registry so that the deployed computer is able boot. Since it will load many drivers at startup (for which most hardware is unavailable) it will make the boot-process slower than it has to be. That's why it's recommended to use "sysprep -clean" as a command in cmdlines.txt, so next boots will be faster. (this will clean the registry from all unused driver references) To find out your pnpid use devcon.exe or pnpids.exe. BUT, when you remove all drivers except the "520" you will need to create yet another image when some other type of pc (which may needs other driver) comes in. I would advice to make an image as generic as possible and NOT remove all those lines from sysprep.inf!!! The 2 major things that need to be correct for the deployed machine to boot after sysprep are: -compatible HAL -correctly loaded mass-storage driver for drive that contains the system partition. So, for a pretty generic/universal/hardware independent image you would use: - "Advanced Configuration and Power Interface HAL" (all acpi enabled machines are compatible with this HAL) switch later to UP or MP if detected by a script - mass-storage sections in sysprep.inf for as many mss-drivers as possible (-bmsd) - add BTS drvpacks and use SetupCopyOEMinf on the master-pc before sysprepping/cloning it. (this is for most other devices) This process is the "simple" version, it can be highly finetuned to make it even better.

I'm surprised how few people actually use sysprep's "factory-mode" Do a: sysprep -factory, shutdown and clone the partition/disk. Deploy that image to a machine and boot it (=factory mode) and allows you to run scripts that modify sections in a sysprep.inf or selects a file from a list of sysprep.inf-templates and renames it to C:\sysprep\sysprep.inf' (all these files can come from a network share, if you did integrate the network drivers!) The scripts that alter or choose the correct sysprep can be run automatically if you put them into winbom.ini or normal startup or runonce-reg entry and even manually!) After that, click sysprep reseal button (sysprep dialog starts automatically in factory mode) OR put resealmode=reseal section in winbom.ini to run it silently without user intervention) Then the deploy pc will reboot and use YOUR pre-filled/auto-selected sysprep.inf in it's mini-setup. IMO sysprep's factory mode is it's most powerful feature... it can install stuff like hotfixes, updated apps and ever changing scripts, including sysprep.inf...etc... from a network-enabled state. Besides that, it also does pnpdriver-installing silently. So it's all done BEFORE reseal but AFTER image-deployment. You can even use it to detect and put in the correct HAL update. Ever heard of a "Universal Image" :-) This way Sysprep-imaging (with a couple of scripts and cmdline tools) AND the BTS-driverpacks are an extremely versatile and fast deploy mechanism. Now, if you add Vista's great ximage, drvload and the wimfltr-driver to that... it's a deployers heaven. It's the way almost anyone will deploy Windows systems in a couple of years. Garanteed. There are people that are already using it today to deploy XP. :-)

hmmm, i have searched but i couldn find free version, maybe someone knows the link for free version? <{POST_SNAPBACK}> InCtrl5

Hi, could you explain to me how you do your correct HAL detection and installation on different hardware by using 1 universal image? There are several ways to do it, but I'm interested in new ways. What exactly do you mean by HAL filtering? Does it mean the RIS server checks if the pc it is about to deploy an image to, is adequate enough to even put the image on? Then it must know what HAL is in the image in the first place... and look for compatibility differences, I presume? Please explain... I'm confused... ... there is a tool called ta.exe (included with windows xp embedded) that will check what HAL the pc can optimally run... maybe somehow it's code is incorperated in RIS HAL-filter???

"InCtrl5" is another one...

Well, because I'm not using unattended (scripting) method, but the sysprep (imaging) method. The company I work for has very heterogeneous hardware, but the unattended installation method is just too slow... So what I'm trying to think of is a way NOT to re-image every single time I run into a (new) machine for which a massstorage driver is not yet incorporated in the image. As you know, massstorage drivers need to be present for the machine to even boot. So my goal is to update the drivers(packs) on a network-share regularly and to have a regularly updated BartPE CD (with the latest masstorage/nic drivers) boot the machine and download/restore the universal image from a mounted image/drivers/scripts network-share to the harddisk after partitioning it. Then mount that local partition and detect all hwids of every piece of hardware that's actually in the machine. After that search for only the needed drivers and custom scripts on the netshare and incorporate them into that still unbooted hdd partition. Incorporating the massstorage drivers into the deployed partition before Windows' boots from it, seems to be the most difficult task, but I think it's possible to script copying driver-file's to and editing the registry of the hdd-partition from within a running BartPE (pxe or CD). Now, that's why my original question was: What exactly do I put/change in the registry and where do I put the driver files of the massstorage driver in the deployed hdd NTFS filesystem BEFORE windows is able to boot from it? ..... Running "sysprep -reseal", AFTER "sysprep -bmsd", does exactly what I need (I think), but I need to know WHAT sysprep actually does to the registry and what filecopying sysprep performs on its NTFS boot-partition for windows to be able to boot from it after deployment (on a different machine which possibly needs the newest scsi/raid/sata driver), because I CAN'T run sysprep again BETWEEN capturing and deploying; BartPE is evidently loaded at that time (and not the deployed os on hdd I'm trying to target for doing this on) ..... I know it all sounds pretty complicated, but I hope you get my idea. Let me know what you think how this can be done... preferably: "a better/easier way"... Remember: regular re-imaging and/or unattended installs are NO OPTIONS for us

Hi, here's some additional code... Hope this explains it better. :-) --------runprep.cmd------- rem Run sysprep, but no reboot!!! start /wait c:\sysprep\sysprep.exe -mini -reseal -quiet -noreboot rem Save sysprep's boot-setup reg-entry (for later import from sethal.cmd)... reg export HKLM\system\setup c:\sysprep\sysprep.reg rem ...and change it, so my detection and hal-swap runs first. REG ADD HKLM\SYSTEM\Setup /v CmdLine /t REG_MULTI_SZ /d "%SystemDrive%\sysprep\sethal.cmd" /f rem Shutdown and ghost the partition/disk. shutdown ------------------------------ BTW, ta.exe comes with "Windows xp-embedded"=XPE.

This should be possible with ta.exe that's included as a dos command tool with windows xp embedded. When you run it, it will create a report file (devices.pmq) with the HAL-type that SHOULD actually be installed (which is not necessarily the one that IS installed) Here's a code snippet that should be run (instead of setup.exe) at first boot of the deployed pc. As you may understand that reg setting was saved (sysprep.reg) and changed just after "sysprep -mini -quiet -reseal -noreboot" and before you shut the master-pc down. --------------sethal.cmd------------------- ta.exe find "ACPIPIC_UP" devices.pmq && SET ACPI=ACPIPIC_UP find "ACPIAPIC_UP" devices.pmq && SET ACPI=ACPIAPIC_UP find "ACPIAPIC_MP" devices.pmq && SET ACPI=ACPIAPIC_MP find "MPS_UP" devices.pmq && SET ACPI=MPS_UP find "MPS_MP" devices.pmq && SET ACPI=MPS_MP find "E_ISA_UP" devices.pmq && SET ACPI=E_ISA_UP find "SYSPRO_MP" devices.pmq && SET ACPI=SYSPRO_MP_UP rundll32.exe setupapi,InstallHinfSection %ACPI%_HAL 131 %windir%\inf\hal.inf reg delete HKLM\SYSTEM\ControlSet001\Enum\Root\ACPI_HAL\0000 /f reg delete HKLM\SYSTEM\ControlSet001\Enum\Root\PCI_HAL\0000 /f reg import c:\sysprep\sysprep.reg exit ---------------sethal.cmd---------------------------- O, I forgot; Your HAL should be set to "Standard HAL" on the master-pc beforehand. -This should pretty much work on ANY pc/laptop that can run XP -Remember: This is NOT supported by M$.

@HTC In the first page of this thread you say: By the way, I have a idea to auto-install all the neccessary drivers "unattended" on target PC after first start(not restart). If someone know it either, post here... ------------------ 1) Could you tell me how you would do that? 2) Where did you get the info of putting stuff directly into the registry?: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase and [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Is that what sysprep -reseal really does in those 15 muinutes when I run sysprep -bmsd beforehand? 3) Does your method actually work with sata/scsi/raid drives?

Hi, First of all: This forum is great! Lots of "guru's" here! Thanx very much for this SetupCopyOEMInf method!!! @Pyron/Shalti Could you put the scripts back online and possibly the sourcecode for the .exe? I want to study how this is put together, instead of just running it. Maybe I should've made a new thread for the following questions...? I don't know for sure... Questions: ---------------- It's a pity that this method doesn't work for massstorage drivers; as I understand these are a special kind. But could anyone explain me where the massstorage drivers are actually put on disk and what registry settings are made...? So what I'm trying to grasp is how windows finds these ide/sata/raid/scsi drivers... I know a lot of people here ain't fond of/don't use sysprep, which I understand, but it has a nice functionality called the buildmassstorage section, which is prepopulated with the -bmsd switch... and when the reseal is working, it takes a long time (somehow because of the large massstorage section) Can you guys explain to me in detail what is done at that time? Or give me some link(s). I've searched so long for these answers, but I can't find it anywhere... :-( Thanx a lot! P.S. one more question: would it be possible to somehow check, before pnp enumeration, what hardware is actually in the machine? For example by running a tool that lists all hwid's and then finds the drivers for those hwid's recursively within a BTS-drvpack-folders residing on a cd/hdd/network and "SetupCopyOEMInf-ing" only those drivers? Anyone? Thanx again!