What is Sysprep? What does it do? Why do we need Sysprep?

Products

• Deployment Solution

Issue/Introduction

 

Resolution

Question
There is a bit of mystery around Sysprep, regarding what it does, where it comes from, why we use it, etc.  This article is designed to clarify the process for internal use.

Answer

Imaging - The History

First came Windows.  Then came Ghost (and maybe some others, but who cares about them).  Then came problems.  Why?  Because when you cloned Windows machines with Ghost, you had things like duplicate Security Identifiers on the network, duplicate IP addys (back in the days before DHCP), and often problems where the newly imaged system wouldn't boot because of hardware differences.\

During this time, Microsoft made it VERY clear that duplicating images was not supported, and would void your warrantee.  Translation - just TRY to get help from them on a system that had been duplicated.  No go.

Then came Sidchanger, Ghostwalker, Sidgen, and who knows how many more SID changing tools.  These handy utilities got around the SID problem and just like that - imaging took off.  There was still the problem with hardware, but with some creative work, you could get around SOME of these problems too (i.e. you could install a NIC, add the drivers, pull the nic, add another nic, install the drivers, pull the nic.....  pretty soon, the OS would have the drivers - THEN capture.)

Creative solution - but still not supported by Microsoft.

However, as the process got better and better, and people used it more and more, the mighty MS caved, and came up with a supported process.

And Sysprep was born!

At this point, the other SID changers owned the market, but Sysprep was the only "supported" method, and relatively quickly, the smaller players died.  Their history largely doesn't matter, unless it's with GhostWalker and SidGen - our utilities.

So, DS started with Sidgen, being one of the early management tools for imaging.  As a legacy app, it's still there today, though the main reason for it's continued existence is thin clients, which can't run Sysprep.  You COULD still use it, but 1) it's not recommended, and 2) you should NOT use it AND use Sysprep.  That's just asking for troubles.

Anyway, as time went along, more and more demand was for a "supported" method of cloning systems, and we started to add more and more Sysprep support to our app.  At this point, most customers don't need to know what Sysprep is, or how it works, to get the benefits from it, because we've automated most of it.

However, Sysprep still does not support imaging accross HAL's, or the Hardware Access Layer.  What that means, is that when an image is captured on one "type" of system and pushed to another, if too much of the hardware is different, it wont boot.  For instance, if you capture an image from a SATA drive, and deploy to a SCSI system, it'll likely fail.  The drive type and architecture is part of the HAL, and Sysprep doesn't support crossing that.

Industry however, doesn't like to be told "no" and started coming up with ways to make it happen anyway.  The key to this is to ensure that the drivers for the "new" hardware architecture are available.  Enter DeployAnywhere from Ghost.  This will take care of that portion for you, and with the addition of this tool into DS, nearly everything you need for imaging, even accross HALs, is there in our console.

So, What exactly IS Sysprep?  How is it different from Sidgen?  What is MiniSetup?

The old tools designed to get around the SID problem were - less than efficient relative to reconfiguring Windows.  Microsoft knew this, and had seen too many "weird" things result.  What all these tools like Sidgen did was 1) scan through the registry for any and all entries relative to the SID and 2) replace those SID's.  This is done on the "new" or recipient system of the image.  Some tools did it in DOS prior to booting, others in windows (Sidgen) and then forced a reboot.  The problems with this method though include essentially "broken" or "orphaned" apps and settings.  For instance.  Say you have a system, and it's part of a Domain.  Run Sidgen, and now you're broken on the domain.  Why?  Because your Domain key is a combination of your computer SID and the domain SID, but your combination is now wrong.  Plus, AD knows about your old SID, not the new.  Big problem.

With Sysprep, Microsoft looked at everything that would have to change, along with the SID, for a system to be considered, effectively, "new".  They wrapped that up into a tool and now it's shipped free.  With XP/2003 and earlier, it's on the installation CD, and with Vista and forward, it's actually installed on the system out-of-the-box.

What Sysprep does is pretty simple, and though there are variations on this, this process is pretty close, and is likely what you'll see when using DS.

• Strips out several settings like networking and such from the registry
• Flips a switch in the OS that tells the OS that it's not done installing and will need to complete the installation by running MiniSetup on next boot.
• Creates/renames an OEMSETUP.INF file
• Shuts down the system for imaging.

At this point in the process, Sysprep is still ON the system, but is done.  It will never be run again.  Instead, you may have noticed the second bullet - which talks about MiniSetup.  The second part of the Sysprep "process" is actually completed by MiniSetup.

MiniSetup is a portion of an OS installation most of us are intimately familiar with.  It's the part that asks for your time zone, log-in name, stuff like that.  After it's done, the system reboots, and you're essentially "good to go".  An installation of an OS, from CD, on a new computer, without DS, would look something like this:

OS Installation Process from CD

1. Boot from CD and launch a 16bit OS to begin the setup process
2. Format the drive
3. Copy installation files to the drive
4. Reboot into another 16bit OS
5. Run MiniSetup to detect hardware, and configure the OS (i.e. time-zones)
6. Reboot into a 32 or 64bit OS
7. Finalize computer settings and wait for user to log on for the first time.

More about this process is discussed below.

How Do These Work Together For Us and Imaging?

First off, don't use Sidgen unless you have to, like with Thin Clients.  So, for this discussion, that process will not be discussed.

An ideal imaging process looks something like this (behind the scenes):

1. The image capture job, configured with Sysprep, is sent to the client.
2. AClient backs up the network stack to a place in the registry for use later.
3. AClient decompresses Sysprep, and launches it.
4. Sysprep strips out registry settings and flips a switch, essentially, to tell the OS to revert to an "almost installed mode", or step 5 in the process listed above under "OS Installation Process from CD".
5. Rename the SYSPREP.INF file in the Sysprep folder to OEMSETUP.INF to be used during the Minisetup phase in step 15 below.
6. Sysprep shuts down the computer.
7. Image is captured.
8. Image is deployed to a new computer.
9. If the job is configured to use Sysprep, DS copies down a replacement for the OEMSETUP.INF file created by Sysprep in step 5 above, with settings from the DS database.
10. If the job is configured to perform Post Configuration tasks, DS copies down an ACLIENT.CFG file which will be used by AClient in step 18 below.
11. If the job is configured to use DeployAnywhere, DeployAnywhere runs, detects hardware, and copies in any drivers necessary, assuming it has them.  These would be used in step 14 below.
12. Comptuter is told to reboot.
13. Computer boots into a 16-bit Minisetup, essentially the "next step" after 6 above had there been no interruption of a capture.
14. Minisetup does a hardware detection and loads appropriate drivers based on what it finds (uses drivers from DeployAnywhere).
15. Minisetup then looks for and reads the OEMSETUP.INF file, which is essentially the answer file for all the questions it would have asked you in step 5 in the above process called "OS Installation Process from CD".  This allows that process to run unattended.
16. Minisetup, now completed, reboots the system.
17. Computer boots into 32bit or 64bit mode with the OS, and AClient launches.
18. AClient reads the ACLIENT.CFG file and at default (can be configured otherwise) restores the Network stack from the location created in step 2 above.
19. AClient runs any additional "Post Configuration" steps necessary to make the computer look like it should look per the stored settings (if any) in the DS Console (i.e. rename the computer, join the domain, etc)  This may require more than one reboot.
20. Computer is now ready for use.

By the way, THIS, is why it's well worth it to use Deployment Solution for imaging.  :-)