Subscribe via e-mail: In my last article, I listed all important features of Microsoft’s free Sysprep tool. Today, I will explain why I think that unique SIDs are still necessary, even though, Mark Russinovich debunked the machine SID duplication myth.
I have no doubts that Mark’s analysis that Windows networks don’t require unique SIDs is correct. Actually, this corresponds to my own experience. I have been cloning machines long before Microsoft introduced the Sysprep tool. At that time, Microsoft warned about using cloning tools. The main argument was that SID duplication can cause problems. This didn’t really convince me because my tests showed that these problems don’t exist. When I first tried a cloning tool, I was baffled as to how this technology was superior compared to unattended installations. Thus, I decided to ignore Microsoft’s warning and embrace OS cloning. I don’t remember SID duplication ever causing a problem.
Even today I often don’t use Sysprep in test environments. I am usually testing with virtualization software and I create new test machines using cloning technology almost every day. Running Sysprep every time is just too cumbersome. It is interesting to note that I also never run into problems with the latest Windows versions because of duplicate SIDs.
However, I still strongly recommend ensuring that all computers in a productive environment have a unique SID, for the following reason:
Future proof
Even if it is true that Microsoft doesn’t use SIDs to identify Windows machines, you can’t be sure that this will also be the case in the future. According to Microsoft’s official guidelines, it is still necessary to run Sysprep before you deploy an OS image. Therefore, Microsoft assumes that unique SIDs is standard. Imagine Microsoft delivering an update that requires unique SIDs while all the machines in your network uses have all the same SID.
Microsoft support
Even today, you probably will get no support from Microsoft if you didn’t Sysprep your machines. Telling the support staff that superstar Mark Russinovich claimed that SID duplication is no problem won’t really help you then.
Third party software vendors
The same applies to third-party software vendors. You know these hotlines. If they only guess that something in your network isn’t according to the official guidelines, then you are already in a defensive position. If you skim over the comments to Mark’s articles, you will see that some readers claim that they know of third-party software that makes use of SIDs and will not work properly with duplicated SIDs. The Windows ecosystem is very big and nobody really knows what odd things some ISVs do with Windows. Even if you don’t have now software in your network that requires unique SIDs this could change in the future.
The fact that Microsoft doesn’t use the SIDs doesn’t say anything about the requirement of unique SIDs. (Update: It is uncertain if Microsoft makes use of SIDs. See comments below.) It is essential that you try to keep the configuration of your PC as close to the standard as you can. The reason why I ignored Microsoft’s warning about SID duplication in the past was only because its gain was bigger than its risk.
However, now that Microsoft offers a free tool that lets you easily avoid complications, it is no longer justifiable to be working with duplicated SIDs. And as I outlined in my previous post, Sysprep is not only needed because of the SID issue.
Update: Unique SIDs are required for domain controllers. See comments.
Actually the number one reason to use sysprep is because there are around 31 other unique identifiers on any given Windows system that sysprep actually does take of. Mark’s point in the blog post (this is first-person not relayed) is that newsid never did anything for anybody. He had people complain that newsid was no longer supported on Vista+ so he dug into a little and discovered that newsid has always been essentially a useless tool.
Also note that there have been versions of sysprep around since the NT4 days, 10+ years ago. It wasn’t always freely available, but since at least XP (maybe even 2000) it has been included on the media.
Jason, I don’t remember that Microsoft ever charged for Sysprep. I only remember that they were forced to release such a tool because the SID removal functions of third party NT cloning tools didn’t work properly.
How did you get this number of 31 unique identifiers? Do you have the URL of the source? Sysprep does lots of undocumented things. But it seems nobody really knows what exactly.
To the best of my recollection, you could only get Sysprep if you had an EA during the NT 4 days — kind of like you could only get WinPE with an EA up until just a few years ago. So it wasn’t an explicit charge, but not free nonetheless.
The 31 number is also to the best of my recollection but was straight from the mouth of Mark R in a QA sessions at the beginning of December. The way he stated it he wasn’t even sure of the number and said something like “around 31″.
Thanks Jason. It is interesting that nobody appears to know what Sysprep is doing in detail even though almost every admin around the globe is using it.
You need to change the SID on servers especially
for more proof look at
http://www.petrikb.com/email-stuck-in-drafts-folder.htm
Petri has proof that SID problem exist and it happened to him!
I think Mark was forced to write his response and take down newsid since it went around sysprep which forces you to reactivate your server with Microsoft
and remember to change the SID you need to click the GENERALIZE option
ben, thanks for the hint. I think Daniel Petri’s problems are related to the fact that domain controllers need unique SIDs. Mark has mentioned this in his article. I added a corresponding note to my article.
Another reason unique SIDs are needed is that if you are using KMS to activate your Win7 machines, without unique SIDs they don’t count towards the 25 needed hosts to activate the KMS host itself.
My source for this was one of the “Troubleshooting KMS” webcasts MS did in Feb, I have not tested it myself.
Dave, thanks this is very interesting. I added a hint in the article. Do you have the link to this webcast?
According to the Volume Activation documentation (http://www.microsoft.com/downloads/details.aspx?familyid=9893F83E-C8A5-4475-B025-66C6B38B46E3&displaylang=en), there is a unique identifier called ClientMachineID. However, this attribute is generated at the time a client connects to the KMS and not directly associated with the SID: “The unique identifier for this KMS client computer. The KMS client generates CMID the first time it attempts to connect to the Key Management Service. CMID = NULL otherwise.” The documentation makes no reference to the SID in any way. I suspect that the presenter used SID to generically mean a system unique identifier and not the actual SID of the system or was under a false impression. Although I definitely leave the possibility open that the presenter knows more than I do, I find it nearly impossible that he knows more than Mark R.
I was just reading through Mark’s original blog post (http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx) that started a lot of this talk again and he specifically dispels any notion of the SID being used for activation: “KMS use the CMID, not the SID. Issue raise when you do not use the /generalize of the sysprep, because the CMID is not changed. This KB explains it: http://support.microsoft.com/kb/929829“.
Jason thanks a lot illuminating this issue! Mark’s discovery is relatively new and it will take a while until the news will be passed round. On the other hand, I somehow doubt that even Mark knows how every single Microsoft application works in detail. For example, what about all the System Center products? Do they make use of SIDs?
An absolutely spot on point Michael. We don’t know what other products, even those inside Microsoft are actually using. Which reinforces your main point of this article and Mark’s: just use sysprep.
Jason, thanks. I think the problem is that Mark focused too much on the mere technical facts in his article. This confused many of his readers. I am sure many missed his advice to use Sysprep and think now that it has become obsolete.
When I stepped into my current position, I took over image creation in an environment where we used Ghost 8 without Sysprep. We had a group of 20 computers with identical hardware all running the same unsysprepped image on the same subnet. Computers within this batch of 20 would display BAD_POOL_HEADER BSoDs at a rate of around 5-12 per day depending on how often the computers were being accessed. I attempted to recreate the image on more than one occasion to fix it to no avail. I eventually began running SysPrep before deploying the image which solved the problem. To this day, I wish I knew why it was the solution.
@4: “It is interesting that nobody appears to know what Sysprep is doing in detail…”
This might help:
Sysprep functions and known issues
http://support.microsoft.com/kb/928386