Question regarding sysprep

Soldato
Joined
17 Jan 2007
Posts
8,944
Location
Manchester
Hi,

I was going to post this in the Windows forum but I thought it would be much more likely that you guys in here might know.

Basically I have a few PCs with varying hardware to rebuild - around 12 - which might not sound a lot but I have roughly 100 bits of software to install on each so anything that will speed up the process will help.

The question boils down to: if the HAL is the same, will a sysprep image work across machines with different hardware? The main differences between the machines with the same HAL are varying integrated graphics chipsets, hard disk capacity and amounts of RAM.

So, if I:

  • Install a clean copy of XP
  • Patch it up to date, install all the required bits of software but no specific hardware drivers
  • Run the latest version of sysprep and clone the disk image with Clonezilla
  • Stick the image on a machine with, say, Ati graphics instead of Intel
  • Boot

Is this going to work? I have had a look online but I kinda get different answers, clouded further by the many products out there advertising "deploy on different hardware" as a selling point which makes me think that it is not as straightforward as it seems. I know I'll have to install the specific hardware drivers on a per-machine basis but that's not a problem.

I suppose one answer would be "just try it" but I'd rather not waste my time if someone could give me a definitive "no" or "yes, but you might have problems x, y and z". Any tips appreciated.

Cheers. :)

P.S. I know about Acronis universal deploy etc. but I'd like to know whether it is possible with sysprep. Thanks.
 
It will work, if all the IDE/SATA controllers/chipsets are the same. It sounds like this is not the case however.

There are better ways of doing this, there is a piece of software that "records" what happens when you install software, registry, files etc etc then packages it all into one single MSI installer package. I've had varying results with it but it might of come a way since I last used it, 100s does sound like a lot though.

I cannot for the life of me remember the name of the software but I will try dig it out, perhaps one of the other guys here knows.

Sysprep does not do much "special" It resets the SID and allows you to re-enter specific information to make the machine unique.
 
Thanks for looking into it.

If the SATA controllers and chipsets are different will it just fail to load, or will it boot but behave strangely/be unstable in use? The latter is what I'm hoping to avoid - I'm rather it just refused to boot than lull me into thinking it's working. :D
 
There are better ways of doing this, there is a piece of software that "records" what happens when you install software, registry, files etc etc then packages it all into one single MSI installer package. I've had varying results with it but it might of come a way since I last used it, 100s does sound like a lot though.

I cannot for the life of me remember the name of the software but I will try dig it out, perhaps one of the other guys here knows.

Loads of packaging apps out there, Wise Package Studio is a popular one.

However I'm not a fan of repacking using a watched/recorded install, much rather automate the standard provided installer.

I use a couple of apps when packaging stuff, most of my packages use the original manufacturers installer but with an SMS Installer (an old MS app that you got the rights to use with SMS) script as a wrapper.

So the SMS installer script will run say an msi with the correct command line, and then it'll do anything else I need it doing :)

Also use Orca to tweak things and very very rarely I'll use Wise Package studio if I need to create an MSI from scratch.
 
Last edited:
It will work, if all the IDE/SATA controllers/chipsets are the same. It sounds like this is not the case however.

<snip>

Sysprep does not do much "special" It resets the SID and allows you to re-enter specific information to make the machine unique.

Providing it boots, can I not just install the chipset drivers specific to that machine over the top? As I say they are all HP boxes and I can get the drivers online no problem.
 
If you do a vanilla build, install software etc and make sure not to install any drivers then a sysprep should be fine; have you looked into Windows RAS over PXEBOOT (providing your machines have it)?
 
If you do a vanilla build, install software etc and make sure not to install any drivers then a sysprep should be fine; have you looked into Windows RAS over PXEBOOT (providing your machines have it)?

I've just had a look at RIS (you do mean RIS, right?) and it looks good but might be just a tad overkill for a small number of machines, and off the top of my head I'd guess that 1/3 of the machines don't have a compatible ethernet adapter. I'll definitely look into it in future when I have time and maybe some spare hardware to test, but I don't want to start going down a road that might take me more time than I have budgeted for.

I did think about just deploying the software via group policy, but I quickly came to the conclusion that it wasn't a great option due to the lack of .msi installers. Also, a few pieces require a bit of tweaking to run under a limited user account which I would have to do afterwards. I get the impression this is much easier to do with Vista, but unfortunately this isn't an option at the moment.

If you seem to think I'll be okay with a vanilla sysprep I'm definitely going to give it a go. If all else fails I can just do it manually (and take an image for that machine so I don't have to do it again!) I'm pretty new to sysadmin so it's a constant learning process at the minute.

Some are AMD single core, some are AMD X2s and some are Pentium Dual Cores so I'm going to be doing 3 manual builds as it is - just wanted to see if I could cut a couple of corners so to speak.

Cheers and I'd be glad to hear if anyone else has any input. :)
 
Providing it boots, can I not just install the chipset drivers specific to that machine over the top? As I say they are all HP boxes and I can get the drivers online no problem.

I would be very surprised if it boots. Most likely it will get to the windows loading screen then reboot.

You may be able to get away with this if you create a custom Windows XP CD slipstreamed with every SATA/IDE controller you have in your batch of PCs.
 
Do you have the room/capacity to dump all 100 onto the network heedlessly and broadcast keystrokes to all of them over the network?

I've broadcasted to 30 machines on a physical KVM before, might be worth considering :p
 
I havnt read the whole thread, but yes it is possible, across multiple HALs, different processor types and different drive controllers.
Requires a bit of sysprep faffing and some bootup commands to work though iirc.
 
I havnt read the whole thread, but yes it is possible, across multiple HALs, different processor types and different drive controllers.
Requires a bit of sysprep faffing and some bootup commands to work though iirc.

Got any documentation on this?

Would be very interested in a read myself.
 
Got any documentation on this?

Would be very interested in a read myself.
Im not at work at the moment, but i'll remote in later, see if i can dig out what we have on the subject.
It was actually devised by the other techie at our place, he did a cracking job with it tbh.:).
 
I'd be very interested as well. Currently looking at either stick with FOG or moving to WDS/SCCM for our image deployment, but would love to do hardware independent imaging :)
 
I might pop into work early next week, but just to note, its not hardware independent as in, detects everything on every hardware:
It'll fully install every driver for a platform if said driver has been slip-streamed into windows, and then every other system that its imaged to, it'll just have the base windows install with basic drivers. But will still run.
So still far better than normal imaging. lol.
 
A lot of information follows, this has been gleaned from many an hour of swearing, but the end result is absolutely worth it.

We use Novell ZENWorks for our imaging and have leveraged some of the functions to carry out scripted hardware independant imaging.

if your imaging software supports pushing down extra files after an image is applied, you're laughing.

We've added the following to our sysprep.inf:
OemPnPDriversPath="Drivers\WinXP\Video;Drivers\WinXP\Audio;Drivers\WinXP\Network;Drivers\WinXP\USB;Drivers\WinXP\SYSTEM;Drivers\WinXP\wnic;Drivers\WinXP\modem;Drivers\WinXP\mouse;Drivers\WinXP\monitor;Drivers\WinXP\keyboard;Drivers\WinXP\other;Drivers\WinXP\other2;Drivers\WinXP\other3;Drivers\WinXP\other4;Drivers\WinXP\other5"

Which basically means it will search for additional drivers in c:\drivers\winxp\video, c:\drivers\winxp\audio c:\drivers\winxp\Network etc.

So in ZENWorks jargon, you create a base add on image with all those folders, and save it as your template.
Then for each different model open that template, copy in the driver files you need (The cat and inf files etc, not an exe file) and save it with the model name.

We have then scripted it to push down our base image, check the model of the PC via WMI and push down the according model driver file.
You don't have to script it, it can be done manually, but I like to remove any process that requires thought.

One thing you absolutely need to do when you sysprep your base machine, regardless of your imaging software, is add the following to the end of sysprep.inf:
[SysPrep]
BuildMassStorageSection=Yes

[SysprepMassStorage]

Then run "sysprep -bmsd", this is going to take a while, but it will basically push all of the mass storage controllers into your image, meaning that provided windows has the drivers, the machine you image to is going to boot.
Check the sysprep.inf file after it's finished, you should find the [SysprepMassStorage] section has a ton of new entries.

The issue with that is that any machine you image will now have all those drivers, and to avoid performance issues they need to be removed.

We tend to put the sysprep files being used in c:\sysprep, so the example below assumes that. The file location is set in sysprep.inf as 'InstallFilesPath=C:\sysprep\i386'

Create folders c:\sysprep\i386\$OEM$, and in the $OEM$ folder create a file 'cmdlines.txt'.
In this file add:
[Commands]
"C:\Sysprep\Sysprep -clean"

This will ensure the machine is cleaned up afterwards.

I would also advise taking images as you go through the process, 1 for when windows is installed, 1 for it being patched, 1 for AV/Firewall install. If you have as many apps as you say, then probably 1 every few apps. Nothing is going to be worse than wrecking an install and losing hours of effort.

Ask if you have any questions, I still have the mental scars from doing all this, so should be able to clarify anything.
 
Last edited:
Cheers for all the input. I've been on holiday this week but was sad enough to take my Server 2003 manual and did a bit of reading on RIprep, the RIS flavour of sysprep which is apparently much less sensitive to hardware changes than sysprep. I wish I'd known about this earlier because I don't have time to test it out, but one for the future!
 
Hi everyone,

Well I'm about half way through what I need to do using the sysprep method. It has worked a treat on about a third of the machines but the rest are a total nightmare. Basically I'm having loads of problems such as: http://support.microsoft.com/kb/320279 and the system hanging when reaching the welcome screen. This happens even after I try to boot the master machine after running sysprep (no disk cloning involved i.e. literally the same hardware)!

Anyway, I'm trying to think outside the box a little and wondered if this would work. Basically I don't bother with sysprep at all and just clone the image to the other machines. Once this is done, I'll change the computer name and run newSID (http://technet.microsoft.com/en-us/sysinternals/bb897418.aspx) Will this work? Is there anything I'm overlooking?

I'm going to try it tomorrow anyway. ;)
 
I would also advise taking images as you go through the process, 1 for when windows is installed, 1 for it being patched, 1 for AV/Firewall install. If you have as many apps as you say, then probably 1 every few apps. Nothing is going to be worse than wrecking an install and losing hours of effort.

Oh, and this is good advice. I'm so glad I took an image of basically 6.5 hours work before sysprep killed it. The joys. :D
 
FYI the clone and then running newSID worked very well (identical hardware of course, if forgot to point that out a couple of posts up) which might be useful to know. It was quicker too.
 
Back
Top Bottom