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.
…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.
On TwitterMy Tweets
- Administrivia (1)
- Authentication (16)
- Business Continuity (3)
- Client applications (18)
- Consultancy and Design (19)
- Hardware (9)
- IT Management (13)
- Miscellaneous (5)
- Mobile (4)
- Networking (18)
- Office 365 Grid (5)
- Performance (26)
- Power (2)
- Security (27)
- SharePoint (79)
- Unified Communications (3)
- Virtualisation (30)
- Windows (59)
TagsActive Directory ADFS administration Amazon Web Services ASUS binding Claims Cloud DCOM Dell development DNS EC2 Graphics Hyper-V IaaS ICS IIS Information Rights Management Intel IRM LDAP Lync NUMA Office 365 PowerShell RMS SAML Search SEO Service Application SharePoint SharePoint 2007 SharePoint 2010 SLAT STSADM User Information User Profile Virtual Machine VMWare w3wp Windows 7 Windows Deployment Services Windows Server 2008 R2 Workgroup
Archives by Month