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:
Signature = "$Windows NT$"
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.
This post was contributed by Michael Murgolo a Senior Consultant with Microsoft Services, U.S. East Region.