Here is the documentation I promised that outlays how to use KiX to supplement and enhance Sysprep images. I put it here, as opposed to the FAQ so that people would feel free to comment and add their scripts/experiences to the knowledgebase.

Why Sysprep?The process of deploying computers can be a lengthy process taking well more than an hour to install, setup, and customize a Windows 2000 installation. By using disk duplication (also called ‘cloning’) a standard configuration a deployment can take as little as 5-10 minutes per computer.

Cloning computers is fairly straightforward with using this process for identical or nearly identical hardware configurations. However, it is possible to use Sysprep and Windows 2000’s ability to identify plug-and-play hardware. I will discuss how to accomplish this later.

Adding KiX to the mix allows us to extend functionality to the unattended process. Using KiX one can automate virtually all of the tasks to ‘customize’ a user’s profile.

The downside to cloning is that you can only distribute the ‘image’ as a clean install; imaging won’t work for upgrades. Also, some applications installed on a standard configuration may not perform properly when imaging is used. Thus, planning, designing, and testing must be done.

PlanningWhen planning for a Sysprep Image you should consider it a project. Projects have phases that are performed in order to ensure the success of the overall goal. There are five phases in any deployment of an image:

Data GatheringBefore you plan and design your image, you need to understand the environment in which it will operate. Problems will arise if you don’t consider your environment. For this guide, we’ll focus on the last three of the following list.

Analyze Hardware and SoftwareBefore you build an image you should have a clear understanding of the hardware and software deployed in your environment. For example, there may be some hardware restrictions that will affect how your image is deployed. Analyzing your software will help in understanding how users use software, potential compatibility issues, or licensing considerations.

Consider the target workstations Hardware Abstraction Layer (HAL). The types of mass storage, drive controllers, and number of processors will play an important role. Check your hardware against Microsoft’s hardware compatibility list at:

Analyzing your software is important as it shows you what your users have installed, how they are using their computer, where their data is stored, and how the environment is managed.

Planning and DesignHere is where we use the data we so fastidiously gathered and analyzed to plan and design our image. We will create the ‘master’ that when finished will be prepped for imaging with the Sysprep utility.

It is beyond the scope of this document to provide a complete reference for building a master image. Use your own experience, corporate guidelines, and best practices for setting up your Windows 2000 build. In general, the steps for creating your master will include:

Using your ‘master’ image across varying hardware platformsOne of the more challenging aspects of designing a master image is getting it to work on computers that are dissimilar to the computer on which the master was built. If not done correctly you will find yourself staring blankly at a lovely blue-screen-of-death. We can overcome the majority of these limitations by utilizing the Sysprep utility.

The Sysprep 1.1 download will include all the needed files, documentation, and some sample sysprep.inf files. I’d encourage you to become familiar with the documentation.

I won’t go into a lot of details on customizing the sysprep.inf file. See the documentation (Microsoft Windows 2000 Guide to Unattended Setup (unattend.doc)) for details. Essentially, you configure your customized sysprep.inf file to import your customized settings, run sysprep.bat with the appropriate switches to execute sysprep.exe, and make an image of the ‘prepped’ computer.

Suffice it to say, that using Sysprep you can do anything from displaying your company’s logo during setup to setting up user data information. I will display some examples of working around some of the more troubling issues.

The infamous “Stop 0x0000007B” error after cloning an image to a dissimilar PCOk, here is the scenario; you’ve just created your master image (created on a Dell GX150), tweaked it out, run Sysprep, ‘imaged’ your master, and have successfully tested it on other Dell GX150’s. Great! Now you go to clone the image onto a Latitude C610 reboot and…blue screen of death.

Why? IDE chipsets. In order for Windows 2000 to boot, it has to be able to load the proper driver for the IDE controller. The IDE controller (and driver) for the GX150 is not the same as the C610.

Now what? It is possible to enable the controllers that natively supported by Windows 2000. Include the following section in your sysprep.inf file:

There are drivers for SCSI devices as well, and an example of the entries to use for SCSI devices are included in the Sysprep examples. I have not tested whether or not both IDE and SCSI entries can be used in the [SysprepMassStorage] section of the sysprep.inf. Feel free to experiment.

How to add Plug and Play drivers to the Windows 2000 installationOk, using the same scenario as above. You’ve created your master on a GX150 and you’ve cloned the image to a C610. You managed to get the mass storage problem fixed, but now when you boot up the C610 plug and play kicks in and starts to install drivers for the ‘new hardware’ found. The problem is that the drivers for the new hardware aren’t included with the image.

How do we add the third-party drivers to the Windows 2000 installation, you ask? Use the following procedure to add your OEM-supplied drivers:

quote:1. On the root of the volume where the %windir% folder is located, create a folder structure to hold the OEM-supplied drivers. For example:

code:

C:\Drivers.....\NIC.....\VIDEO.....\SOUND.....\ETC.

2. Copy the OEM-supplied drivers to their appropriate sub-folders.3. Add the OemPnPDriversPath entry in the [Unattended] section of the Sysprep.inf file. You can list multiple paths in this key by separating them with a semicolon, as shown in the following example:

Note: The %SystemDrive% environment variable is automatically inserted before each of the listed search paths.

If you do not want the OEM-supplied drivers to remain on the HDD after the mini-wizard is finished, you can place the folder structure you created under the Sysprep folder. You will need to adjust the OemPnPDriversPath appropriately. The Sysprep folder (along with its sub-folders are automatically removed after Setup is finished.

Save the Sysprep.ini file in the Sysprep folder and run the Sysprep.bat. Any Plug and Play devices (including the ones you added) are automatically installed during the mini-setup wizard on the target computers. Note that you will not need to specify the –pnp command line switch in your Sysprep.bat file unless there are legacy (ISA) devices on the target computers. Using the –pnp switch will force a full Plug and Play re-enumeration of all devices. This will add 5-10 minutes to the Setup mini-setup process.

Note: If the OEM-supplied drivers are unsigned, the mini-setup postpones the installation of the device until an administrator logs on to the computer. See the following ‘Q’ articles in Microsoft’s Knowledge Base for more information:

Incorporating KiXtart with SysprepThe Sysprep process includes several techniques for added customization. However, there are limitations with these options; for example, installing and configuring a sound card or installing a service.

Follow these steps to include a KiX script during the mini-setup:

quote:1. Copy KiXtart (and any other utility you use to administer computers) to the appropriate locations. Also, register any DLL that needs registered (i.e. KixGUI, AutoItX, etc.)2. Create a file name Cmdlines.txt with the command-line information to run your script at the top of the file. Example:

[Command] ”C:\Sysprep\i386\$oem\kix32 kix_prep.kix”

3. Copy the script to the proper location in your Sysprep folder.

The included script will run at the very end of the mini-setup wizard process. Here is a sample script:

Now you have created a method for running a script that will run after the mini-setup has rebooted your computer. Use your “Post Setup” script to automate tasks that cannot be accomplished by Sysprep like; installing machine specific drivers or software (i.e. touchpad drivers, chipset installations, changing computer name, add workstation to the domain, etc.). Use your imagination.

Testing, Piloting, and DeploymentUse the Testing and Piloting phases of your ‘Sysprep Image’ project to work out bugs and gain end-user acceptance. When that is done, you can begin Deployment.

Chris,Thanks for your contribution. Obviously, you have put a lot of effort into it. I'm sure many people will gain from it.

I do much the same thing except I take the lazy approach. Rather than go through all that effort to build one image for all, I have several 'flavors'. After all, there are significant 'needs' differences between a desktop and a laptop that would warrant a separate image.

We even have some 'custom' images burned to CDs. When one of our 'repeat offenders' blows up their PC, we can drop down 'their' image and have them back 'just like new'.

_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

I'd like to second Les.. there a good about of work in this. Writing up the document not to mention collecting the data and research that went into it.

We have many sysprepped images for a variety of machines (compaq deskpro 400 - 1.7g) and dell latitudes (300 - 1.1g) which require about 10 different images due to chipsets, storage controllers, video/sound controllers, etc.

If this procedure can modify our image creation process to reduce the number of images (even by half) this would be a great benefit to us.

Using this method is the 'real' lazy approach to imaging. Once you have it set up and working it is real easy to add new computers to the image. Now, when I make a change to our 'standard' deployment it is automatically reflected on all computers.

I came up with this method over the course of about two months of research and testing. The document I wrote above took about 10-12 hours to write (I looked busy, so I don't think my boss noticed. ).

When I made my original image I used a combination of batch files, a Wise script, and Autoit to accomplish my goals. I'm thinking of re-writing everything in KiX. As I do this, I'll post more sample scripts.

Kent and others,You mentioned dragging the window side to side...Not really necessary. If you look down at the bottom you will see a link to "Printer-friendly view of this topic" which is more than just "printer" friendly. It will make all lines wrap at the edge of the (screen) page. No need to side-ways schroll!

Lonkero,You don't know what you're missing. I can have a build dropped down to a user in 15, 20 minutes tops. Like Chris said, complete with service packs, hot fixes, applications, customizations, everything. I just couldn't see myself building every machine from scratch. And when a user messes up their build, in 20 minutes there "as good as new".

About the only thing I build from scratch are the odd new image for a special application or hardware, and of course, my servers. I do make images of servers from time to time but only as a backup prior to a risky upgrade. These would not be SysPrep'd.

_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

I also created a SYSPREP image for our standardized machines. I've then created an image using PowerQuest DriveImage and used the powercast function to apply the image to multiple computers at the same time. The next step is to experiment with PXE and see whether I just need to plug in a network cable and boot up the PC to have the image applied.

It definitely saves some time even if you set up machines only every once in a while.

_________________________
There are two types of vessels, submarines and targets.

Les,don't make it from scratch as you think.ok, my installation takes 30mins and it just uses automated installation rutines with pre-installation, ghost and such things and then logonscript for software installation after domain logon.

I know it takes some minutes more to execute, but once got it working some time ago haven't had need to investigate in sysprep.

this way, when only system is installed from the cd, the rest of the installation can be altered from that script which is taken from server.

Back in the NT4 days, I used to clone with DriveImage and use their SID changer. I find that for Win2k, SysPrep is a better way to go.

Jens,You've got way too much time on your hands. I'm happy to boot floppy. In fact I put the SysPrep.inf file on the boot floppy that sets most of the options. Sometimes I pull the image from the network, other times from CD. KiX only comes into play after the image is done.

_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.

If you want to REALLY automate the process, you should try looking at ALTIRIS.

Very powerful automation. Can even schedule periodic "sysdiff" type images of the user's computer so that even the user can repair, replace his/her image without your assistance. They also have PC Transplant Pro which is a very powerful utility that allows you to save almost every personal file and setting and apply it to a new computer. i.e. You could convert a user from Windows 95 to 2000 or XP and aside from the logon screen they would hardly even know their computer was switched out.

In my opinion there is no other company that has as complete a solution as they do. They have their bugs and issues I'm sure, just as every other product out there does, but I also feel it is the best one out there period.

If you can, have someone come out and to an in-house demo, I've been to their SMS/Altiris seminar in Las Vegas, and what this system can do is simply amazing. Supports the PXE boot and imaging as Lonkero is talking about, but so much more. We use Ghost 7.5, but that is only a small picture of what Altiris can do.

Heck, if I ever lost my current job, I wouldn't mind working for them, and working with that type of technology on a day-to-day basis.

Chris, That was a wonderful document on how to use sysprep. It explained it better than Microsoft ever has. When we first started to do sysprep back in NT 4.0 days, The documentation on it was, to say the least, horrifying. I dug my way through and finally had a working copy. Then when Windows 2000 sysprep utility came out. It had better documentation but was still hard to read and the examples were just copies of themselves with a few changes. Maybe you should send this post into microsoft and have them include this with their sysprep utilty so that there is a down to earth readable document in a form that use users can understand.

Hats off to you Chris on something I could never have put together myself. Cheers!!

Kudos Chris !! Excellent material. I just discovered this thread today and boy could I have used it in the not too distant past!I have put it into my Hall Of Fame documentation collection, and anticipate having to use it in the future....and the votes are well deserved.