[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
Windows Embedded Standard systems are built differently, and do not have the same setup experience as normal desktop Windows computers, but both have one thing in common: Windows Security Identifiers (SIDs).
SIDs are used to distinguish different Windows computers in a networked environment and are also identifiers for nearly everything related to security. Heavy use of SIDs is made, for example, in the user management of a local system as well as in an Active Directory domain. For certain built-in accounts and groups there exists the same (well-known) SIDs on all systems. In addition, there are SIDs that must not be the same on different devices in order to guarantee the uniqueness of the device, local account, etc.. One of the most important among those is the machine SID that is used as a prefix to other SIDs, such as e.g. local user accounts.Because this SID is unique to a machine it is problematic to clone a Windows system with a disk cloning tool such as Ghost or the Imagex utility by Microsoft, without changing the system’s SID. Systems that still have the same SID as the original system have problems in networked environments. To complete the picture, SIDs are used to manage user rights in the access control lists (ACLs) of files and registry keys, as well.
Cloning embedded systems
To enable the cloning of embedded systems Microsoft included a component called “System Cloning Tool” in the Component Catalog of XP embedded. System Cloning was the only supported cloning tool for Windows Embedded by Microsoft for quite some time, but in Standard 2009 Sysprep, the tool used to clone desktop systems, was also made available to enable the System Center Configuration Manager’s OS Deployment functionality. Sysprep and the System Cloning tool behave quite differently and therefore can be used to address different deployment scenarios.
System Cloning Tool
The System Cloning Tool is designed to deal with deployment of the image.. It is well integrated into the build process and can be run automatically at the end of the First Boot Agent (FBA) process. It offers options to reconfigure several settings of a device after the cloning. However, quite often it is a good idea to set the cloning behavior to manual, because in most projects some manual tweaking after running through FBA is required. In this case, the sealing of the image needs to be done with the help of the Fbreseal utility and appropriate command line switches e.g.:
C:\>fbreseal –keepautologon -keepmounted
Caution: Fbreseal is not the most user friendly tool. It offers no help screen via a -? switch and, even worse, runs with the default options if one tries to call it with that switch!
The actual cloning process always takes place when the target device boots the first time. Due to this, it is not a good idea to have write filters enabled at this stage. If they are, the cloning process repeats itself any time the system boots. The cloning process is extendable by adding custom native Dlls with a corresponding entry point in target designer, but quite often OS developers tend to use RunOnce Registry keys set before sealing the image to achieve the same effect.The system cloning process itself is designed to run only once and therefore fbreseal deletes itself after the first execution.
The reason Sysprep was included in Standard 2009 was to provide a seamless integration with the enterprise change management tools, especially System Center Configuration Manager (SCCM).With Sysprep included, the image deployment feature of SCCM is also available to Standard images.
Sysprep is the tool OEMs and corporate administrators use to clone their desktop and server images for all versions of Windows, reaching back as far as NT 4.0. You can find a ton of information on how to use it in TechNet. It is good to know, that there are always Sysprep versions related to a certain OS release and therefore, for Windows Embedded Standard, only the information focusing on Windows XP should be used.
In contrast to the System Cloning Tool, Sysprep, leveraging a mini-setup, allows more granular interaction and branding during the first boot of an OS on the target system. This can be quite compelling for OEMs looking at an enhanced user experience or better maintenance abilities in field.
The Sysprep component includes several configurable options in Target Designer. One option specifies whether Mini-Setup should be used or not during the cloning process. Sysprep does not run at part of the FBA process and therefore all commands to seal the image need to be triggered manually or from other scripts or applications.
To seal an image from the command line use:
There are a lot of other options available depending on the deployment scenario available. Mini-setup, for example, can be configured to display only certain dialogs or to suppress certain dailogs.The whole setup-process can be automated using a unattended.txt configuration file.
How to choose?
Well, this is not always easy to tell, but if devices are built and set up at the OEMs location I personally would favor System Cloning Tool due to its better integration in the built process for this scenario.
If devices are deployed and configured in field Sysprep in combination with its mini-setup offers more flexibility and a better user experience for end users or maintenance personnel. However be aware that Sysprep is only supported in Standard 2009 as part of the SCCM OSD scenario.