Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Scrapple

  1. Hi guys, Thanx for your PM's. Unfortunately I haven't had the time to answer them or even to participate on this thread lately and it will take some time before I will. BTW Deploying Vista is gonna be so different and much more convenient. You can add modules/settings to an imagefile (.WIM) with an MMC. Check out the BDD-2007 on connect.
  2. 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!
  3. 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
  4. 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.
  5. 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.
  6. 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.
  7. ...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?
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. 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.
  • Create New...