Quad-Damage wrote:

Is there any way to host you program and run the whole thing in windows? By copying the  under windows and run the same program in a PE with a system viewer program.

I have no idea what a "system viewer program is". But anyway, it is indeed possible to run OfflineSysPrep under windows/locally so long it is pointed to an offline/non-booted system (attached drive or mounted image etc.). You could use the 'UnderWindows' folder as a base to gather what is necessary. The preferrable option would be to use the LiveXP script and select the 'Output' option. This will automatically gather everything that's needed, build the mass storage database, and output to the 'temp' folder in your WinBuilder directory. Here's an image of the button to click on the script:

http://img688.imageshack.us/img688/6971/20100129142130.png

I really just want to use your program to inject mass storage devices, the -bmsd is not cutting it for me.

If you need to use -bmsd, then do this prior to using OfflineSysPrep. Run it under the booted system, sysprep.inf [SysprepMassSorage] will be populated. Then run sysprep as normal to inject the entries into the registry. Reboot to PE or whatever and then run OfflineSysPrep to inject DriverPacks mass storage drivers etc.

I know what I need to do to get OfflineSysPrep to mimic the -bmsd function so that option would be possible, but I need the time and desire to code it.

Anyway, hope this helps.

Regards,
Galapo.

I have no idea about the Runscanner error. Too many unknown variables with BartPE, I haven't used it for a few years. I use LiveXP these days: http://winbuilder.net/download.php?view.35. I'm not sure of the package which downloads includes OfflineSysPrep by default. If not, it'll be in the list of options to download through the WinBuilder download centre when updating LiveXP.

Regards,
Galapo.

@Quad-Damage
Very interesting that cmdlines.txt can be used to correctly set HAL. If incorrect HAL was set to a deployed machine, I'd get continuous reboot before mini-setup. At least that's what I remember. I'll have to test this cmdlines.txt suggestion sometime!

Regards,
Galapo.

See here for details on building a reference image, also a good method of deployment: http://pantherxp.net/

Regards,
Galapo.

markhodgeNZ wrote:

Which brings back the reboot loop sad

I would say you've got an issue with your image, not necessarily with injection of mass storage drivers.

markhodgeNZ wrote:

Has ANYONE here managed to get Offline Sysprep working?

Yes, I have. ilko has who did numerous tests for me for the HAL development. Like I said, it may be a problem outside of the mass storage drivers.

markhodgeNZ wrote:

Could you post your Sysprep.ini file, user_settings.ini file, and what steps you used?

My working settings are as in the supplied download. Of course, I replace ntldr. But my guess is that if you were to do that, you may find the reboot sequence happening again anyway.

Regards,
Galapo.

ntfs.sys error is due to memory breach. You either need to update ntldr from 64-bit xp etc. or inject fewer drivers (see the user_settings.ini file to do this).

Regards,
Galapo.

markhodgeNZ wrote:

1. Run OfflineSysPrep-v1.10.0.7\UnderWindows\OfflineSysPrep.exe
2. Select the Windows partition of your offline Windows partition.
3. Under Select User Profile, selected administrator                                    -    (for what? default user? doing something specific?!?)
4. Select AUTO configuration under Select HAL update option                      -    (okay for ACPI Uniprocessor source to ACPI Multiprocessor target?)
5. Click Apply.
6. Sysprep:

I see no steps where you injected mass storage drivers. Click 'Advanced' on the OfflineSysPrep interface and select desired option, in your case probably 'Install all DriverPacks non-IDE mass storage Device(s)'.

Regards,
Galapo.

markhodgeNZ wrote:

I didn't actually notice any documentation/directions as such included with OfflineSysprep.

Please look a little harder, viz. at the OfflineSysPrep.htm file.

Regards,
Galapo.

Thanks again. I'll add to the program. Hopefully issue of setting correct HAL at boot is now solved.

Regards,
Galapo.

Great, thanks for that.

Any idea about determining the setting of standard HAL vis-a-vis ACPI PC HAL?

Thanks,
Galapo.

36

(41 replies, posted in Universal Imaging)

Commandline should be coming in version 2. thecharliec is still coding the alpha version.

Regards,
Galapo.

37

(41 replies, posted in Universal Imaging)

I could do that. But only in a couple of weeks after we've moved. My wife would kill me if she found out I was doing hobby programming instead of packing!

Regards,
Galapo.

38

(41 replies, posted in Universal Imaging)

Those kind of tests would be very helpful indeed.

Thanks,
Galapo.

39

(41 replies, posted in Universal Imaging)

I wish I had hardware to test and then I could improve it. I would like to know of a way to detect whether a system supports acpi but not acpi uniprocessor. Probably this would then solve most of your issues. Then I would like a way to detect whether a system supports acpi and if not default to standard (I guess I don't care about the Compaqs).

I'm running fast out of time to do much. A work situation has arisen requiring my family to move house over 1,000kms away at short notice. That's in 9 days time -- and we only found out yesterday!

Regards,
Galapo.

40

(41 replies, posted in Universal Imaging)

Difficult to know what was the glitch. Seems like it wasn't to do with the HAL injection, since the issue occurred without it.

I'd be curious to know if it also happens if you let sysprep run, reseal, and let the system boot through mini-setup.

Regards,
Galapo.

41

(41 replies, posted in Universal Imaging)

Likely the issue is to do with the HAL. OfflineSysPrep auto HAL detection on first boot only works with acpi uniprocessor and acpi multiprocessor machines.

Regards,
Galapo.

42

(41 replies, posted in Universal Imaging)

The w2k code was unfortunately removed quite a while ago. It's still there in that older version, which I could revisit if there was a need and add support into the newer version. What would do it for me I guess would be if my w2k machine packed it in and I had to upgrade the motherboard ... but I hope that doesn't happen!

If I get some time later in the year I can revisit the issue though.

Regards,
Galapo.

JakeLD wrote:

Me and bro eXoRt will test it for you. big_smile

Thanks. Hopefully you'll find it working as expected.

Regards,
Galapo.

kickarse wrote:

Galapo, does your program work with LiveXP and all its variants?

Yes, that's all I use it with these days. I haven't fired up pebuilder for two years now.

Regards,
Galapo.

kickarse wrote:

Galapo, could you add an option to mount a VMWare image and use that for the target?

I guess I could but I don't really see the point. If one wants to use a VMWare image, then it should be up to the user to have the image mounted, and it's not difficult. There's various ways of doing so: either with VMWare's own supplied program, or vdk.exe, or ImDisk, etc.

New version is out also. Changes to OfflineSysPrep:
· Options which are run on first boot (driver-signing supression, generating new SID, auto HAL update) are now stored in case of re-running OfflineSysPrep before first run and when OfflineSysPrep starts the second (or third etc.) time then these options are selected by default if originally selected
· Original setup commandline is replaced if re-running OfflineSysPrep before first run

Regards,
Galapo.

kickarse wrote:

Also, there's the PantherXP way of doing it, injecting drivers into a WIM. The guy is on the boot-land.net forums.

The HAL and driver injection routines of PantherXP I am quite familar with because I was involved with developing those functions and testing.

llewxam wrote:

Question Galapo, is it OK to run OSP after it has already been run on the same image?

Yes, that's fine. Caution with the "auto boot" HAL option and driver-signing options: if you re-run those again there will be issues. I'll work on a fix.

Regards,
Galapo.

I've again released a new version.

Changes to OfflineSysPrep:
· Added Advanced option to generate new SID
· Removed some registry writes and added some deletions so as to avoid multiple HALs being listed in Device Manager
· Fixed bug introduced in two previous versions with manually setting HAL to ACPI Muilti-processor
· Fixed spelling mistake on Advanced gui
· Fixed bug introduced in two previous versions with OfflineSysPrep.inf

Regards,
Galapo.

There is a way that allows for automatic HAL detection with XP/2003 on every boot same as Vista: http://www.msfn.org/board/index.php?sho … p;p=532799

Unfortunately, would seem to break licensing agreement. Darn, because that method would be ideal.

Regards,
Galapo.

kickarse wrote:

So, now, basically we run OSP on a live system, turn the machine off, capture the image, then deploy the image, turn the newly deploy workstation on?

You've got a number of options:

1. Sysprep drive; shutdown; boot to PE; run OSP with "auto boot" HAL option; create image; deploy image; start new system.

2. Sysprep drive; shutdown; connect drive to another system; run OSP with "auto boot" HAL option from the other system; create image; deploy image; start new system.

3. Shutdown; boot to PE; run OSP with "auto boot" HAL option and also sysprep option; create image; deploy image; start new system.

4. Connect drive to another system; run OSP with "auto boot" HAL option and also sysprep option from the other system; create image; deploy image; start new system.

Regards,
Galapo.

kickarse wrote:

I'm happy I was able to help the infamous Galapo! big_smile

I'm greatful for the time you took to research and post. I hadn't tried devcon because I thought a complete shutdown was what was needed. However, just a "devcon reboot" was. But even though devcon doesn't actually make a reboot under the limited conditions, it nevertheless must get something working because when the shell closes, the reboot is different to the one without having run the devcon command.

I would love to test it out, I would love to see the process behind the scenes too.

Well, it's basically just refreshing the files you mention here: http://forum.driverpacks.net/viewtopic. … 819#p29819. Then writing corresponding registry entries.

Note: my "auto boot" method is only for acpi uni- and multi-processor machines. Setting another type of HAL can as yet only be done with "auto" and "manual" methods, not "auto boot" method. In other words, from PE environment I can work out when to use uni-processor HAL and when to use ACPI, but I can't work out how to make this differentiation at first boot under the specific conditions imposed. Maybe it doesn't matter. Mysysprep only works with acpi uni- and multi-processor machines as well as far as I know.

Regards,
Galapo.