Quick question of Independent XP Images

[Lithium]

Hi all,

 

I'm trying to save myself some work by creating a hardware independent XP image in the time we wait before going to Vista.

 

I read lots of the only major issue being the HAL... Which Hal's are validly changeable by copying/replacing files?

 

Can I change freely ACPI Uniprocessor HAL and ACPI Multiprocessor HAL's? or is it some other types that can be changed to one of these two?

 

I can't find the original topic I read it all in on google

[GlennT]

Have you had a look at Acronis?

They do a product with "Universal Restore" which basically enables you to put an image created on one machine onto a machine with completely different hardware.

Have a look here..... http://www.acronis.com/enterprise/products/ATISWin/universal-restore.html

[srochford]

The HAL isn't much of a problem now - it used to be when you could have a mix of ACPI and non-ACPI machines.

 

The problem for us is chipsets and hard drive controllers. For example, if we make a machine on a latop with AMD chip and chipset then that will work on an Intel machine but the reverse isn't true.

[djones]

Just been through this myself. There are a number of options but the one I settled on was using MySysprep to automatically change HAL before mini-setup runs.

 

However, as Steve says, the more significant issue is mass storage devices and drivers - this is what took me a while to get right. I've written up a few guides (cobbled together from a variety of sources) for creating and then deploying hardware independent XP images using WDS. Even if you're not going to use WDS for deployment, the principles for creating the images (sysprep.inf files etc) are the same.

 

My guides are available here:

 

http://www.midteq.co.uk/index.php?option=com_content&task=blogcategory&id=36&Itemid=68

 

Dave.

Edited February 13, 2008 by djones

[DMcCoy]

I created my image (just the one) on a virtual machine with using the single processor acpi HAL. After the first boot windows changes the hal on my core2s to multiprocessor, needs an extra reboot but it does this during some post install steps anyway. I added the mass storage devices to the sysprep.inf so that board types are not an issue (works on all my desktops - not so for laptops yet).

 

Drivers are added to sysprep drivers folder when I get a new machine type in, I usually do some customisation of the driver inf files to remove all the startup junk, context menu entries etc.

[googlemad]

Change the IDE controllers in device manager to Standard ones before you image (Using update driver).

 

Works 9 times out of 10 for me

[Sirbendy]

Here's how I do it, and I've yet to have it fail on desktop or laptop.

 

Install XP, install your apps etc, get the whole shooting match fettled to your taste.

 

Then go into device manager, click "Computer", and update driver. select to pick your own, and then pick "Standard PC". Let it reboot and do all the "redetect hardware" jazz.

 

At this point you have an utterly non-ACPI setup. Basic of basic. Will boot and run on anything at all. Create your Sysprep.inf (or copy it over if you already have it).

 

Make sure in there is this section:

 

[unattended]

OemSkipEula=Yes

UpdateUPHAL=ACPIPIC_UP,%systemroot%\inf\hal.inf

InstallFilesPath=C:\sysprep\i386

TargetPath=\WINDOWS

 

The "UpdateUPHAL" line is the important one. It tells Sysprep that on completion of deployment, it's to go and use the most suitable HAL it has.

 

After doing this alteration, start up command prompt, and go to the sysprep directory. Type "Sysprep -bmsd" to build the mass storage driver list.

 

Copy any machine specific drivers to the designated directory you specify, then disable swap file, nuke hibernate and clear down sys restore etc, reboot.

 

Once it comes back up, I fire up Sysprep and Reseal. Then ghost it once Sysprep is done.

 

This has seen me through the last 2 0706 and all my new 0707 revision builds, deployed on Intel and AMD, Single or Multicore core, P2 through to X2/C2D, all without issue.

 

I just wish the LEA would pick up on it..heh..their builds were often failing to boot on certain hardware types, and they used to release different images for different hardware.

 

My 0707 R4 build beats theirs to login by 30 seconds, runs a hell of a lot faster/smoother, and comes in at just under 2gb ghost size..their 0707 release to "non-own build" schools comes in at 6. We'd never go back now.

Edited February 13, 2008 by Sirbendy

[srochford]

Change the IDE controllers in device manager to Standard ones before you image (Using update driver).

 

Works 9 times out of 10 for me

 

I can do 9 out of 10 - what I want is 10 out of 10

[djones]

Before using MySysprep, I found that I could get the HAL to change to 'Advanced Configuration and Power Interface (ACPI)' on everything I tried it on (laptops and desktops) but not reliably change to 'ACPI Multiprocessor PC' or 'ACPI Uniprocessor PC' as appropriate.

 

In terms of the IDE drivers, I just had to make sure I had the correct Device IDs (inc. correct revisions specified) listed in sysprep.inf and obviously the appropriate drivers and it now works 10/10 on everything we have.

 

I do have two issues remaining though:

 

1. On first boot after deployment, the 'SCSI/RAID Host Controller' tries to install but fails. If I then uninstall it via the Device Manager and reboot, it installs correctly without a problem.

 

2. I created the image initially using our slowest/oldest machine which happened to be a laptop. (I will be moving to using VMWare in the future.) Unfortunately, I forgot about power management settings so when I deploy to desktops, I have to change the default settings to 'always on' on first boot. Is there a way round this?

 

Dave

[Lithium]

Is there a way of specifying the computer name for sysprep to use?

[djones]

Is there a way of specifying the computer name for sysprep to use?

 

You can specify the machine name in the [userData] section of the sysprep.inf file as follows:

 

[userData]
   ComputerName= 

 

If you pre-stage the computers within AD, I think you can use the %machinemane% variable to automatically select the correct name.

 

If you want/need more advanced naming schemes, MySysprep will also accomplish this relatively easily as follows:

 

[userData]
;This is a special added feature that comes with MYSYSPREP - more details here. 
;You can have your PC named by its serial number (%SerialNo%) or assest tag (%AssetTag%), for example, as shown below. 
   ;ComputerName=Something%SerialNo%
;If left blank, the user will be prompted for a computer name during Mini-Setup.
   ComputerName= 

 

For more advanced naming schemes check the MySysprep instructions.

 

Dave.

[djones]

The problem for us is chipsets and hard drive controllers. For example, if we make a machine on a latop with AMD chip and chipset then that will work on an Intel machine but the reverse isn't true.

 

From another forum:

 

The intel service 'intelppm' runs on Intel machines so to make an image work on both Intel and AMD based machines you would have to disable that service during mini-setup with:

 

sc.exe config intelppm start= Disabled 

 

Dave.

[Lithium]

I was thinking more along the lines of (RM networks?) typing in the computer name when it starts mini-setup... I'm sure I spotted that you can do that...

 

Square brackets?

[djones]

Yeah, this is what I currently do. I have...

 

[userData]

ProductKey=****-***-***-***-****

FullName=" "

OrgName="My Organisation"

ComputerName=

 

...in my 'sysprep.inf' file which, when mini-setup runs, prompts me to specify a computer name (or accept the default randomly generated one) before joining to the domain and completing. This is the only thing that is prompted.

 

The first time I embarked on all of this, I created (unmanaged) computer accounts in the correct OUs in AD for all the machines in the network. This ensures that the machines get joined to the domain in the correct OU from the outset so that they pickup any GPOs/scripts etc from first boot.

 

Dave

[srochford]

 

1. On first boot after deployment, the 'SCSI/RAID Host Controller' tries to install but fails. If I then uninstall it via the Device Manager and reboot, it installs correctly without a problem.

 

2. I created the image initially using our slowest/oldest machine which happened to be a laptop. (I will be moving to using VMWare in the future.) Unfortunately, I forgot about power management settings so when I deploy to desktops, I have to change the default settings to 'always on' on first boot. Is there a way round this?

 

Dave

 

1. Are you putting Daemon Tools on the image - if so, we run this as part of the machine startup:

 

    sCmd="\\server\share\devcon\i386\devcon.exe remove ""ACPI\PNPA000"""
   oShell.run sCmd,,true
   wscript.sleep 5000
   sCmd="\\server\share\devcon\i386\devcon.exe rescan"
   oShell.run sCmd,,true

 

- this removes the device and then does a rescan. Devcon is an MS download (and very useful!)

 

2. powercfg is your friend:

 

  sCmd="powercfg /setactive ""home/office desk"""
 oShell.run sCmd

- choose your power saving scheme as appropriate.

 

(both are script fragments - you need

set oShell=createobject("wscript.shell") 

somewhere at the start)

[djones]

1. Are you putting Daemon Tools on the image - if so, we run this as part of the machine startup:

 

- this [script from previous post] removes the device and then does a rescan. Devcon is an MS download (and very useful!)

 

Bingo bongo! That may be the ticket - I'll check next week.

 

2. powercfg is your friend:

 

  sCmd="powercfg /setactive ""home/office desk"""
 oShell.run sCmd

- choose your power saving scheme as appropriate.

 

(both are script fragments - you need

set oShell=createobject("wscript.shell") 

somewhere at the start)

 

Yeah, I'd thought this would be the answer but my scripting skills are not great and I couldn't find any suitable examples when I searched. Thank you!

 

Dave.

[Lithium]

Ok, I took my image for a trial today... and several things happened.

 

1. When I used the Standard PC HAL, I couldn't use ANY pointing devices - not even a COM mouse... so I had to work out where all the hal files were since Microsoft don't update their site to move from drivers.cab\halmacpi.dll to sp2.cab\halmacpi.dll...

 

2. After getting it back, I forgot to use a uniprocessor HAL, so it wouldn't go on half the PC's...

 

3. I forgot to omit computername in the inf so that it would (hopefully) ask me for it.

 

4. none of my drivers installed

 

5. I suspect there's slightly more to it than just extracting the Dell Rxxxxxx.exe's to C:\Dell\drivers and pointing OEMPnPDriversPath to these folders....

 

 

On the other hand, it went on the same spec machines happily, I just had to go around and install the NIC drivers, push netsupport to them, then use NSS to run the driver install wizards

 

Bring on Vista! then I won't have to smash something

[djones]

Ok, I took my image for a trial today... and several things happened.

 

4. none of my drivers installed

 

5. I suspect there's slightly more to it than just extracting the Dell Rxxxxxx.exe's to C:\Dell\drivers and pointing OEMPnPDriversPath to these folders....

 

On the other hand, it went on the same spec machines happily, I just had to go around and install the NIC drivers, push netsupport to them, then use NSS to run the driver install wizards

 

When you extract the Rxxxxx.exe downloads from Dell, you should end up with a folder containing a series of files and folders as shown in the first attached screenshot.

 

One of these folders will be named WinXP or similar and in there will be the '.cat', '.inf', and '.sys' files as shown in the second screenshot. These are the only files that are usually required for unattended installation.

 

I place these files in a folder such as C:\Drivers\Dell\GX520\NIC and specify the same path in the 'OEMPnPDriversPath' section of my sysprep.inf file so that I end up with:

 

OemPnPDriversPath=Drivers\Dell\755\Chipset;Drivers\Dell\755\Audio;Drivers\Dell\755\Modem;Drivers\Dell\755\Video;Drivers\Dell\755\NIC;Drivers\Dell\D505\Chipset;Drivers\Dell\D505\Audio;Drivers\Dell\D505\Modem;Drivers\Dell\D505\Video;Drivers\Dell\D505\NIC;Drivers\Dell\D510\Chipset;Drivers\Dell\D510\Audio;Drivers\Dell\D510\Modem;Drivers\Dell\D510\Video;Drivers\Dell\D510\NIC;Drivers\Dell\D510\Wireless;Drivers\Dell\D520\Chipset;Drivers\Dell\D520\Audio;Drivers\Dell\D520\Modem;Drivers\Dell\D520\Video;Drivers\Dell\D520\NIC;Drivers\Dell\D520\Wireless;Drivers\Dell\GX520\Chipset;Drivers\Dell\GX520\Audio;Drivers\Dell\GX520\Modem;Drivers\Dell\GX520\Video;[b]Drivers\Dell\GX520\NIC[/b]
   InstallFilesPath=C:\
   ConfirmHardware=No
   OverwriteOemFilesOnupgrade=No
   DriverSigningPolicy=Ignore
   oempreinstall=yes
   updateInstalledDrivers=Yes 

 

Sysprep will not recursively search subfolders so you must copy all required files into the top level folder you have specified in 'OemPnPDriversPath'

 

Dave.

[Lithium]

If I have InstallFiles pointing to C:\sysprep...

 

Where I specify in OEMPnP... Will it make it C:\Sysprep\Drivers\Dell\745\NIC ?

 

or something else?

[djones]

Yes, you would obviously then need to place the 'Drivers' folder under the 'sysprep' folder as you have said.

 

Your 'sysprep.inf' would look something like this:

 

OemPnPDriversPath=Drivers\Dell\745\NIC
   InstallFilesPath=C:\sysprep
   ConfirmHardware=No
   OverwriteOemFilesOnupgrade=No
   DriverSigningPolicy=Ignore
   oempreinstall=yes
   updateInstalledDrivers=Yes

 

*** Note the absence of the 'C:\sysprep\' part in the OEMPnPDriversPath ***

 

However, I tried to do this first too thinking that as the 'sysprep' folder would be automatically deleted, it would tidy things up nicely. Unfortunately, not all my drivers appeared to be installing in time or needed the first reboot to happen completely which, as mini-setup deleted the 'sysprep' folder, caused a few issues. I'm not sure whether this was actually the problem but once I had moved the 'Drivers' folder to the root of the drive and specified 'InstallFilesPath=' as 'C:\' everything seemed to go swimmingly.

 

Dave.

Edited February 17, 2008 by djones

[robbie-w]

I am trying this on a single core laptop Toshiba L10 and then imaging to a Lenovo N500(multicore). It gets stuck straight after the windows bootloader i.e. where safe mode is. No hdd activity or anything just a black screen

 

At a bit of a loss on this one. Laptops drive is in IDE mode and not AHCI. Are the HAL's supposed to be copied to the disk somewhere? I put them in various other files in sysprep/i386

 

Any ideas?

 

Robbie

 

Here's how I do it, and I've yet to have it fail on desktop or laptop.

 

Install XP, install your apps etc, get the whole shooting match fettled to your taste.

 

Then go into device manager, click "Computer", and update driver. select to pick your own, and then pick "Standard PC". Let it reboot and do all the "redetect hardware" jazz.

 

At this point you have an utterly non-ACPI setup. Basic of basic. Will boot and run on anything at all. Create your Sysprep.inf (or copy it over if you already have it).

 

Make sure in there is this section:

 

[unattended]

OemSkipEula=Yes

UpdateUPHAL=ACPIPIC_UP,%systemroot%\inf\hal.inf

InstallFilesPath=C:\sysprep\i386

TargetPath=\WINDOWS

 

The "UpdateUPHAL" line is the important one. It tells Sysprep that on completion of deployment, it's to go and use the most suitable HAL it has.

 

After doing this alteration, start up command prompt, and go to the sysprep directory. Type "Sysprep -bmsd" to build the mass storage driver list.

 

Copy any machine specific drivers to the designated directory you specify, then disable swap file, nuke hibernate and clear down sys restore etc, reboot.

 

Once it comes back up, I fire up Sysprep and Reseal. Then ghost it once Sysprep is done.

 

This has seen me through the last 2 0706 and all my new 0707 revision builds, deployed on Intel and AMD, Single or Multicore core, P2 through to X2/C2D, all without issue.

 

I just wish the LEA would pick up on it..heh..their builds were often failing to boot on certain hardware types, and they used to release different images for different hardware.

 

My 0707 R4 build beats theirs to login by 30 seconds, runs a hell of a lot faster/smoother, and comes in at just under 2gb ghost size..their 0707 release to "non-own build" schools comes in at 6. We'd never go back now.

Edited April 24, 2009 by robbie-w