Sysprep, Machine SIDs and Other Myths
In a recent blog post, Mark Russinovich wrote about the implications of having duplicate machine Security Identifiers (machine SIDs). As it turns out, there are likely very few situations where having duplicate machine SIDs causes issues. Unfortunately, some have gotten the mistaken impression that the discontinuation of NewSID means that nothing needs to be done to prepare an installation of Windows for imaging. (Mark even specifically states that otherwise.) Microsoft Knowledge Base article 314828 may also leave this impression since the beginning of the MORE INFORMATION section focuses solely on duplicate SIDs. (I will be pushing our Support folks to clarify this.) As I will show, the real “myth” is the idea that changing the SID is the only thing that needs to be done to prepare Windows for cloning.
It is true that one of the reasons we do not support the use of tools other than Sysprep is because these other tools don’t necessarily know about all the places where Windows stashes away references to the machine SID. However, the main reason is that Sysprep does much more than reset the SID. Even as far back as Windows NT 4.0, Sysprep has been used to enable a two stage process for deployment. The first stage was actually running Sysprep. This would prepare the operating system to be duplicated. The next stage, Mini-Setup, would run to change the operating system in such a way that it would act as a new, unique installation of Windows. These stages are now named “generalize” and “specialize” respectively in Windows Vista and higher operating systems. To simplify things, I will refer to this two stage process as the duplication stages.
The Windows NT 4.0 duplication stages only did a relatively small number of things such as resetting the SID, changing the OEM branding strings, changing the Product ID, and changing the computer names. However, since Windows 2000 the duplication stages have been tasked with many more items such as disabling/enabling System Restore, removing/regenerating TAPI settings, cleaning the device database/reinitiating full Plug and Play device detection, removing/regenerating network settings, resetting user first run settings and others. Also, apart from its internal tasks the duplication stages call external “providers” that allow the Windows component developers and third-party application vendors to prepare their components for duplication. (The Windows 2000/XP version of this process is documented in Microsoft Knowledge Base article 298491.) Below is the contents of the file that registers the Windows component external providers on Windows 2000/XP, minioc.inf, taken from the Windows 2000 RTM CD:
[Version]
Signature = "$Windows NT$"
DriverVer=11/14/1999,5.00.2183.1[Components]
NtComponents=ntoc.dll,NtOcSetupProc
Display=desk.cpl,DisplayOcSetupProc[SysprepInitExecute]
msdtcprx.dll,SysPrepDtcReinstall
catsrvut.dll,SysprepComplus
scecli.dll,SceSysPrep[SysprepBeforeExecute]
setup\msmqocm.dll,SysprepDeleteQmId[Global]
WindowTitle=%WINDOW_TITLE%[Strings]
WINDOW_TITLE = "Windows 2000 Professional Setup"
As you can see, several external DLLs are called to prepare Windows components for duplication stages. The number of Windows component providers has only increased with each new version of Windows. While the Windows Vista and higher Sysprep providers are no longer registered in INF files they still exist (see the Sysprep Provider Developers Guide for details). There are 26 Windows component providers currently used in Windows 7 during the “generalize” process and 21 used during “specialize” (numbers that could change with any Windows update or service pack).
Because of what I have shown here, I submit that since at least Windows 2000 it was never a best practice to simply run a SID-resetting utility like NewSID to prepare an installation of Windows for duplication. (It was certainly never a Microsoft recommended best practice.) These tools simply do not do everything that the Sysprep duplication stages do. Even if SID regeneration were to be removed from the duplication stages in future versions of Windows, the Microsoft Policy Statement in KB314828 regarding the use of Sysprep is unlikely to change. With each new version of the operating system the Sysprep duplication stages have become more complex. Simply removing SID regeneration is unlikely to change this. Cloning without running Sysprep can affect components such as the Windows Update client when used with Windows Server Update Services, Network Load Balancing , MSDTC, Vista and higher Key Management Server activation, and others.
On the topic of SID duplication itself, I think it would be a mistake to remove SID generation from Sysprep duplication stages. There is at least one case where duplicate SIDs are a problem that Mark discusses where a member server cannot have the same SID as a domain controller. Therefore, if a server image is used to create the first domain controller for a new domain it cannot but used for any member servers without changing the SID. Also, having unique local SIDs provides an easy first check as to whether machines were duplicated correctly. Finally, without a thorough review of the Windows source code and every third party application, I’d say it is premature to say that nothing else depends on unique SIDs.
Although there may be few consequences of SID duplication per se, what the Microsoft development and support teams are really concerned about are installations of Windows that were duplicated without using Sysprep. Duplicate SIDs are a “symptom” of installations that are improperly duplicated.
Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .
This post was contributed by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.
Comments
Anonymous
January 01, 2003
Monk147 - Running Sysprep multiple time is generally not recommended due to issues that can occur. Please read this blog post:blogs.technet.com/.../sysprep-skiprearm-and-image-build-best-practices.aspx. Marcus - Yes, Sysprep does have some inconvenient behavior but it is the only way to assure that any clone that is deployed is in a supported state when it is started. You can avoid PnP re-detection by using PersistAllDeviceInstalls in Unattend.xml:technet.microsoft.com/.../ee832798(WS.10).aspx. Michael MurgoloAnonymous
January 01, 2003
Andrew, I assume you are asking about whether PersistAllDeviceInstalls could be used on VMware virtual machine. As long as the attached virtual hardware was identical between the VM where Sysprep was run (the "template") and the deployed VM, the you should be able to use that. Michael MurgoloAnonymous
January 01, 2003
Hi Michael and thank you for your article. I'd like to go little beyond the SIDs themselves and talk about computer accounts in AD. Lot of customers use to decommission old PCs, deploy new PS using old names and attach them to old computer accounts in AD. Do you believe that's a safe practice or it's better to reset/delete old computer accounts and create new ones? Thanks in advanceAnonymous
January 01, 2003
Artem, It will depend upon what your goals are. If you are trying to do all of the following, then rejoining the existing account makes sense. • Keep the existing computer name. • Preserve the existing computer account direct resource access. • Preserve the existing computer account group membership (for resource access via group membership and Group Policy security group filtering). • Preserve container (OU) location If you wish to do none of this, then deleting the old account and creating a new one may make more sense. Where it gets tricky is if you only want to do some of the above items. For example, supposed you want a new computer name and a new OU location for the account while preserving the group membership. Then there are several ways you can do this. You could script a rename and move of the existing account after the old OS has been shut down for the last time but before the new OS join occurs. (You would use this method if you needed to preserve access to resources ACLed directly with the computer account.) Alternately, you could capture the computer group membership while in the old OS delete the account (here’s an example of that - http://blogs.technet.com/deploymentguys/archive/2009/06/19/setting-ad-computer-object-mdt-properties.aspx), create the new account in the correct OU on join, and write a script to restore the membership to the new account. Michael MurgoloAnonymous
January 01, 2003
Hi Guys Thanks for the informative article, it is much appreciated I have just found your blog and I am very impressed. I am wondering if you may be able to help me with a problem I am having with XP Pro SP3, Sysprep and Acronis Up until a few months ago I would make my images for IBM Thinkcentre and HP Desktop computers that I support in various businesses. These updated images would be have XP Pro SP3 and current Microsoft updates and as a final step I would sysprep the machine, Shut down and use Acronis to image the machine ready for deployment. This procedure was working great until last week when I decided to update my images with the latest microsoft updates and applications that the user used. When I then go to use the images for deployment, the machine now gets into a loop at the point where you specify the computer name and description. It just keeps coming back to this same point. I have tried rebuilding another model of HP from scratch that I haven't used before and I still get the same problem. I am thinking that the issue is related to some of the latest MS updates that have come out in the last few months or so, however I am not sure. Help would be much appreciated Craig WilliamsAnonymous
January 01, 2003
As part of a team that creates Enterprise SOEs (Sysprep Resealed) that are then provided to regional Field services personal who then add region specific content we are finding that they are using Disk Cloning. What they are doing is taking a completed build, adding content, then re-running sysprep reseal. They would then capture that image and deploy it to like devices. Is it appropriate for them to be running Sysprep Reseal on an instance of the OS that has already been resealed? I have not been able to find Microsoft support statement on running Sysprep reseal multiple times on a given instance of an OS. In a conversation I had several years ago with a Microsoft engineer that we had in to help he specifically told me that it was not recommended or supported. Thanks for taking the time to read this.Anonymous
December 03, 2009
Very interesting post, but what do you think about desktop virtualization? i don't know Microsoft VDI infrastructure at all, but for example with Citrix XenDesktop the vDesktops deployed to and used by users come from a single (or group of) operating system image (without any kind of sysprep or other pre-duplication tools). Thanks, StefanoAnonymous
December 03, 2009
i like to share my experience with duplicate SID, we rolled out some machines without knowing that the SID were duplicated, when came to windows updates thru WSUS, some machines kept going missing and there was no way to check the status of the missing PCs. We eventually identified the duplicate PCs and did a fresh and verified image onto them.Anonymous
December 05, 2009
WSUS is a more complex issue, because the a WSUS ID is stored in the registry on each PC from the point at which it first contacts a WSUS server. Due to poor decisions at Microsoft, this was not cleared by sysprep in many cases. To make matters worse, the WSUS server itself foolishly took 2 client PCs with different FQDNs, BIOS version, OSs, SIDs but identical WSUS IDs as being the same client. If they HAD used the SID to differentiate these problems would have been avoided, but Microsoft invent their standards and best-practices for /other/ people to use not to use themselves.Anonymous
December 09, 2009
Hi Michael, Good article. I read Mark's original post and was amazed and rather worried that so many people commenting either missed the point, or refused to believe Mark because they had duplicated machines and had problems. Am sorry Emanuel, I see you point about standards. You made the assumption WSUS uses SIDs albeit in good faith. That glosses over the point of logic failure of cloning: keep it clean. The whole point of cloning is to keep the source clean as a whistle. Sysprep is there to do just that cleaning but it can only clean out so much. It doesn't clean WSUS values because cloning a machine with WSUS IDs is "a bad idea" (tm). WSUS is working by design to ignore everything but the ID it handed out, probably because some people DO indeed make bad clones that have identical SIDs. So they play safe and don't assume. Poor decisions are not Microsoft's. It's the people who clone things they shouldn't who do, and then blame Microsoft when it doesn't work. It all reminds of a variation of film "The Fly".Anonymous
January 13, 2010
Althou I do understand sysprep need, but having using Altiris to clone WinXP computers it really means that I save ALOT of time when I simply clone computer by making a "perfect" sample computer with perfectly setupped user (In school envoroment with 21 computers, all using same username "Student", no AD) and then simply taking a snapshot of computer and multicasting it to other computers. It was fast and easy way. Altiris had sysgen that made changes to computers so there would not be dual SID's. Using Sysprep resets so many setup tasks in computers (f.ex. notorious IE 8 "kazillion" steps to start browing, all small little details in other computers) and now in our Win7's it destroys f.ex. Display drivers which means that after almost installing all compueters by hand (sysprep destroys so much ..) I have to reinstall drivers also. Is there ANY way to get back to old ways of simple and fast procedure of cloning and setting up or are we forced to use 20th century tools and ineffentiel ways?Anonymous
February 02, 2010
Hello Michael. Thank you for your article. I do need your help. I am almost in the same situation that Craig Williams described. Up until recently, I did not have any problems in using sysprep to "reseal" my images. We have a variety of IBM thinkpads and I have to update the cloned images regularily with updates, etc. What happens now with ThinkPad T60 image is that after I "reseal" the computer with all new updates and patches, as soon as I go through the initial setup and login for the first time, I am unable to see "Windows IP Configuration". It is just blank - it doesn't show any adapters, it doesn't say "Media disconnected", nada. Although, in "Device Manager" I can see all network adapters and they are also present in "Network Connections"... I was, unsuccesfully recetting TCP/IP stack, applied WinsockFix, etc to no avail. I exported registry keys (HKLM/SYSTEM/CurrentControlSet/Services/Rcpip and HKLM/SYSTEM/CurrentControlSet/Control/Network from a working machine and imported them into freshly sysprep'ed - that didn't work either. I am at the end of my wits! Please, help. Thank you.Anonymous
September 10, 2012
The comment has been removedAnonymous
February 21, 2013
can this be done on a vmware machine?Anonymous
March 03, 2013
The comment has been removedAnonymous
May 18, 2014
Hi All
I have a already customized image wim file, I have been asked to install drivers of new model so that it can be applied and used on new model.
I installed the drivers and when I am doing sysprep with generalize and reboot options it is uninstalling display driver and hence its going into an inconsistent state after reboot. Since the wim is not a standard wim but a customized one. is there any way to make sysprep generalize phase to avoid uninstall of drivers?. Thanks in advance.