nivlacckw

And single HAL for all machine as well.....

Intel® 5000 Series Chipsets Integrated Device - 1A38 http://listing.driveragent.com/pci/8086/?q...a4a677ad24761f3

Highly recommend reading. This should cover most (if not all) areas.. Microsoft Solution Accelerator for Business Desktop Deploymenthttp://www.microsoft.com/technet/desktopdeployment/bddoverview.mspx

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 Anybody come across HAL changers from major server vendors back to the NT4 days? There used to be a program for changing HAL online from standard to ACPI years ago..

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

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

There seems to be reg2inf thread in the forum...... Seems this is nothing new.....thank god we are getting closer

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

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?

Some more external reference of this concept from Microsoft http://download.microsoft.com/documents/uk...eploying_XP.ppt

Can you give us more details about this HW detection tool? It's devcon.exe from microsoft which is a command line version of device manager. You need to do some scripting work on top of it. This idea and discussion is now getting started under the below thread. Change the HAL and add mass storage drivers -How to combine existing P2V techniques for imaging http://www.msfn.org/board/index.php?showtopic=78535

Post in 911 CD forum to draw Pebuilder's community attention http://www.911cd.net/forums//index.php?showtopic=17752

I was checking these links out and I think he's talking about changing the HAL with devcon. He's also suggesting adapting the physical to virtual (P2V) change of Mass storage drivers for a newly imaged system instead of a virtual one. So it adds an extra CD change/boot step to the system build process, but it may be worth it in the long run. Pretty novel way of creating your own UIU process, if it doesn't have any latent issues/limitations. Looks like I have more testing to do! One of the ideal way to implement this is to write a plugin in BartPE environment to pull the drivers and inf files from the BartPE CD itself and inject to the offline installation. PEbuilder does allow adding mass storage drivers, parses and merges them during the build process. Thus push the driver management effort to the min - this is perhaps the shortcomings in the existing fixscsi plugin. If a machine managed to boot up with BartPe based CD with disk drives then there must be a mass storage driver within. I believe there must be some people interested in this as this should help migrating Windows installations across different hardware without reinstall. BTW, the MS BDD 2.0/2.5 seems using on this process......... B)

In fact, this is easier for beginners to debug the build process as well. The key sucessful factor is about the design of the build process but not the imaging procduct. PS. If we going more into details about this, we are moving towards to things like packaging and desktop management BTW, there is another way to change HAL and mass storage drivers after image has been deployed to the system and inject the HAL/Mass storage drivers to the installation prior the system bring up . So single image for all machines is possible. Reimaging is not necessary for driver updates.

Agree with this. Identify GUID issues for add on apps is far much more complicated than dealing with OS itself when using disk imaging approach. There could be cases that the applications vendors do not provide utility like this Trend example. In general software requires GUID are management agents (SMS client, AV clients, hardware agents etc) and client software that needs to unique indentity to present to the server. In my company (120k users european bank), we use hybrid approach. Imaging for core OS and more static parts. At the end of imaging , calling for an unattended installation script from network for Windows hotfixs and apps that are frequently updated or having GUID issues. This may not be the fastest solution compare with imaging all apps, however it does provide certain flexibility in managing software in a modular approach within the SOE build without frequently recreate the image. just my 2 cents