Great, glad to hear it's useful!

Regards,
Galapo.

OK, new version of OfflineSysPrep has been released that no longer requires sysprep when setting the option to automatically set HAL at first boot.

Regards,
Galapo.

kickarse wrote:

or with Devcon.exe (non-distributable)

devcon reboot

Good news! While devcon doesn't actually cause a reboot, when the app that is running as shell closes, the type of reboot that is performed does not have the hang. So devcon makes the reboot a "better" type of reboot and so I don't have to have a sysprep dependency. I'll release a new version later today.

Regards,
Galapo.

New version of OfflineSysPrep is now released with the option of automatically setting HAL at first boot added (sysprep required).

If someone is able to find a shutdown app which works under the conditions mentioned above, then I can remove the sysprep dependency.

Regards,
Galapo.

Unfortunately, no.

I've also tried PsShutdown, PowerOff, and fdapm.

Regards,
Galapo.

kickarse wrote:

Nice!! What type of shutdown app are you needing?

One that works under very tight conditions: no user logged in and explorer is not the shell. I can't find anything that works.

kickarse wrote:

Also, did you write it using part of the source of crystal program? Are you just initially setting the HAL to the one HAL that works with most systems? or is it where it truly finds the HAL before loading NTLDR?

No, I'm calling CrystalCPUID to do the CPU detection for me.

Here's what I'm doing:

1. Writing necessary registry entries and files etc. for first boot as uni processor, which will be successful even if image was orignally set to standard (something MS says is impossible to do!).
2. Set my app to run as shell upon boot.
3. At first boot, app runs, detects HAL, and makes necessary adjustments to sysprep.inf.
4. Upon reboot, sysprep completes its operations (mini-setup etc.).
5. Computer reboots.
6. Upon boot, OS detects new HAL.
7. OS needs a reboot.
8. Upon boot, correct HAL is listed in Device Manager.

If I could find a way to shut down the system, then I could do away with the sysprep dependency.

Regards,
Galapo.

llewxam wrote:

As for the above, sorry but I don't have a live disc with OSP at the moment or I'd just find out myself smile but if all that is being injected is the MS pack, would that actually be large enough to cause an issue with the default NTLDR?

Yes, you get an ntfs.sys error. This doesn't occur with PE because limit is not yet reached as cabbed drivers are supported.

llewxam wrote:

And I actually don't recall being able to use more than one, but obviously I'm wrong there...

Sorry, I wasn't saying to use more than one. I'm saying if you need to inject all the drivers, then you'll need to replace the default ntldr with one that has a higher memory limit. But this would seem to break licensing agreement, though.

Regards,
Galapo.

kickarse wrote:

So perhaps the option is to on the next boot have the system load BartsPE (as small of a load as possible) from the drive itself, have Galapo's utility run automatically (set HAL and mass storage) and reboot the machine?

That would be one way.

But I did a bit of work yesterday and have nearly finished adding the option to OfflineSysPrep to set HAL upon first boot. Read more here: http://www.911cd.net/forums//index.php? … p;p=154514

Regards,
Galapo.

llewxam wrote:

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.

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.

OverFlow wrote:

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.

OverFlow wrote:

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

OverFlow wrote:

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.

SPDrvScn won't work for mass storage drivers. It just updates the 'DevicePath' key in registry, but doesn't enter 'CriticalDeviceDatabase' or corresponding service entries. As such, on new hardware you will not survive first boot.

Regards,
Galapo.

JakeLD wrote:

OfflineSysprep took care of this issue, so I would recommend using it instead of injecting all storage drivers into your image, you can only inject the one detected in your PE...by doing that you prevent driver from conflicting with one and other.

Note: I have discovered a bug with the 'Install only PE-detected non-IDE Mass Storage Device(s)' option. Only devices with HWIDs with 'PCI\' are injected. So HWIDs like 'SCSI\', 'GenNvRaidDisk', '*NVRAIDBUS' won't be injected with this method (well, until I can do a fix, which seems a bit unlikely at the moment).

So, work-around is to make use of user_settings.ini file and enable desired drivers. Eg:

[disable_drivers]
all=disable

[enable_drivers]
qnvrd325=enable
qnvraid=enable

Regards,
Galapo.

Yep, I agree. Longhorn ntldr is a no-go license-wise. Which is unfortunate because of the functionality it has: a) increased memory limit; and b) automatic HAL detection and swap.

Wouldn't it be great if MS made the file legally downloadable for use with XP or whatever you wanted! But I doubt they'll show generosity in this way.

Regards,
Galapo.

I'm not sure he said he was using pirated OS. Only issue is Longhorn's ntldr. Chinese sites were first to list details of how that version of ntldr can do automatic HAL detection and switch on each boot for XP (instead of using all those boot.ini entries you commonly see). Once Longhorn progressed to Vista, boot manager has developed more so that it is no longer backwards compatible.

EDIT: I see mention of ghost images -- not good...

Regards,
Galapo.

JakeLD wrote:

What's the point of integrating graphic drivers into PE ? You plan playing Call Of Duty on PE or what ? LAN, Chipset and Mass covers everything needed for emergency CDs.

I agree. I've always been satisfied with just default vgasave device myself in PE.

But others use their PE more as a portable temporary replacement OS. %SystemDrive% can be writable with File-Based Write-Filter or SDI (or alternatively even a RAW disk) ram-booting image.

WinBuilder nativeEx project has explorer as shell sized in ~60-70mb. Functioning control panel and device manager allowing installation of drivers.

It is conceivable, then, that some might desire to include graphics drivers. Of course, I do not at all mean that the original poster was in any way justified with his demands! Just trying to think why someone might want to do this.

Regards,
Galapo.

Could also try:

http://www.vnunet.com/vnunet/downloads/ … manager-se
http://kb.paragon-software.com/paragon/ … ct_id=3804

I can supply you with a BartPE plugin or WinBuilder script if you so desire.

Regards,
Galapo.

70

(41 replies, posted in Universal Imaging)

Generally developers do not like documenting and writing help files. And this is true of OfflineSysPrep. It assumes familarity with the processes it provides a "front-end" for. Development is done in my spare time, which is limited, and so help file stuff is limited because it is not fun to do. I'm sorry, I wish I had more time.

Generally, the error that you got is due to using some other program named "runscanner" rather than the one that should be used from here.

Hope this helps.

Regards,
Galapo.

I'm not sure as I don't have that hardware to test.

But what I do know is that I've been testing for the next release of Driver Import PE and it works well for my SigmaTel audio device. Before there was manual steps necessary such as copying INI files to a particular path (different for different SigmaTel drivers, though) under %ProgramFiles%. Now it is just a one click install, either from offline host, driver INF, or DP .7z pack.

Regards,
Galapo.

72

(41 replies, posted in Universal Imaging)

Congratulations on the new release! And Merry Christmas and happy New Year to you also. My holiday was great, we even had baby sitting at times since my parents also rented a unit in the same block as us! I hope you get a relaxing break some time too.

Regards,
Galapo.

73

(41 replies, posted in Universal Imaging)

Thanks for the report.

Sorry for the delay -- I've been on holidays and away from internet access. The latest BartPE plugin and WinBuilder scripts now contain an updated CreateMassStorageData.exe which should fix the issue (providing Overflow doesn't alter the location of MassStorage.inf again).

Also, I've updated the LiveXP mass storage driver script for the same issue in case a user supplies a newer BASE.

Regards,
Galapo.

74

(41 replies, posted in Universal Imaging)

A while ago I promised Overflow that I would post a topic about OfflineSysPrep.

OfflineSysPrep is basically a gui-frontend for Microsoft's sysprep.exe, which allows sysprepping from PE upon an offline XP\2k3 system. Various additional tasks can be performed such as stopping Intelppm service, injecting DP mass storage drivers, specifying HAL, etc.

More info here: http://www.911cd.net/forums//index.php?showtopic=22064

BartPE plugin and WinBuilder scripts exist. Of course, WinBuilder script is the more advanced and automatic option, and comes by default with LiveXP.

Regards,
Galapo.

Jaak wrote:

XP SP3 suffered, imho, in that it did not get the full 2008 WIM.

No, but you can now do-it-yourself: http://pantherxp.net/

Regards,
Galapo.