This is a topic split from another thread. In that thread, nivlacckw brought up a novel idea to adapt a physical to virtual (P2V) process to alter the HAL and add mass storage drivers to a system after an image has been laid down, but before mini-setup runs. The page he referenced is the Ultimate-P2V (http://www.rtfm-ed.co.uk/?page_id=174).

On the site, there is a reference to Notorious_bdg’s “HAL_Update” script (http://www.rtfm-ed.co.uk/downloads/HAL_Update.txt) which seems to detect and change the HAL using devcon. This only appears to be written for 4 HAL's but either the script could be completed to cover all of them or, depending on the licensing, the devcon source could be altered to create a utility that provides only this very defined function. Maybe it could also include a function to detect the mass storage controller and pull from a predefined driver folder to inject the correct drivers as well as updating the HAL?

He's making a similar inquiry on the BartPE forums.

So I just wanted to see if anyone can see problems with this process or does it seem to be a valid use of devcon? If you boot from a PE CD and make these types of changes will there be any problems when you boot?

This method is definately the best way to universal imaging as far as I can see.

How nice it is to: Just deploy any XP image (sysprepped or not, drivers or not) to any (virtual/real) machine and change some files/registry on the harddisk with a universal tool before you boot from it.

BTW, there are already 2 commercial tools doing this:
-Symantec Restore Anywhere
-Acronis Universal Restore

Their disadvantage is that they only handle massstorage and HAL, but don't handle pnpdrivers and they're add-ons to the company's own image-product. (Ghost, True Image)


BUT: You can also write such a tool yourself. It's not rocket science...


detect the HAL from the following key in BartPE:
HKLM\SYSTEM\CurrentControlSet\Enum\Root\ACPI_HAL\0000\HardwareID and if that does not exist
HKLM\SYSTEM\CurrentControlSet\Enum\Root\PCI_HAL\0000\HardwareID

If the HAL in the offline image is different from the one detected, then extract the right latest HAL + kernel on the offline image (usually SP2.CAB) and rename them to their proper names in C:\Windows\system32

load the C:\Windows\system32\config\system to a temp hive

empty the "Enum" branch in the loaded hive so it will be filled properly at boot.

detect the Processor vendor from BartPE with:
HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\VendorIdentifier
... if AMD then change the Startvalue of the intelppm service to 4 in the loaded hive, otherwise most AMD's will bluescreen.

So... that's pretty much the HAL detection/changing routine

That HAL script you mention in your link does not work when run from BartPE/WinPE, because it does't handle the registry in the offline image... it's also not always right on the HAL to be installed.



Now for the Mass Storage drivers it's more difficult. But basically comes down to: Detect the PNP-ID of the boot-device, find the correct .inf file on a driver distribution share mounted from BartPE and install the .sys, .cat files in the offline image. AND very important to import the proper entries in the CiriticalDeviceDatabase and Services section of the loaded hive so the pc will not get a bluescreen (7B error). To do this is too much to explain here in detail.


PNP-drivers is easy: detect the PNP-IDS of the hardware (also within BartPE) and find their corresponding .inf files (and .dll, .cat, .sys...etc...) in the extracted BTS driverpacks on a distribution share and throw them in the offile image in a folder i.e. C:\drivers.

If mini-setup or OOBE is set to run because sysprep was the last action taken before capturing the image (See certain: HKLM\System\Setup values) then,
Save the HKLM\System\Setup\Cmdline string value of the to i.e. C:\setup.cmd.
Change the value to "C:\mysetup.cmd"
copy over setupcopyoeminf.exe to C:\
Copy over/or create the C:\mysetup.cmd with the following lines:

C:\setupcopyoeminf C:\drivers
call C:\setup.cmd
del C:\*setup.cmd
del C:\setupcopyoeminf.exe

If sysprep was not used, then mysetup.cmd should be set to run from a runonce entry where also devcon.exe is being injected and a "devcon rescan" is being run from within mysetup.cmd


So...I'm probably forgetting some stuff, but that's basically it. A universal XP (image) changer. Let's make this a BartPE plugin called: "SysWrap" :-)

But hey, besides the obvious sys-admins/deployers, it could also be used for people changing motherboards/computer and wanting to keep their installation, and what about P2V, V2P, P2P, V2V.

For an imaging product I definately would use Vista's WAIK "ImageX" or script it's API "WIMGAPI.DLL"

Some more external reference of this concept from Microsoft

http://download.microsoft.com/documents/uk...eploying_XP.ppt

actually there is a third comercial program that does this, the UIU (Universal Imaging Utility) from Binary Research the original makers of Ghost. It handles HAL, massstorage and includes a drivers database.

Is this different between BartPE and WinPE? In BartPE the ACPU Uniprocessor comes up as
HKLM\SYSTEM\CurrentControlSet\Enum\ACPI_HAL\PNP0C08\0\HardwareID

I don't currently have access to my WinPE install, it's in my other office.

This UIU tool is too "old-fashioned" and too expensive... you have to run their tool (that runs sysprep) and after that recapture everytime a new driver is needed. Your image file swells due to their driverpack (which is also pretty limited compared to the BTS packs). It does not support RAID. You have to make two images if some of your computers are not ACPI capable. I've pretty much reverse engineered their method and it's not that difficult to make either.

The beauty of the "new method" that is describe above, is that:

- it's possible to use ANY (old) XP image you (once) captured
- do not depend upon sysprep to be run beforehand
- it can inject only the needed drivers, you don't have to put them in the image
- you can also update your boot/pnp-drivers without recapturing on a net-share
- can update HAL/kernel for ACPI <-> NON-ACPI (1 image is possible)
- it does not depend on a certain image product (granted: UIU isn't either)

You must have used thier last version not the new one, new one will do scsi, all HAL types, and at least for the machines I've done my testing on their driver database was more complete than BTS's.

Yes, is still uses sysprep, but for most of my images I do also.

If you want to edit the image make if fat32 and you can modify the image before deployment. At least to an extent, no you can't edit the registry.

I have not tried symantec restore anywhere, I'm hoping to get a copy soon to play with. I personally did not like acronis' method, but I also did not want to change imaging software either.

Not trying to argue. Just trying to get as much information out there for the poor souls who will stumble accross this thread. Finding some of this information has been a real pain in the but.

you looked under the wrong key... so don't forget the sub-branch "Root" in the key I mentioned:

HKLM\SYSTEM\CurrentControlSet\Enum\Root\ACPI_HAL\0000\HardwareID

or for non-acpi

HKLM\SYSTEM\CurrentControlSet\Enum\Root\PCI_HAL\0000\HardwareID

I think it is the same for WinPE, but it's definately ok in BartPE.

BTW I know another extremely novel way to detect the HAL... To let windows detect it itself on first boot... just like unattended does it in text-mode. If you guys are interested in this kind of stuff I'll share it with you.

I would like to see that. If you'd be so kind. Thanks.

of course we're not argueing. It's a highly interesting subject to me. So I'd like to exchange a lot of info to find the most perfect way to do imaging. And yeah, I definately agree that finding and learning all this stuff on the net is very time-consuming and goes pretty deep into the system sometimes.

I'm gonna look into the new version of UIU as soon as I have the time to research it. What version is it? The last version I looked into is that of june 06. I hope they have a better one now.

My driver-folder on the share is over a GB extracted and contains BTS driverpacks + extra diverpacks like HID, TV, modem, monitor etc... I'm very curious if the new UIU can top that...

About a Fat32 image... I know with ghost explorer i could edit that, but I'm using ImageX which isn't a sector based image, but file based, so it even allows you to keep the previous data and/or OS on the partition/disk after you deploy the new image. It also includes a filter, so you can mount and edit the image file (even script it!) It's kinda like a command line winrar.

Ok, here's how you do it:

Get the longhorn beta 1 "NTLDR" file and put it in the root of your xp image

add an option to the line in boot.ini, like:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect /detecthal

then create a file named dtecthal.inf in C:\windows\inf that consists of the following



extract all HALs to system32 and rename them to the filenames above.
extract all kernels to system32 folder


Basically what MS did is incorporate the HAL detection of the text-mode (unattended XP) in the NT loader of Longhorn. That was still the time in which they had the many kind of HALs we know from XP.

The vista Beta's do NOT use/need this method, because the bootloader is different and they have only 1 universal HAL file (which BTW can't be used in XP...)

Hope anyone finds this useful.

The version of UIU I was using that would do all of the HALs and SCSI was from March/April timeframe this year.

Sounds like they have gone backwards since my testing earlier this year. Sad if they have, the version I had worked very well for what we wanted to do.

I don't think that work will let me use ntldr from vista beta 1. And I suppose the detecthall switch is not in XP. So I guess I'll be stuck with the slightly more dificult methods.

What do you mean extract all kernels? I thought there was only one so could you be more specific?

And I take it the Longhorn Beta 2 that's out there now won't cut it, right?

This is really an interesting topic for me. I know there are several commercial solutions out there, but I can't see paying the money for something that can be done just as easily w/a script or utility. Plus, I'm always intrigued by finding out how it works under the hood.

is there someplace that all of the switches for setup.exe are, I'm referring to the one which is run on first boot after sysprep is run.

-newsetup
-mini

are the two I know of off the top of my head, are there others that might do things that would help this effort?

I'm currently working of this kind of solution:

1/ I'm starting with a RestoreCD Plus from HP and a 2nd CD which contains an OEM Windows XP Professional OS sysprep'ed in factory mode.

2/ I boot the 1st CD, let the restore process copy required files and then ask for the 2nd CD (OS) and restore it, reboot the computer a first time to let HP tool checks hardware and configuring drivers and applications and when computer reboot, boot from WinPE and backup the HDD with a cloning tool to a VMWare virtual machine.

3/ inside the virtual disk (.vmdk) which i can mount with Ken Kato VDK driver on my host computer as drive, i can do all the changes required (inject drivers, configuring sysprep.inf oobeinfo.ini and winbom.ini, make appropriate changes to registry hives).

4/ and then restoring the virtual machine disk to a physical computer.

Some limitations: my OS is OEM preactivated and i can't use the image on different brand of computers.
I have some problems with oobeinfo.ini to make the first boot fully unattended.

About UIU: You really give it too much credit. Granted, they do a fine job on most systems... possibly all pc's in your company, but they will NOT detect just any Hal (or have just any driver issue resolved for just any system, which I know you haven't stated)

If you read the documentation of UIU (even that of march/april) you can read under the topic troubleshooting that when you've captured an ACPI image and deploy it to an non-acpi system, it will crash on boot. So you would still need 2 images with UIU, like I said before. UIU is therefore not really "universal", which they like to claim.

Other things they admit they cannot do is:
- deploy to RAID
- capture from SCSI and deploy to IDE, Pata/Sata

They also have missing/incorrect mainboard drivers sometimes, which crashes the deploy pc. And driver bangs (missing drivers) for bleeding edge hardware is also an issue.


About the longhorn NTLDR: You could use it only once and swap back the XP one on second boot once the HAL is properly detected and installed. If even that is out of the question, then use the method of WinPE reg HAL detect/swapped described in my long post. If you're not allowed to HAL swap at work (because it DOES break MS support!), then be prepared to make and manage multiple images... and also throw the word "universal" out the window, because it is simply not applicable anymore.

indeed, the "/detecthal" switch only works on Longhorn beta 1 NTLDR. XP's NTLDR is unaware of it.



well, I mean kernels like: ntkrnlmp.exe, ntkrnlpa.exe, ntkrnlup.exe and ntkrpamp.exe

Yes, sadly Vista Beta 2 is of no use for us in this HAL swap thing.

Well factory and audit mode exist, of which factory can process winbom.ini (like winpe), but even if some secret setup.exe parameter existed... it wouldn't be of great use for switching hals, because XP has to be almost completely boot up, before it kicks setup.exe. If you had captured an image with a hal that was incompatible with the deployed system... it would've never even made it that far into the boot-process and would just reboot/blue screen before it could detect the HAL... and THAT is exactly why UIU has a big limitation and detecting/swapping the HAL with WinPE/BartPE is the way to go.

BTW, msoobe.exe is usually the program that's run with the cmdline reg-entry on a new system... most OEMs use it to enter the WinOOBE mode many of you are familiar with.

As far as the UIU, I built my test image on an ACPI system and deployed it to the Standard HAL, ACPI uni/multiprocessor HAL, ACPI without any problems. These machines ranged from a Dell GXA to the current Lenovo M52 desktop, there were a few drivers missing on the newest machines but all it took was a phone call and a days wait and they gave me an update to their driver pack.

The driver issue I've had with BTS's packs also so it's not a complete solution for drivers either.

I did not try going from SCSI to PATA/SATA but I did go the other way without issue.

The only driver issue they could not solve was for the TPM on the thinkpad systems which was not properly signed by the manufacturer.

I don't think that HAL swapping would be an issue but using beta compinents usually is.

I knew about the various HAL's being used to create hal.dll, but I never thought they did the same thing for the kernel. Are there any references, that you know of off the top of your head, for which one is used in a particular instance?

So we'd have to include placing the correct kernel as well as the HAL? Doesn't seem like a major deal, unless there are other supporting files that follow the same concept. Thanks for the tip.

I think the premise of making this switch via a script, or coded utility, is possible. Granted MS won't touch it, but I never bother with that avenue anyway cause it usually takes way too long to get a resolution. I think I have enough to get started, now I just need to find the bandwidth.

Sure, it's possible to check the "Install Standard HAL" checkbox in UIU before you capture the image. It will install perfectly on most any system, but with very limited Advanced Power Capabilities on ACPI machines afterwards and lower performance for Hyperthreading machines.

But... I have the feeling you're gonna tell me you deployed a real ACPI image to a non-acpi machine and suffer no APC disadvantages. :-) If you succeeded in doing that... that's really "wonderful?" and pretty rare scenario... but it's really not something UIU anticipated on or even supports, let alone MS. Because HAL/Kernel wise it would be the most undesirable situation you could boot a pc under... HAL-wise, that is. It will drastically affect the way some drivers communicate with the hardware. I would be very surprised if it would even run stable.

I very much agree on the BTS packs... they are not the be-all-end-all solution. It needs updating and sometimes tuning too... but you can do it yourself...offline... so you don't need to include/update them IN the image, which is a big plus.

Yes, PATA->SCSI works flawless with UIU. They state/support that. I wouldn't expect any different.

About the thinkpad:Exotic unsigned drivers (usually laptops) will always be a pain in the a**... I've had my experiences...:-)

I wouldn't use the longhorn NTLDR in a heavy production environment too... but it works and is a pretty novell way of doing HAL detection/installation, so that's why I shared it with you deploy geeks... :-)

How much do you pay for the UIU license per seat if I may ask? I thought it was something like $19 dollars or $10 bucks high-bulk. For some that is cheap... other might find it very expensive... the same goes for Acronis and Symatec's solutions.

A tip: You could also write a tool like UIU yourself... check ta.exe (from XP Embedded) for hal detection and rundll32 or devcon for hal installation. And sysprep with -noreboot switch to change the HKLM\system\setup\cmdline reg-entry to your own hal-routine after sysprep has run.

Check your C:\windows\inf\hal.inf file for which is which and what names they should get to "activate" them... :-)

Good luck with scripting it and keep us posted. I might be able to advise you, even though I'm not a coder.

If you can code really well you shoud also check wimgapi.dll of the new BDD2007 WAIK... the help file is included for those function calls... so you could write your own imagex.exe or GUI it with a nice progress bar like Vista's setup.exe on the DVD does.

Thanks for the ref, I'll check it out. I haven't had time to even install the Vista beta yet so it may be relased by the time I get around to it. I understand they're using a different method for unattended installs. So much to do, so little time.....

Actaully I did not run into any problems in testing but that doesn't mean they would not have come up. And I wasn't really concerned about going all the way back to the standard HAL. I mean who in their right mind would really want to run XP on a PII 300mhz machine in the first place.

From the reports I've collected it looks like 70% of the machines we are concerne about are ACPI Uni/mutiprocessor, another 20% are ACPI. The remaining 10% are standard and personally I'm not really concerned about them, but I'm still trying to convince my managers and directors of that.

We have not yet purchased the UIU but the quote we had was around $10 a machine. Cheap when you consider what we are paying to build a machine from scratch or maintain over 30 images across our organization. We won't ever get down to 1 image, but we could get it down to 10 images instead of 30. Some of our images contain over 12gb of software, others are just the os and updates, but most exist because of differing hardware.

And until recently when I changed jobs I did not have time to pursue this endeavor and no one else even considered it. After seeing what the UIU could do and what Acronis can do I began pursuing it further. And actually at the time this post was started I began working on an application to run at first bootup after sysprep to replace the HAL, right now it's mostly pieces and testing but it's getting there.

As I'm really writing it for work I will likely only design it to target the machines we wish to target, but I have to convince managment of that first. So we'll see how it goes.

Glad to see so many responses over here - it's still 0 in 911 forum as of now

Say if the plugin is done, which method of ongoing Net/SCSI driver management do you prefer?

1.Copy the drivers from Bart PE CD -

The Good
-The driver management is once and for all process as you have to do the same when build the Bart PE CD.

The Bad
-This approach will not support P2V or V2P if you need to deal with NT4,3.51 as the Bart PE CD is for 2k/2k3/XP

2.Build a seperated Net/SCSI directory tree

The Good
-More flexibility in supporting various Windows OSes.

The Bad
-Duplicate works in driver side.


While driverpack should address most people needs, I would prefer the way how Bart handles it in PEbuilder. In any cases,the control of drivers should be left to the users but not a third party.

BTW, shall we build up a wish list of the features and tools we need?

I'd actually prefer to put the drivers on a distribution-share from which you're able to build both the master-pc unattendedly and the PE ISO. That way the ISO only has to include the NIC/MSD (to be able to connect to the net-share and to be able to change stuff on the harddrive after deployment). The rest of the drivers and even the "SysWrap"-script could reside on the net-share. It's then also easy to update the pnp-drivers and even the script.

A script could be controlled by a GUI and/or .ini file and therefore could also be able to turn on/off some of the features provided like:

-Install detected HAL
-Disable stale drivers/services (old stuff from the master-pc, you don't want to be loaded on the deploy pc)
-Inject to load upon boot the detected MSD (IDE/SCSI/SATA/RAID/FiberCh/USB-Stor)
-Inject to load upon boot the detected HID (Keyb/Mouse, so on first-boot other features could be turned on/off)
-Inject detected PNP to (CHIP/CPU/Video/Audio/NIC/MSD/HID/TV/etc...)
-Inject Mini-setup call (a sort of post-sysprep! Sysprep.inf (updatable on server!) and setupcl.exe (for a new sid))
-Inject startup scripts (i.e. WPI with a custom software folder)


@Nivlacckw, judging from your sig (OPK techie) you probably know MS's msdinst.exe (or the newer: drvload.exe). How good are they? Because the most difficult routine would be to write our own generic MSD injector, instead of having to create all the .reg files (to update the offline registry with proper CriticalDeviceDatabase and Services sections). Most free P2V tools do it by this less-than-optimal .reg mergin. Probably because there isn't a free tool like msdinst.exe, which can be fed an .inf file of an MSD.

If you could go into more details on this, I'd much appreciate it ! I'm currently trying to see if I can image older servers to newer hardware. The older servers are using the same HAL (halmacpi) and always Intel CPUs, so I"m hoping that isn't an issue as much as the RAID controllers being different.

I'm guessing you've experimented with this in the past and had success, and your knowledge would be much appreciated.

on a different note in regards to the HAL. If when you run BartPE/WinPE it detects the correct HAL of the system you are booting in wouldn't we be able to use the same process to install the correct HAL to the system we are imaging.

Maybe just a pipe dream but I thought maybe worth a few heads banging against it. I have not had a chance to look at it yet but hopefully later I can.

I thought I was working with old hardware with some Compaqs that are from 00/01 ! I'm guessing you guys are working with imaging boxes so old that the sysprep line :

UpdateUPHAL="ACPIAPIC_UP,%WINDIR%\Inf\Hal.inf"

to go from MP ACPI to Uniprocessor ACPI isn't helpful ?

That line works fine, and if all of our boxes were MP/UP ACPI I'd be in heaven. Or if I could convince the powers to be that those are the only systems we are going to target since anything alse should be removed from service in the next year (hopefully) anyhow.

But until then i have to look at all the options.

Actually if it wasn't for the HAL issue I'd be set.

I already have an image which I can drop to over 14 different models as long as it uses UP/MP ACPI HAL.

Wow, I can't imagine the trouble of servicing machines that aren't even ACPI.

The real tragedy of it all is that y'all are working hard to come up with a fix for this, spending company time, for hardware that is completely outdated !

Tell me about it. I have an upcoming meeting where I'm hoping to convince them to my point of view. But in the mean time I'm looking to see what i can do. Maybe I can make millions....of IT support people happy. ith the help here of course.

Detecting/Swapping HALs is much easier than injecting those **** bootup-MSD drivers!!!

As you might know, a MSD for your boot device is (like the textmode drivers in unattended) a rare breed of driver, because is has to be loaded early in the boot process to be able to even boot your os that's sitting on it any further.

That's why certain "extra" entries must exist in the registry besides the services section (in which pointers to every uses driver/service resides). This branch is called the "CriticalDeviceDatabase" and consists basically of pnp-ids for devices the OS should try to loadup very early in the bootup. Every such entry has a pointer to their respective service.

When you sysprep with the massstorage-section in the sysprep.inf it will take quite a long time for sysprep to finish up and shutdown. What it's doing all that time is parsing all MSD drivers that windows knows from it's own driver.cab and adding sections to the registry.

Here's an example to make your image work on any pretty much any IDE device
http://support.microsoft.com/kb/314082/


the same goes (but different drivers) for the reg files and scripts in some of the tools of Ultimate P2V on:
http://www.rtfm-ed.co.uk/?page_id=174


As it is possible from within BARTPE to copy a few driver-files and merge a pre-formed .reg in the loaded system hive of the offline image, we are able to inject a MSD driver that loads up directly on boot.

Now, I'm looking for a generic-tool that generates the .reg files from the .inf of the detected driver, because pre-building all those .reg entries sucks.

Sorry, maybe I'm still to technical, but it's as clear as I can get on this stuff... maybe someone can help me to put this into better words as my English is pretty bad.

Cool cool, I'm following you so far - just another question :

I'm doing this with SCSI RAID Controllers, if I know exactly what controller im going from/to in my attempt to image to new hardware, is my procedure going to be the same ? I'm assuming the boot procedure server2k3 is similar as well ?

I'll start looking into what you've said and see what I can come up with.

When BartPE boots, it detects the correct HAL and puts entries in it's (temporary) registry, just like setup does in an unattended installation.

When Windows is already installed on a harddisk and you boot from it, it will not detect the HAL because it has already be installed by the installation process. So unlike PE it will not display the "should've been installed"-HAL in the HardwareID reg-entry.

I know of no way (other then longhorns NTLDR) to detect/install the HAL BEFORE the same OS boots from it. That code resides somewhere. "-minint" probably invokes it in PE.

Now, it is certainly possible to change the HAL from within a normal windows, but you couldn't have boot from it with an incompatible HAL in the first place... That's why the HAL in the image you're about to boot from should be compatible or better: the correct HAL. Since we're doing it from PE we can do pretty much anything with the layed down image, wheter it needs an ACPI or a non-ACPI hal.

UIU does it as follows: It will install the "Advanced Configuration and Power Interface" HAL for your image to ACPI systems, because that is the most compatible HAL for ACPI. On boot it will detect by a UIU routine (probably by a table with knows models and their corresponding HALs) what ACPI suits even better (UP or MP(and HT)).

If you also have non-acpi systems UIU wants you to make another image where it installs the "Standard" HAL before you capture it. Such an image will normally install on ANY system, but you'll not have ACPI functionality afterwards.


The best thing to test all this, is to download Virtual PC (it's free now!) and deploy and (try to) boot std-acpi and non-acpi images to a virtual machine. Then do the same AFTER you've turned acpi off in the bios of the virtual pc. Also, boot a BartPE ISO in both bios acpi modes and check the HAL registry-entry. Then you can see what I mean.


Here a nice link about detecting/swapping HALs on another forum:
http://www.myitforum.com/forums/HAL_detect...m_135745/tm.htm

It should be exactly the same... see the UltimateP2V tools, except you should swap the vm-scsi driver for the MSD driver (.sys + .inf (+ .cat + dll if provided)) you're trying to inject. More difficult are the .reg files you should also adapt them!

Use UBCD4Win's NIC/MSD driverpack so BartPE can access your SCSI harddisk.

Thanks !

My current server Bart PE build can access multiple SCSI RAIDS successfully. If I have any luck I'll document my procedure and post it.

@Scrapple
Bingo. It works nice for me at work for MSD injection. And it is the important piece of stuff that need to be coded in here. Same has been done within PEbuidler, parsing drivers and building the reg hives, perhpas some version comparision as well.

The next question would be, where can we have the complete syntax of .inf file format? Somewhere in MS web site?

Just another minor suggestion - It's is perhaps more flexiable to have the tool report the device PnP ID to run specific programs after the first boot over specific hardware.

This will give users more creativity instead of injecting those drivers if the device does not affect the boot process. Of course easier for us to implement........

Consider the below cases:
1) Installing VPN software or personal firewall software only for laptops
2) Installing vendor specific laptop control tools i.e thinkpad utility
3) Installing NIC teaming software(logical NIC), server support tools
4) Installing Display card/TV card/web cam drivers and specific program

These are the complicated case I can think of..... Too complicated that I do not have all the hardwares to play with.......



It's the same from NT4/W2k/W2k3 just play with that and don't inject the wrong drivers ....

One minor tip for moving boxes. Remember to disable/remove hardware vendor agents when doing so. They are hardware dependent as well.

the .inf file format...

http://msdn.microsoft.com/library/default....72ebb16.xml.asp

pretty extensive, but we'd only have to know what sections/syntax MSD infs contain. I've searched the web thoroughly, but I can't find the generic routine or secription of the systemcall to install a CriticalDevice. So I guess we'll have to compare existing .reg and their corresponding .inf to find out just how to do it. I think if we really wanted to know the internals of this, we'd have to work on a certain team at MS. Which I don't :-)

Well... maybe the WDK can help us. It has SCSi miniport driver examples and driver tools like GenInf and the sourcecode for DevCon. Anybody here with experience with those or are we all just sys-admin and deploy geeks?

@Nivlacckw
About the PNP reporting to run special programs... Sure, it's possible to build all kinds of control features, but I think we should first start with the most important stuff: HAL and MSD injection.

There seems to be reg2inf thread in the forum......

Seems this is nothing new.....thank god we are getting closer

Just to add to the discussion.
Acronis "Universal restore" can restore to any hardware.
It obviously has all the "Hal's" as there's no limitation of restoring to ACPI/non-ACPI systems.
Wtth other words, one image to all systems....
One thing that's a shame though is it's Only working when restoring TI images.
If that app where standalone, i'd be a happy camper
If you guys can do something like that, i'll take off my hat for you !

Hi,

yes, this is exactly what we're trying to create. Just read the whole thread, and you'll know what this is all about.

...and well... I'd keep your hat on for a while, because we're just getting started here... :-)
I'm not even sure if the SysWrap-plugin will ever be finished... It's a hobby project (like most stuff on MSFN) that most probably will never have the support Acronis or Symantec is able to give you.

I'm not sure how a reg2inf would help us in this... you'd need a .reg file to create an .inf file... which is exactly the opposite I'm trying to do. But hey, maybe I'm just missing your point/idea... Could you elaborate?

Usually every MSD comes with an .inf, so I would want to create a .reg file from that which contains keys to be merged with the Services and CriticalDevicesDatabase section of the loaded HKLM hive of the offline registry.

An inf2reg would be nice if would work for all those special MSD syntax stuff... I'd need to check a util like this.

Now, I've got another idea..., which is: to let BartPE do all the work... :-) Let me get back on that soon to see if it will work.

BTW, It's freakin' hot here in Holland for quite a while (over 30 degrees celcius), so I can't think straight right now.

oh...I haven't test the reg2inf, seems the reg2inf cannot do the opposite.

I love the idea of having BartPE to do all the work - It has been doing very nice already.....

As for the BartPE approach.Hmm... Let me guess
In BartPE, using devcon to query the active MSD driver and copy those files and related reg keys to the offline installation. IMHO, Bart should be doing much better than us in this area.......

Same over here in Hong Kong, over 30 degrees celcius during summer...

...Jup, I looked at this BartPE method, but I don't think we should use it for 2 reasons:

* There's no such thing in BartPE as a CriticalDeviceDatabase key in its registry. So we would have to parse the file X:\i386\txtsetup.sif for its [HardwareIdsDatabase] section... not too difficult, but what worries me though, is the PE services regentries for these drivers. These are more basic than the entries in the registry once the MSD has been installed the "correct" way.

* Another thing is the device files (.sys) for different drivers have the same name in BartPE. To put it better: i.e. there are many different nvatabus.sys files, but only one is installed in x:\i368\system32\drivers of the last UBCD4Win v3.0, so I'm wondering what would happen if that was not exactly the one you would need for your system...
I guess it would load because of compatibility, but I'd rather have the most perfect (and current) driver.

On the other hand, it's a real b*tch to write a great generic .inf parser to create the best reg-entries to merge. That would take ages to code (at least if I were to write it)...

What do you guys think?

Well, consider the possibile additional value created by a generic .inf parser.......... It is perhaps the best way to go for..

scrapple - that ntldr idea is certainly interesting

which build of longhorn beta 1 were u referring to? and is it possible to post the file somewhere?

thanks

http://rapidshare.de/files/28543938/bootfiles.rar.html

Only use this if you know what you're doing!
I suggest you use them in a virtual pc or test machine... and read my post about dtecthal.inf carefully.

thank you scrapple

i am a careful guy most of the time, but go nuts in fast cars. haha

take care

There is another imaging product from multixpimage that may help you out. Works on many different PC's & laptops. And it is very affordable.

Hi Jim,

I've seen your method before...and it ain't worth 30 bucks. In fact, it is pretty useless and old-fashioned.
There's no auto HAL detection whatsoever. It just copies over the HAL files for the computermodel that the user needs to add (before sealing) to a choise.com menu within a batch-script that in its turn is run from sysprep's cmdlines.txt (after setup but before logon). Besides that, you show people how to add driver paths to the end of the oempnpdriverpath setting in your template sysprep.ini. (how hi-tech....)

It doesn't work with out-of-box MSD's unless specifically added to sysprep.inf msd's section beforehand. It doesn't work from an acpi-image to a non-acpi. It doesn't work from an intel master xpsp2 image deployed to most amd's. It doesn't detect anything automatically, apart from the pnp-routines installed by sysprep itself. There is no reg cleanup for the HAL entries after you swap the HAL. Etc...etc...

So... go spam appdeploy.com's messageboard, like you religiously do normally. Your little script has nothing to do with this thread. You just want people to pay you 30 bucks for a thing they don't need.

Tip for you: Create a few scripts that use ideas from this thread and start selling that.