Forgot your password?

typodupeerror
Windows Microsoft Software IT

The Machine SID Duplication Myth 201

Posted by kdawson
from the no-harm-in-seeing-double dept.
toppings writes "Microsoft Technical fellow Mark Russinovich explains why he is now retiring NewSID, which has been used by IT departments for years when deploying Windows to new systems from customized clone images. Russinovich writes: 'The reason that I began considering NewSID for retirement is that, although people generally reported success with it on Windows Vista, I hadn't fully tested it myself and I got occasional reports that some Windows component would fail after NewSID was used. When I set out to look into the reports I took a step back to understand how duplicate SIDs could cause problems, a belief that I had taken on faith like everyone else. 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. At that point the decision to retire NewSID became obvious.' He concludes: 'It's a little surprising that the SID duplication issue has gone unquestioned for so long, but everyone has assumed that someone else knew exactly why it was a problem. To my chagrin, NewSID has never really done anything useful and there's no reason to miss it now that it's retired. Microsoft's official policy on SID duplication will also now change and look for Sysprep to be updated in the future to skip SID generation.'"
This discussion has been archived. No new comments can be posted.

The Machine SID Duplication Myth

Comments Filter:
  • Oh, right... that. (Score:4, Interesting)

    by tverbeek (457094) on Tuesday November 03, 2009 @10:39PM (#29972716) Homepage

    For what it's worth, using NewSID (or some other technique to accomplish the same thing) was too much trouble to do the first time when push came to deadline and I had to crank out a few hundred WinXP workstations for the college labs. I didn't have any problems. Never gave it another thought.

  • by ErMaC (131019) <[gro.soidutscamre] [ta] [camre]> on Tuesday November 03, 2009 @10:44PM (#29972744) Homepage

    There are several other software packages with a similar problem. Microsoft SMS is a big one, as well as most McAfee Enterprise Virus scan products.
    I think Mark's saying this to conveniently avoid updating his software to work with Windows Vista/Windows 7 =)

  • Isn't it ridiculous? (Score:1, Interesting)

    by Anonymous Coward on Tuesday November 03, 2009 @11:01PM (#29972860)

    Isn't it ridiculous? A guru working for MS says "OK, we finally figure out we don't understand what's going on, after all these years"

  • by mysidia (191772) on Tuesday November 03, 2009 @11:07PM (#29972902)

    I think there's an elegant, simple solution to this.

    Microsoft should incorporate NewSID into the DCPROMO utility, and force generation of a new SID as part of the process of initializing a new domain (even if it means that another reboot will be required).

    Since it's the only case where a DC needs to have a unique SID.

    And domain creation is certainly an extra special case. Most potential DCs won't ever be used to perform the initial creation of a windows domain: in general, only 1 DC per domain is supposed to ever have that privilege over the entire lifetime of the Windows-based LAN, which usually means only 1 server per organization will actually ever need to have had a unique SID.

  • by alexschmidt (1026034) on Tuesday November 03, 2009 @11:26PM (#29973032)
    I run VMWare at a college and we typically have the students run a scenario of Primary and secondary DC's. Unless we used NewSID, we had problems. The weird part was, it was intermittent. Some students would create multiple copies of the same image and had no problems, others would have nothing but grief unless they used NewSID.
  • by pyite (140350) on Wednesday November 04, 2009 @12:01AM (#29973280)

    I know for a fact that WSUS (Windows Server Update Services... basically a centralized patch server) would do "weird, interesting" things when two machines tried to check into WSUS with the same SID.

    I don't even work with Windows servers and I happen to know this from engineering some network infrastructure (load balancing) for the folks in our organization who do manage WSUS. Long story short, what they thought was problematic load balancing across WSUS servers was actually the same SID being used from 1,000+ cloned VMs. WSUS thought they were one machine.

  • by Asmor (775910) on Wednesday November 04, 2009 @12:13AM (#29973358) Homepage

    As a student, I worked for the CS department. It was just me and my boss, and we both had extremely limited hours. Thus, we didn't have a whole lot of time or opportunity to figure out how to do things 'the right way' whenever that would change, and just kept doing things as we had been.

    This was a problem when Vista was deployed. Once we got out image to where we wanted, we would ghost it and deploy to about 60 machines. For Vista, we used a KMS (Key Management Server) which is one of the options you have for licensing large numbers of machines. In a nutshell, each machine contacts the KMS and gets a license for itself.

    This was supposed to be strictly limited to volume licensing; thus, the KMS would not activate any machines until it had at least 25 different machines registered to it.

    Now, ideally what would happen is that before you make your image you'd basically set Windows into a 'deployment mode' (not the technical term) where, the next time it's booted, it would go through and reinitialize everything for the machine it's on, and part of this involves generating a unique SID.

    We toyed with this a bit with the time we had, but couldn't get it to a place where we were happy with the results. In particular, we had some issues with networking, IIRC, that means we would have had to go and manually setup every machine for our network.

    TL;DR: All of our machines had the same SID, the KMS only say 1 unique installation even though 60 machines were connecting to it, and Vista wouldn't activate. In order to fix it, we had to change the SIDs for each machine.

    So to say that duplicate SIDs are not a problem is erroneous indeed.

  • Really? (Score:5, Interesting)

    by Sycraft-fu (314770) on Wednesday November 04, 2009 @12:43AM (#29973558)

    This surprises me. I'm not going to say he's wrong, after all the man literally wrote the book on Windows (Windows Internals from Microsoft Press, great book) but it just seems odd. We seem to have problems at work if a system is Ghosted, but not SID walked. It'll join the domain, but exhibit weird problems, like users not able to log in and such. Now maybe GhostWalk does other things too that are what really needs to be done, but it seems to just be a SID change tool.

    Personally I'll keep using GhostWalk until Symantec removes it.

  • by ard (115977) on Wednesday November 04, 2009 @04:53AM (#29975344)

    From the article:

    This is called generalizing the image, because when you boot an image created using this process, Sysprep specializes the installation by generating a new machine SID, triggering plug-and-play hardware detection, resetting the product activation clock, and setting other configuration data like the new computer name.

    Is the product activation clock reset because of Sysprep, or because the SID is changed?

    In other words, could NewSID be used to keep unactivated windows installations running indefinately?

    <conspiracy_theory> Would that be the real reason for the NewSID retirement? What's the rush of removing the download instead of leaving it unsupported? </conspiracy_theory>

Never invest your money in anything that eats or needs repainting. -- Billy Rose

Working...