Jump to content

Change the HAL and add mass storage drivers


Mordac85

Recommended Posts

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

Edited by curry2
Link to comment
Share on other sites


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

Edited by Scrapple
Link to comment
Share on other sites

So why not have a database of your supported hardware by WMI model. And that databse holds the key to drivers/hal/vendor specific software, etc? This way you can also control if you allow non-standard hardware from being built with your build code with one variable

ALLOW_UNSUPPORTED_HARDWARE = False as a constant in the code.

This would allow you complete control over all drivers and software.

In fact, it is how we do it today =)

Link to comment
Share on other sites

So why not have a database of your supported hardware by WMI model. And that databse holds the key to drivers/hal/vendor specific software, etc? This way you can also control if you allow non-standard hardware from being built with your build code with one variable

ALLOW_UNSUPPORTED_HARDWARE = False as a constant in the code.

This would allow you complete control over all drivers and software.

In fact, it is how we do it today =)

If I understand you correctly you want to get the manufacturer's model-string from WMI and that would then serve as a pointer to a list of drivers...

Well, the problem with this idea is that the model-string will not garantee what HAL and or drivers the deployed machine will need, because at least in our environment we have a number of pc's with the same model-string but house quite different hardware.

I'd rather get a list of hardware in the deployed-machine by using a utility like pci32.exe of devcon.

Link to comment
Share on other sites

So why not have a database of your supported hardware by WMI model. And that databse holds the key to drivers/hal/vendor specific software, etc? This way you can also control if you allow non-standard hardware from being built with your build code with one variable

ALLOW_UNSUPPORTED_HARDWARE = False as a constant in the code.

This would allow you complete control over all drivers and software.

In fact, it is how we do it today =)

If I understand you correctly you want to get the manufacturer's model-string from WMI and that would then serve as a pointer to a list of drivers...

Well, the problem with this idea is that the model-string will not garantee what HAL and or drivers the deployed machine will need, because at least in our environment we have a number of pc's with the same model-string but house quite different hardware.

I'd rather get a list of hardware in the deployed-machine by using a utility like pci32.exe of devcon.

Hmm, that is quite interesting as I have never run across the same model number with different hardware (Edit: Sorry, meant with corporate purchases, not custom builds such as home). Did you find this to be true using the win32_computersystem.model property or another property? It is true it does not tell you what HAL it is to run, but you can include the HAL in the database for that model detected and return that back tot the script.

Unfortunately it would not be automated from the get-go, but someone would be admin'ing and updating with each new hardware that enters the environment. I wouldn't call this necessarily a bad thing though. =)

Try doing a query of the property I listed above on random spots of your inventory and see what you find. The only time I have seen it be an issue is with custom built hardware unfortunately, but IBM/DELL/HP return quite reliable values.

Edited by jscheffelmaer
Link to comment
Share on other sites

  • 2 weeks later...

To those that were posting about the UIU (Universal Imaging Utility) earlier in this thread:

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

The UIU can handle multiple HALs, and will also handle going from IDE to SCSI, PATA/SATA. The UIU is also capable of being run on a SCSI machine and deploying to IDE, PATA/SATA. The UIU has been capable of doing this since May 2005, and the documentation for the UIU has stated this since May 2005. We have a new version that has been released July 2006 that provides a nicer interface, a more compressed driver library, and several new options.

The person who claims that our documentation states that you need two images is referring to machines that have the "Standard PC" HAL. These machines stopped being produced around 1999. If you still have these machines running in your environment and you have a great need to deploy these machines to the rest of your working environment I wish you good luck. Most users have migrated off of machines this old about 3 or 4 years ago. This was more of an issue when the UIU was originally released in early 2004 because there were still some a minority of users using this archaic hardware.

I work with supporting and development of the UIU.

Link to comment
Share on other sites

About MSD injection.

I was wondering if its possible to use Rundll32 Inf installation to install the drivers in the offline registry ?

Any thoughs on that?

Hi Prozac,

Unfortunately this won't work, because the -very- undocumented, but really interesting functions within setupapi can't stray from their -probably- hardcoded reg-roots like HKLM\System\CCS\CriticalDevDB and the services section.

I've looked into this idea myself... but I'm not a programmer and I don't work for MS, so my knowledge about setupapi is really limited.

BUT... I have some good news concerning MSD injection. Let me tell you what I tried:

I had some old image that did not include drivers for a Promise Fasttrak Sata Raid Controller. So I deployed that image from BartPE to such a Raid system, which of course gave me a 00007B bluescreen on first boot.

Downloaded MSD to see what files (easy) and reg entries (difficult) were neccessary to inject.

injected the cat, dll, inf and sys into the offline image and loaded the offline system-reg to a temp hive of BartPE. injected the most basic CriticalDev and Service key I could create... So no extra reg-parameters for the driver at all! Unloaded the temp-hive, shutdown Bartpe and tried to boot from the Harddisk again expecting it to fail miserably again with a 7B...

..... That did not happen.... It booted correctly... to my surprise! After my bootup I updated the driver like you would do normally (this can be scripted BTW) and restarted the machine... Booted fine again and there they were in the registry... all the parameters that I would've wanted to install directly from the inf within BartPE, but too difficult for me to write a generic parser for.

So what could this mean? It could mean we only have to inject -very- basic entries in the Services and CritDevDB for the image to boot up without real hassle. On first boot when PNP-install should be run we could (re)-install the MSD as a PNP device and after the second boot it will run like it should be, because the correct "difficult" entries would have been installed.

Of course I don't have 100's of different MSD devices laying around to test every driver on... but you guys might be able to help me with that. Testing the routine I mean... Anyway, it gives me some hope that this MSD injecting could very well be simpler than I would've thought a few weeks ago.

And yeah, it would probably also work by using the MSD drivers that BartPE uses from the CD. But we should (re-)install the -full- driver on first boot properly...

CU guys

Link to comment
Share on other sites

To those that were posting about the UIU (Universal Imaging Utility) earlier in this thread:
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

The UIU can handle multiple HALs, and will also handle going from IDE to SCSI, PATA/SATA. The UIU is also capable of being run on a SCSI machine and deploying to IDE, PATA/SATA. The UIU has been capable of doing this since May 2005, and the documentation for the UIU has stated this since May 2005. We have a new version that has been released July 2006 that provides a nicer interface, a more compressed driver library, and several new options.

The person who claims that our documentation states that you need two images is referring to machines that have the "Standard PC" HAL. These machines stopped being produced around 1999. If you still have these machines running in your environment and you have a great need to deploy these machines to the rest of your working environment I wish you good luck. Most users have migrated off of machines this old about 3 or 4 years ago. This was more of an issue when the UIU was originally released in early 2004 because there were still some a minority of users using this archaic hardware.

I work with supporting and development of the UIU.

Hi,

First of all, welcome to the thread... nice to actually meet a person that makes a living of a "universal" imaging program. And although your method is very different from what we're trying to create here, your input/thoughts will be very appreciated. Especially since you're a developer that I suppose knows a lot about this very subject.

Now as a reaction to your defense... let me quote your documentation that came with your UIU 3.0 from july 2006:

-----------------------

2) Problem: Blue Screen or Continual Rebooting:

Possible Cause: The Master PC was an ACPI compliant PC, but the PC receiving the UIU image is an older, non-ACPI compliant (Standard) machine or vise versa.

Possible Cause: Deploying to or from a RAID based system. The UIU is not currently designed to work with any RAID based systems – IDE, SATA, or SCSI.

Possible Cause: Deploying from a SCSI system to an IDE, PATA, or SATA system. The UIU image can go from IDE/PATA/SATA to SCSI only, and only with Windows XP.

Possible Cause: Missing or incorrect main board drivers. Check for UIU Updates, or contact technical support.

-----------------------

So...maybe you need to update your documentation... or tell me what I've said/read wrong... I dunno... Also, I might add that standard pc hal is not the only non-acpi hal... there are 2 more for XP and 3 more for win2k.

And yeah, it sucks that there are still quite a number of companies / IT departments that have to support these old hardware (HALs). But still...they can't be overlooked.

UIU is a nice program, but not really my thing, because it has some definate flaws that I've already pointed out at the beginning of the thread. What do you think about the method in this thread? Could you point out its flaws or tell me anything new that might be nice to know about universal imaging?

Question for you... How do you feel about the up and coming Vista Deployment method and their tools to build and edit images? Is it worrying to your current business?

Thanx a bunch!

Link to comment
Share on other sites

  • 4 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...