[Scrapple]

dobbelina, on Jul 22 2006, 08:28 AM, said:

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]

nivlacckw, on Jul 19 2006, 02:39 PM, said:

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]

Scrapple, on Jul 22 2006, 05:24 PM, said:

nivlacckw, on Jul 19 2006, 02:39 PM, said:

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]

nivlacckw, on Jul 22 2006, 08:51 PM, said:

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]

Scrapple, on Jul 23 2006, 09:08 PM, said:

nivlacckw, on Jul 22 2006, 08:51 PM, said:

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

[curry2]

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

This post has been edited by curry2: 05 August 2006 - 06:58 AM

[Scrapple]

http://rapidshare.de...tfiles.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.

[curry2]

thank you scrapple

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

take care

[imaster]

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

[Scrapple]

imaster, on Aug 10 2006, 01:13 AM, said:

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.

This post has been edited by Scrapple: 11 August 2006 - 11:07 AM

[imaster]

I use a product from multixpimage that displays a menu of all the different PC models we have during the mini-setup. Then all I have to is press 2 keys to select the correct HAL. Easy huh?

[Scrapple]

imaster, on Aug 12 2006, 02:25 PM, said:

I use a product from multixpimage that displays a menu of all the different PC models we have during the mini-setup. Then all I have to is press 2 keys to select the correct HAL. Easy huh?

You're a g-**** genius Forrest...

[jscheffelmaer]

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 =)

[Scrapple]

jscheffelmaer, on Aug 13 2006, 05:53 PM, said:

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.

[jscheffelmaer]

Scrapple, on Aug 13 2006, 11:21 AM, said:

jscheffelmaer, on Aug 13 2006, 05:53 PM, said:

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.

This post has been edited by jscheffelmaer: 13 August 2006 - 05:03 PM

[faceman71]

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

Quote

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.

[prozac]

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?

[Scrapple]

prozac, on Aug 25 2006, 10:27 AM, said:

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

[Scrapple]

faceman71, on Aug 24 2006, 10:12 PM, said:

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

Quote

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!

[kickarse]

Could we possibly keep this On Topic?

I too am looking for a way to generate proper HAL before Sysprep loads Minisetup...

This gives and interesting idea
http://thesystemadmi....com/n27-6.html