You are not logged in. Please login or register.
I used to do that by selecting Advanced Configuration and Power Interface (ACPI) PC and Standard IDE before running Sysprep. The HAL is basically the one that just works with just about everything, fortunately.
So we could script devcon to update the (ACPI) PC "driver" and reboot fixing/updateing the HAL
(and totaly re-enumerating the machine on the next reboot)...
Exactly... this is basically what acronis and ghost do.
Wait a minute - that is brilliant...
we could script detecting and updateing the HAL... why not?
select basic hal that is fully compatable with all platforms then script detection and updateing...
In fact i seem to remember seeing a script that does this somewhere...
we're getting somwhere now... we can call it the "DriverPacks SysPrep Alternative"
The only program I've found which accurately detects both Intel and AMD processors is this: http://crystalmark.info/software/Crysta … dex-e.html. It is scriptable and so can be used for the correct detecting of necessary HAL. Both PantherXP (http://pantherxp.net/) and OfflineSysPrep make use of it now.
Regards,
Galapo.
I put the ball in your (SysPrep Users) court to test and report on my code.
To make suggestions, to point out my failings - what an opening that is!
To show me what works, and what does not, and WHY!
To remind you of the main issue I see with the sysprep method:
http://forum.driverpacks.net/viewtopic. … 036#p28036
http://forum.driverpacks.net/viewtopic. … 056#p28056
http://forum.driverpacks.net/viewtopic. … 068#p28068
http://forum.driverpacks.net/viewtopic. … 070#p28070
Regards,
Galapo.
TY Galapo... you da man!
Ok so if i am following you it is neccessary to add the registry entries directly and bypass sysprep.inf
have you or someone else documented the entries that must be updated to bypass sysprep.inf?
Or is my idea of createing a custom INF similar to the SCSI.inf valid...
Ok so if i am following you it is neccessary to add the registry entries directly and bypass sysprep.inf
Exactly! And so OfflineSysPrep was born, which allows for sysprepping options but no mass storage injection from sysprep.inf. This is instead accomplished by DP mass storage plugin data because there hwids are tied to unique service names and driver files.
have you or someone else documented the entries that must be updated to bypass sysprep.inf?
As a minimum you need:
1. CriticalDeviceDatabase entry with a) hwid; b) ClassGUID; c) Service.
2. Serice entry added under current ControlSet with a) DisplayName; b) ErrorControl (00000001); c) Group; Start (00000000). Optional: Tag. Sometimes required: PnpInterface.
Of course, other option is to edit INFs and rename files (as driver manufactures should be releasing them like this in the first place) so that they conform for use with sysprep.
Regards,
Galapo.
Jeez, busy night, looks like I missed some good stuff 
Yeah baby - talk to me guys!
How many of you guys use ghost - that totaly eliminates the SID issue...
I do use it, but Ghost doesn't touch the SID, you need GhostWalker to do that part if you want a 3rd party tool to do SID. Ghost just clones. SysPrep directly handles SID, when SysPrep setup manager is run it gives an option to not reset the SID, which means if you don't check it, the SID is reset. That is why your (OverFlow) suggestion earlier about just copying the hard drive's files over to another drive works instead of needing cloning software - my Restore disc simply marks a partition as active and un7zips an archive of a SysPrepped setup.
So am I on the same page as you guys that you want to make an alternative to SysPrep so the cloned system is never even forced to run through a mini setup?? I think if you replace HAL.DLL and the kernel with the original (or a working) set from Recovery Console then reboot, all of the system's drivers have to be reinstalled. Example - if a customer brings me an old machine to fix and it has a bad board, say a Socket A, and they have Windows XP on it, and there is some application they don't have a disc for and seem like they are very upset to hear that they may need a Windows reload and loose that app when they get a new motherboard, replacing HAL.DLL should be all that is needed to make the machine boot on the new board, as long as the hard drive controller is recognized by their XP install. I highlighted SHOULD because I have only tried this a couple of times, rarely has it been an issue that was sooooooo important that it was worth taking the time to do it, and I always prefer a fresh install on a new mobo. Point is, if a total alternative is what you're after so that an image is dumped on a drive, the drive on a mobo, and the system just boots in to Windows, then I think replacing HAL and the kernal, injecting the proper MS drivers, then calling SAD/other on the first boot seems like somewhere to start....
Can't say I know if that is feasable, but may try to do some testing on this today if time allows....
select basic hal that is fully compatable with all platforms then script detection and updateing...
In fact i seem to remember seeing a script that does this somewhere...
http://www.myitforum.com/articles/15/view.asp?id=8997
That what you were thinking of?
Ian
I do use it, but Ghost doesn't touch the SID, you need GhostWalker to do that part if you want a 3rd party tool to do SID. Ghost just clones. SysPrep directly handles SID, when SysPrep setup manager is run it gives an option to not reset the SID, which means if you don't check it, the SID is reset. That is why your (OverFlow) suggestion earlier about just copying the hard drive's files over to another drive works instead of needing cloning software - my Restore disc simply marks a partition as active and un7zips an archive of a SysPrepped setup.
Actually the latest version of Ghost, if I'm not mistaken, has the ability to change SID (albeit I think it uses NewSid or Sysprep too lol).
I could be wrong. As I hate the latest version of Ghost.
Last edited by stamandster (2009-03-06 01:12:59)
Looks like I was too optimistic, bonked. I went so far as to remove Device Manager\System Devices\Microsoft ACPI-Compliant System, set HAL and KTOSKRNL to standard ACPI, and extracted the entire contents of the MS pack to Windows\INF but it still wouldn't finish booting.........
There may be another way, and I swore this worked, but no go.
Ian
hmm, slight addendum, the system DID boot in Safe Mode. I let Safe Mode play around with the drivers as much as it could, but once it asked for help installing anything I rebooted in Normal mode and it worked fine, albeit missing many drivers. Well, now I could call my installer and off we go.
The original machine was an Athlon64 X2 on an ATi chipset, I did the above steps and moved it over to an Athlon64 X2 on an nVidia chipset. ACPI was detecting properly as ACPI, since I set it that way, so the HAL switch would need to be thrown in somewhere, but this is interesting. I think I'm going to take down a P3 1GHz system and do the above steps and move it over to the A64 nVidia system and see if the same thing happens. If so, strange procedure, not at all automatic (yet) but it may work.
Ian
In Windows 98 we used to enum the system drivers in the registry. I don't know if we can do it in a similar way.
Oh and in your test the HAL would be the same, it's only the chipset that's different. And it'd most likely work without any extra intervention except for booting into safe mode.
Last edited by stamandster (2009-03-06 06:52:54)
You're right about the HAL being the same since they were both X2s, but I wanted to reset to standard ACPI to make it a more "true" test...
The Safe Mode thing was just a fluke the first time around, didn't end up helping......
I'll look around for a similar solution to the enum key
Thanks
Ian
Ghost has changed the SID since like version 3, maybe 4 (late 90's)... if it did not ghost would never have worked for corporate customers 
- Ghost Walker for single copies - and is automatic if multicast is used...
we used to use it at the phone company, at that time we were supporting over 3000 desktops with it. ( and we did not use sysprep 
)
Ghost was introduced in 1996 by Binary Research. It initially supported only FAT filesystems directly, but it could copy but not resize other filesystems by performing a sector copy on them. Ghost added support for the NTFS filesystem later that year, and also provided a program to change the Security Identifier (SID) which made Windows NT systems distinguishable from each other. Support for the ext2 filesystem was added in 1999.
http://en.wikipedia.org/wiki/Disk_cloning
the SID is also changed when a machine joins a domain (in most cases)...
Some interesting information HAL changing issues
http://communities.vmware.com/thread/15 … p;tstart=0
http://communities.vmware.com/thread/29202
and an MS kb
http://support.microsoft.com/kb/237556
So a couple things noted...
Multiprocessors use -
i386\driver.cab\ntkrnlmp.exe extracted to %windows%\\System32\ntoskrnl.exe
i386\driver.cab\ntkrpamp.exe extracted to %windows%\System32\ntkrnlpa.exe
Uniprocessors use -
i386\driver.cab\ntoskrnl.exe extracted to %windows%\System32\ntoskrnl.exe
i386\driver.cab\ntkrnlpa.exe extracted to %windows%\System32\ntkrnlpa.exe
HALs -
i386 source file: i386\driver.cab\halmacpi.dll
Computer type: ACPI Multiprocessor PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
i386 source file: i386\driver.cab\halaacpi.dll
Computer type: ACPI Uniprocessor PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
i386 source file: i386\driver.cab\halacpi.dll
Computer type: Advanced Configuration and Power Interface (ACPI) PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
i386 source file: *i386\driver.cab\halsp.dll
Computer type: Compaq SystemPro Multiprocessor or 100% Compatible
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
i386 source file: *i386\driver.cab\halapic.dll
Computer type: MPS Uniprocessor PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
i386 source file: *i386\driver.cab\halmps.dll
Computer type: MPS Multiprocessor PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
i386 source file: *i386\driver.cab\hal.dll
Computer type: Standard PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
i386 source file: *i386\driver.cab\halborg.dll
Computer type: SGI mp
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
The only HAL above that seems to work on both normal/standard/most Uni and Multi Processors is this one -
i386 source file: i386\driver.cab\halacpi.dll
Computer type: Advanced Configuration and Power Interface (ACPI) PC
Copy to this folder: winnt\System32
Rename to this file name: hal.dll
We should be able to edit our own INF file to change the HAL appropriately with the HAL.inf. Perhaps we can install the HAL like we do the mass storage? Only reason I say that is because Sysprep -bmsd injects System classes into mass storage section of the sysprep.inf file from the windows driver directory.
But we also have the issue of an incorrect mass storage driver.
Perhaps we should move the posts on Replacing Sysprep with our own process to another thread?
ed. I just found this helpful little tidbit that we might be able to edit to our testing...
http://windowsitpro.com/article/article … ssing.html
Last edited by stamandster (2009-03-07 01:27:37)
Wow...
you guys are my heros!
thanks for all the excellent info...
The way I do it in OfflineSysPrep is to accurately detect CPU with CrystalCPUID. Once correct CPU is known and what it can support (eg, dual core, hyperthreading, etc), then correct/matching HAL files are extracted from correct CAB file under '%WinDir%\Driver Cache\i386\'. Then required registry entries are written.
With this method, a computer initially installed with standard HAL can even be set to multiprocessor HAL, something which MS says is impossible (of course, CPU must be able to support it).
Regards,
Galapo.
Last edited by Galapo (2009-03-07 07:48:07)
i did not realize that offlinesysprep was such a complete tool...
It sounds like i would just be reinventing the wheel by pursuing this...
Don't get me wrong guys, OfflineSysprep has it's place. But my problem with it is that to be useful for my purpose I would have to clone a machine installed with no MS text mode drivers and ACPI HAL on to any given machine, then boot with Bart/LiveXP and run OfflineSysprep to get the system bootable. I agree that it might feel like reinventing the wheel, but if a method with all of this functionality could be set up so it runs automatically on the first boot after a Sysprep reseal then Sysprep would be given a huge move forward. Even if Sysprep were abandoned entirely, point is if this could be done at bootup, it would be that much sweeter.
Ian
Ah... 'Ping'... the lightbulb comes on...
So we have some awsome building blocks for a DriverPacks solution.
the DriverPacks solution (as always) would be depoyable as an unattended platform
- and OSP is an attended solution...
- i belived that after an OSP was performed on each type of machine in your envirionment
that it would then be complete / deployable without user intervention...
Yeah I'd also rather not have to boot into a PE type environment. It's not as fast as sysprep either.
I also thought that about OfflineSysprep till I tried it. Very easy to use, but the only time that I see it being usefull is a)you have a significant amount of hardware-identical systems you want to install an image on but the source image differs from the target machines so this could edit a pre-existing image to work b)migrating an installed XP to a new motherboard with less risk of blue-screens. It IS a great setup and very complete, but it is platform-specific. When I used it for the first time I realized it was making an image compatible to the system I ran it FROM, not where it was GOING. I will have occasions where that will come in handy in the future and am glad to have it as an option for those cases, but it does not make a universal image, it takes one and makes it VERY specific.
So, how in the WORLD would we get a foot hold on a fake pre-setup? MySysprep does it, the documentation on the web page says that MySysprep runs at boot and figures out which HAL to install, then it calls the real Sysprep and backs off. Would that be a local WinPE? If we were to be able to shut down XP and have it call a WinPE environment on the next boot that would determine which HAL to use and do a Bart-like MS install so that having duplicate HWIDs wouldn't matter (something I don't honestly understand what the big deal is anyway but obviously others know more about that than I do..(what about DPInst?? Let IT choose....)) then we would know which MS to use, inject that so XP wouldn't freak, and bing, be up and running. Of course, to keep things legit the product key would need to be switched, but there is a registry key that if altered activation is broken, so all we would need to do there is prior to shutdown
RegWrite("HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current
Version\WPAEvents","OOBETimer","REG_BINARY","0")and after bootup
ShellExecute("c:\windows\system32\oobe\msoobe.exe /a")As far as the dup HWID for MS, what about having a special pack just for this Sysprep alternative? Couldn't say all nVidia MS drivers be "merged" so that if there is a dup HWID, all files are copied that would affect each set of drivers? That's another thing I've been thinking about and deciding if I want to persue for a loooong time, but haven't because of making constant tweaks to my universal images, then the driver installer, now I'm writing a backup app for the shop's techs so every backup is uniform in what is saved and how........ No time right now for this MS merging experiment!!
Sheesh, and to think that at the beginning of the year I hadn't coded anything in 10 years, now I'm writing driver installers!!!!! HAHAHA!! Gotta love AutoIt!!
Ian
I will have occasions where that will come in handy in the future and am glad to have it as an option for those cases, but it does not make a universal image, it takes one and makes it VERY specific.
Actually, that's not entirely true. OSP can perform much of what sysprep does with running it. That is, it is a "generalisation" process to ready the system/image to be deployed onto different hardward. Drivers may be injected, and "specificity" is basically limited to how many drivers you decide to inject. If you choose to inject all the DP mass storage drivers, then so many are injected that native ntldr cannot cope (have to resort to xp 64-bit version etc.). So in this case, it is not making it "very specific".
In the case of HAL, yes, it is specific to the option chosen. The plan in OSP version 2 is for OSP be able to run from commandline or supplied INI file and be able to do HAL setting on first boot. If I get time, I might be able to add this feature to version 1 perhaps if it's useful.
Regards,
Galapo.
well i would need to know which executable minisetup is ... is it just setup with a parameter after it? or winnt32... ect. then i write a fake setup... autoit will fail at PE so it will need to be vb or something else... nbd
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.022 seconds, 10 queries executed ]