It’s now a week on from Mark Russinovich’s NewSID retirement announcement and I’ve been watching the feedback since. To give a brief overview, it’s long been a tenant of machine cloning processes that a new machine SID should be generated for each clone in order to prevent conflicts. Mark Russinovich wrote the original NewSID tool for Windows NT and as a Microsoft Technical Fellow today, he supposed that it might not be needed anymore and investigated the implications of retiring it. Obviously, if you haven’t read it yet and you work with machine cloning, you should read the article, but if you haven’t found the time to sift through the 168 comments (and counting), this summary might help clarify things:
It appears many readers are confusing machine-specific state, computer Domain SIDs, and machine SIDs. This article is only about machine SIDs. Having multiple computers with the same computer Domain SID will definitely cause problems. Further, some applications create per-machine state that they expect to be unique across systems and cloning a computer with that state will cause problems for those applications. As many have pointed out, Windows Server Update Services is one example.
For those reasons, Microsoft’s official support policy will still require Sysprep to have been run on a cloned system.
These additional responses from Mark may clear things up further:
Every Domain has a unique Domain SID that’s taken from the machine SID of the first Domain Controller of the Domain, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers.
And:
…because AD uses the machine SID of the first Domain Controller as the SID for the Domain, and all systems subsequently promoted to DCs on that Domain adopt the same machine SID, member systems cannot also have that machine SID.
For the DC you want to create from a clone, create a unique installation or run Sysprep.
That’s the only real caveat. Any Domain SID conflicts would be a huge problem, so cloned domain controllers or members must all be SysPrep’d. Stated in another way, SysPrep is the only supported way to clone machines in a domain.
What implications does this have for SharePoint development?
- In a Workgroup, none
- In a Domain, none, because we’re talking about Machine SID not Domain SID
One thing that does impact cloning of SharePoint development environments is the machine name. If that changes then you find yourself in a migration exercise that will probably take more time than building from scratch. To this end, some people:
- Run the SharePoint installers with updates
- Do not run the configuration wizard
- Capture a SysPrep’d image
- Deploy that image
- Run the configuration wizard on the deployed machine with a new name and new SID
This approach remains unchanged by NewSID retirement.
As I’ve been discussing, we go a step further and isolate the virtual machine so that we can use an exact replica without any reconfiguration. This is a preference and I think there are big benefits to it, as I’ve explained, but there are many ways to approach this, and to speak to the NewSID questions, all are equally unchanged.
Mark does not say that domain member computers (e.g. workstation) cannot have the same machine SID. He just says: “member systems cannot also have THAT machine SID”. Where, “THAT” refers to: “…the machine SID of the first Domain Controller… and all systems subsequently promoted to DCs on that Domain.”.
Also, this is only because “AD uses [THAT] machine SID… as the SID for the Domain”.
If all member computers have the same machine SID – but, this SID is different from “…the machine SID of the first Domain Controller… and all systems subsequently promoted to DCs on that Domain”, I see nothing in Mark’s article advising against that.
Maybe just give it a try? If you have two machines with the same name/SID communicating with the same DCs concurrently, there will be problems. This is part of why we need to run SysPrep. He even says (as I quoted), “It appears many readers are confusing machine-specific state, computer Domain SIDs, and machine SIDs. This article is only about machine SIDs. Having multiple computers with the same computer Domain SID will definitely cause problems.” Everything you’re citing basically just means that you shouldn’t DCPROMO a machine that’s been created from a clone, unless it’s been SysPrep’d first.
I was not disagreeing with the assertion that: “you shouldn’t DCPROMO a machine that’s been created from a clone, unless it’s been SysPrep’d first”.
Instead, the sentence which I took issue with was: “cloned domain controllers OR MEMBERS must all be SysPrep’d”.
Ordinary workstation are domain members, And I was saying that such members can be cloned without worrying about whether their SIDs are unique – since you have no intentions of ever promoting one to DC.
That was the main point of the Russinovich article.
I’m not sure that was the point of the Russinovich article. That was the one case where the machine SID matters. But the domain SID of member machines definitely still matters, as it’s how objects in the domain are identified. This is why SysPrep is still a requirement for cloning domain member servers. So he effectively does say that, “domain member computers (e.g. workstation) cannot have the same machine SID”. In a Workgroup it doesn’t matter (unless the machines get promoted to DCs). In a domain it always matters.
It’s difficult to believe you read all of Mark’s article. You are perpetuating the very myth that Mark is trying to debunk. Here it is in Mark’s own words, from that article.
“The more I thought about it, the more I became convinced that machine SID duplication – having multiple computers with the same machine SID – doesn’t pose any problem, security or otherwise. I took my conclusion to the Windows security and deployment teams and no one could come up with a scenario where two systems with the same machine SID, whether in a Workgroup or a Domain, would cause an issue.”
“I realize that the news that it’s okay to have duplicate machine SIDs comes as a surprise to many, especially since changing SIDs on imaged systems has been a fundamental principle of image deployment since Windows NT’s inception. This blog post debunks the myth with facts by first describing the machine SID, explaining how Windows uses SIDs, and then showing that – with one exception – Windows never exposes a machine SID outside its computer, proving that it’s okay to have systems with the same machine SID.”
FROM: Mark Russinovich Nov 2009 12:00 AM
http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx
That’s definitely not what I’m doing. He’s pretty clear about these distinctions in his article, as in the passage I originally quoted to you, “It appears many readers are confusing machine-specific state, computer Domain SIDs, and machine SIDs. This article is only about machine SIDs. Having multiple computers with the same computer Domain SID will definitely cause problems.” I don’t know how much clearer that can be. The only exception to any of this is that the first DC should not be cloned, as its SID becomes the SID for the domain (as you originally quoted to me).
194416