Change the HAL and add mass storage drivers

[IcemanND]

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.

[Scrapple]

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.

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.

[stickzilla]

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.

[Scrapple]

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.

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

Edited July 17, 2006 by Scrapple

[Scrapple]

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.

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.

[stickzilla]

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.

[nivlacckw]

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 -

2.Build a seperated Net/SCSI directory tree

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.

@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.......

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.

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.

Edited July 18, 2006 by nivlacckw

[Scrapple]

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.......

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.

[nivlacckw]

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

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

Edited July 19, 2006 by nivlacckw

[dobbelina]

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 !

[Scrapple]

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.

[Scrapple]

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

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

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.

[nivlacckw]

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

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

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...

[Scrapple]

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.......

...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?

[nivlacckw]

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.......

...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..