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:
  • fp (Score:4, Funny)

    by Anonymous Coward on Tuesday November 03, 2009 @10:22PM (#29972568)
    Maybe slashdot should get rid of the dupe sids, too.
  • I found that unless you change the SID on a computer before becoming a (virtual or otherwise) windows Domain Controller, it will cause all sorts of issues. That is, at least in windows 2000 and 2003.
    • Re: (Score:3, Informative)

      by rfunches (800928)

      Agreed...when I was reading up for one of the Server 2008 AD MCTS exams, I cloned a base VM image of Server 2008 to simulate two DCs, a file server, an IIS/application server, etc. I had to download and run NewSID because every server I joined to the domain (i.e. the "primary" DC) had problems getting joined correctly. I don't recall the specifics but Server 2008 did throw a hissy fit and I had to run NewSID on each VM prior to joining before I could do anything else.

    • by mysidia (191772) on Tuesday November 03, 2009 @10:58PM (#29972834)

      It's not for domain controllers in general it's for the very first domain controller used to initialize a brand new domain. You want to never create a new server with that same SID again. The first domain controller's SID is special, it will be used to generate the domain SID. From then on, all subsequent domain controllers promoted in the domain will have the same machine SID.

      So you're good if you create the very first DC with a unique install, and clone all your other servers from an image.

      As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s randomly generated by Domain setup, 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. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems. All accounts in a Domain, including computers, users and security groups, have SIDs that are based on the Domain SID in the same way local account SIDs are based on the machine SID, but the two are unrelated.

      ...

      issue is if a distributed application used machine SIDs to uniquely identify computers. No Microsoft software does so and using the machine SID in that way doesn’t work just for the fact that all DC’s have the same machine SID.

      • Mark Russinovich seems very knowledgeable to me, but I think he has made a mistake. There is general agreement that NewSID is necessary.

        For example, we clone hard drives and leave the cloned drive in the system as a backup. For that, my understanding it that it is necessary to change the SID. Since those computers are cash registers, they are not attached to a domain. If they were attached to a domain, and the domain controller failed, the user might not be able to ring a sale. We could use Sysprep, but
        • Part of Russinovich's point is that Windows boxes don't interact with one another by SID, only by username/password credentials. Quoth TFA:

          Windows doesn’t allow you to authenticate to another computer using an account known only to the local computer. Instead, you have to specify credentials for either an account local to the remote system or to a Domain account for a Domain the remote computer trusts. The remote computer retrieves the SIDs for a local account from its own Security Accounts Database (SAM) and for a Domain account from the Active Directory database on a Domain Controller (DC). The remote computer never references the machine SID of the connecting computer.

          In other words, it’s not the SID that ultimately gates access to a computer, but an account’s user name and password: simply knowing the SID of an account on a remote system doesn’t allow you access to the computer or any resources on it. As further evidence that a SID isn’t sufficient, remember that built-in accounts like the Local System account have the same SID on every computer, something that would be a major security hole if it was.

          So if the design of your network layout is that you allow the computers to access one another with common usernames and passwords, Russinovich is saying that your layout will work even if all the boxes have identical SIDs. Running NewSID is apparently unnecessary work, except in cases of keeping the SID of the first DC on a new AD domain from matching those on other boxe

          • Look at the comments on his article. Numerous people say it is incorrect.

            What about the case where there is a drive in a system that is a clone of the system drive?

            In my opinion, there should have been an announcement that NewSID would be removed long before it was actually removed. That would have given time for people to make comments. It also would have given time to change documents on the Microsoft web site that say that having a different SID is important.
        • What is the specific problem that occurs in your scenario? You describe a lot of organizations that say it's bad to dupe SID's but you don't describe the failure mode that occurs when SID's are duped.

          It seems like the original article is saying that everyone says duped SID's are bad, but no one can produce a failure scenario / test case that documents it. Please provide some evidence so we can call check out your scenario.

    • by shaitand (626655)

      Yup

  • 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. Not sure if they've resolved the problem in later versions of WSUS...see this thread for an example: http://www.neowin.net/forum/lofiversion/index.php/t343182.html [neowin.net]

    I thought that the problem was defined as being based around locking a specific machine down with Group Policy... when two machines have the same
    • by ErMaC (131019) <ermac@ermIIIacst ... inus threevowels> 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 =)

      • Re: (Score:3, Funny)

        by flydpnkrtn (114575)
        I got that impression from the post as well.. "Umm I haven't tested it with NT 6.0 er Vista, and I don't really feel like testing it with NT 6.1 er 'Windows 7,' so we're just gonna retire the thing..."
      • Re: (Score:2, Informative)

        by gslavik (1015381)

        Add Sophos enterprise to that list.

        • by Petaris (771874)

          I don't have an issue with Sophos Endpoint Security and I have never changed my SIDs. Many people told me that it would break things but I never ran into an issue and always questioned why it had to be done.

      • by rikkards (98006)

        With SMS I don't think it was the SID but the SMS GUID where you have issues. An example is if there are more than one machine with the same SMS GUID and one of them is in a direct membership collection and assigned the package, both will get the advertisement.

        I don't see the point in NewSID (never heard of it before either but I will have to see what it does) When imaging you should be running sysprep, there is a lot more that it does than just blow away the SID.

      • by jtdennis (77869)

        At least the last few McAfee Enterprise antivirus products have generated a unique sid and stored it in the registry (I think somewhere around HKLM\Software\Network Solutions\ePolicy Agent)

    • by fan of lem (1092395) on Tuesday November 03, 2009 @10:49PM (#29972768) Journal

      Did you mean the SusClientId? AFAIK this is the only identifier WSUS uses to distinguish between computers (they also don't have to be on the same domain).

      On new clones you only need to delete the SusClientId key under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate; the update service will take care of assigning the machine a new ID.

      • by Darth_brooks (180756) <clipper377@NoSpAm.gmail.com> on Wednesday November 04, 2009 @10:42AM (#29977986) Homepage

        I ran into this same issue. I've now got a batch script that runs at first logon (post-reimaging) that resets the client ID. Probably overkill at this point (the bad image that was causing this has long since been redone), but it ensure that every machine checks in with a fresh key.

        net stop wuauserv
        reg delete "HKEY_LOCALMACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Windowsupdate" /v SusClientId /f
        net start wuauserv
        wuauclt.exe /resetauthorization /detectnow

        That does require a more windows update client (the old wuauclt only accepted a couple of options, including detectnow, and ignored the reset. If you typed wuauclt.exe /gogetmeabeerandasteak it wouldn't throw an error, it just looked like it ran).

        There's a distinct difference between the SID and the SusClientID.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      It is a common misconception that duplicate SIDs create the issue where multiple PCs check in as the same PC (with a rolling name) in WSUS. The WSUS ID is in fact stored here: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate]

      as the SusClientId and SusClientIdValidation keys.

      It can and should be reset independently of SIDs to have PCs correctly check-in to WSUS

      • Yep, we had this problem. I wrote a quick script to delete these keys and regen new ones. The problem was quickly solved.

    • 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 Anpheus (908711)

        This seems strange because it manages multiple domain controllers fine, and they all have the same SID.

        • by pyite (140350)

          So the behavior observed in our case was the clients get updated, but WSUS thinks only 1 client ever connected.

          • by nabsltd (1313397) on Wednesday November 04, 2009 @02:11AM (#29974332)

            This is absolutely correct.

            Identical machine SIDs and WSUS identifiers (stored in the registry) don't stop the updates from being applied...they just cause the WSUS reports to show only the details for the last cloned machine that connected.

            • by jimicus (737525)

              This is absolutely correct.

              Identical machine SIDs and WSUS identifiers (stored in the registry) don't stop the updates from being applied...they just cause the WSUS reports to show only the details for the last cloned machine that connected.

              Oh good. So if Machine A fails to apply a patch for whatever reason and machine B comes along 5 minutes later with exactly the same SID but gets on fine.... you'll never know about machine A?

              • by rikkards (98006)

                Yep. ITMU and SMS is the same thing.

              • Oh good. So if Machine A fails to apply a patch for whatever reason and machine B comes along 5 minutes later with exactly the same SID but gets on fine.... you'll never know about machine A?

                No. If Machine A fails to apply a patch for whatever reason and machine B comes along 5 minutes later with exactly the same WSUS ID but gets on fine you'll never know about machine A. WSUS ID and SID are not the same thing. Failure to properly sysprep your image (or at least manually delete the key) is what causes the issues people are describing, nothing to do with the SID whatsoever.

    • Re: (Score:3, Informative)

      by gotpaint32 (728082) *
      As fan of lem mentions, the issue you state only happens if the wsus regkey is present. The regkey can only be present if you image a machine that has registered with WSUS. Best practice is to make sure that the machines that you image does not have any group policies applied to it.
    • by Macfox (50100)

      I was under the impression this was the case. I found even after syspreping a machine, if the WSUS keys were not cleared, it wouldn't register with the WSUS server. The fix is to stop the WU service, clear the keys then sysprep....So I found anyway.

      • by rikkards (98006)

        Catch is if you ever need to call Microsoft they would tell you that isn't a supported fix. We had a similar issue with ITMU last year where workstations were not getting a SUSClientID at all and I mentioned that and the tech (nice guy) informed me not to do that although it had worked there was a bigger issue. Basically the problem was that the WindowsUpdateAgent exe that introduces ITMU has a bug that if the DLL is same or newer it will not reregister the DLL after installation unless you used the /force

  • Go Figure (Score:5, Insightful)

    by Anonymous Coward on Tuesday November 03, 2009 @10:29PM (#29972640)

    This is coming from the same company that billed my employer to the tune of $250,000 USD in order to create a utility that would move a user profile from the old location to the new one after the user account had been moved to a new NT domain.

    And then we found the moveuser.exe utility on the server resource kit and asked them what the $250,000 was for. Not that anyone who pays two hundred and fifty thousand dollars for a few lines of vbscript is smart (the phbs wanted something bonafide), but I'm just sayin'...

    • And then we found the moveuser.exe utility on the server resource kit and asked them what the $250,000 was for. Not that anyone who pays two hundred and fifty thousand dollars for a few lines of vbscript is smart (the phbs wanted something bonafide), but I'm just sayin'...

      A company was having a problem with one of their machines, so they called in this specialist. The specialist came in, examined the machine, pulled out a hammer and tapped the machine. The specialist then produced a bill for $1,000. When asked why he was charging $1000 for just tapping he machine with a hammer, the specialist replied, "You're paying for me to know where to tap the machine with the hammer."

      The bill was paid.

      • Re: (Score:3, Funny)

        by norpy (1277318)

        I believe the anecdote is this:

        There was an engineer who had an exceptional gift for fixing all things mechanical. After serving his company loyally for over 30 years, he happily retired. Several years later the company contacted him regarding a seemingly impossible problem they were having with one of their multimillion-dollar machines. They had tried everything and everyone else to get the machine to work but to no avail. In desperation, they called on the retired engineer who had solved so many of their

        • I can see where it makes sense to tailor the anecdote to higher-end professions, but the version that's always stuck with me and been one that anyone can relate to is the auto mechanic.

          A driver takes his car to the mechanic to find out why the car is making a strange noise and running rough. The mechanic says he will look at it. He opens the hood, listens and then grabs a hammer from his toolbox and hits the engine block. The car quits running rough and the noise goes away.

          The mechanic turns to the custo

          • These anecdotes are all just examples of inefficient markets. If there are lots of people who have an answer, you can pay any one of them for the answer and the pricing is efficient. If supply is low or you don't know where to look for suppliers, pricing is inefficient, and supply-side pricing ensues (similar to monopolies).

            You don't pay someone a pile b/c they know where to hit a machine. You pay them a pile b/c you can only find that one person who knows where to hit it, and they can gouge for all your wo

    • by kestasjk (933987) *
      I think God just takes the piss out of artists and software developers when it comes to work vs reward.
  • 42 (Score:2, Insightful)

    by Anonymous Coward

    So if SIDs are mostly irrelevant, why bother with them at all? Why not just always have them the same number (e.g., 42)?

  • How is it an ID if reuse in the same context has no ill effects? What does it mean to identify something if all things can have the same ID?

    Something is missing here.

    -Peter

  • by l2718 (514756) on Tuesday November 03, 2009 @10:34PM (#29972676)
    So the "best practice" for MS-Windows was to randomly generate UIDs to avoid user accounts on different machines from having the same UID? This would have made sense had NFS been common, where indeed duplicate UIDs are an issue. But windows does not support NFS mounts -- and SMB mounting is based on a local account on the remote machine. There must be some subtlety here, or else why has this taken years to figure out?
    • Re:Duplicate UIDs (Score:4, Insightful)

      by RAMMS+EIN (578166) on Wednesday November 04, 2009 @12:36AM (#29973498) Homepage Journal

      The "subtlety" here is that Windows is extremely complex. I don't think anybody knows exactly how it works. Given that, it is hard to determine conclusively whether something can cause problems or not. Without that knowledge, it is best to err on the safe side.

      • I've always concluded that Windows can cause problems.

        Does not matter what subsystem or module apparently.

      • by tb3 (313150)

        The "subtlety" here is that Windows is needlessly complex.

        There, fixed that for you. :-P

        • by Panaflex (13191)

          The "subtlety" here is that Windows is needlessly complex

          I believe the correct description is "a vain attempt to obfuscate the true meaning of certain security details, which were chosen over provable, known-good techniques."

          But I'm just a security software developer, what would I know?

    • by BitZtream (692029)

      Just for reference, all my NT servers are happy to speak NFS, Windows Services for Unix or whatever the new name for it is after Win2k3.

  • by dbIII (701233) on Tuesday November 03, 2009 @10:34PM (#29972684)
    A ggreat deal of Microsoft security is unfortunately just like the underwear of Brittany Spears.
    If it's even there at all it's needlessly complex and frilly, looks good without actually covering much and is far too easy to get around or remove completely.
    The excessive complexity for no good reason of the SID and the way UIDs are implemented on that array of platforms are a good example of this.
  • I distinctly remember having problems joining two Windows 2003 VMs (using copied disk images) to a Windows 2003 domain (also running on a VM using that same copied disk image). I was setting up a test environment for SQL Server 2005 clustering at the time. I recall there was a very specific reason that I ended up using NewSID on those VMs. Anybody able to jog my memory/correct me?
    • by Anpheus (908711) on Wednesday November 04, 2009 @01:03AM (#29973774)

      You should sysprep the machines to reset their state before joining the machines. Basically, you should create a stock VM that is your disk image right after a "sysprep" and then NEVER EVER do anything with that. Clone it, complete the setup process, and join that cloned machine to the domain.

      So in your case, you should have installed each VM from the ISO/CD and joined the domain, or used a first sysprepped disk image, cloned that twice, and used the two clones to join the domain.

      The reason is that sysprep does the necessary work to separate two machine's identities in a more significant way than just the SID.

      Microsoft's policy is you should never clone a disk image in a domain environment without first running sysprep. NewSID was just a way of doing "sysprep lite."

    • You need to make sure the image wasn't joined to the domain and that each new copy does it's own join.

      The domain SID in a domain joined image will cause problems.

      Russinovich's post is about the machine SID which is not the same thing as a domain SID.

    • I remember back around 99/00 we were cloning a ton of machines to QA boxes and server stuff. NT server maybe - hard to remember. We tried cloning without SID removal and the machines didn't work right. I can't remember what exactly the problem was, but possibly joining to a domain. We paid some consultant to come in, they informed us that we're idiots and can't just clone these machines like that. They brought ghost to the problem, swapped in new SID's and the problems went away. I can't remember all the de

  • by derinax (93566) on Tuesday November 03, 2009 @10:35PM (#29972694)

    "As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s randomly generated by Domain setup, 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. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems. All accounts in a Domain, including computers, users and security groups, have SIDs that are based on the Domain SID in the same way local account SIDs are based on the machine SID, but the two are unrelated."

    The low ramifications of this as mentioned above may have changed post Win2K and XP. This particular caveat governed our processes as system deployment specialists for Microsoft corporate events. We had to make sure that any potential DC had a unique SID even before the machines were promoted to DC, otherwise we saw (verifiably!) many issues with Workstations failing to join the domain. I seem to recall other more esoteric issues with older Microsoft server products, but that may be delusions based on the mass hysteria we had about unique SIDs at the time.

    • 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.

    • Re: (Score:2, Interesting)

      by alexschmidt (1026034)
      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 DangerousDriver (752795) on Wednesday November 04, 2009 @05:15AM (#29975466)

      Here's what happens when a DC and member server are both cloned from the same base image with identical SIDs:

      Event Type: Error
      Event Source: NETLOGON
      Event Category: None
      Event ID: 5516
      Date: 04/11/2009
      Time: 08:52:35
      User: N/A
      Computer: SERVER01
      Description:
      The computer or domain SERVER01 trusts domain TESTDOMAIN. (This may be an indirect trust.) However, SERVER01 and TESTDOMAIN have the same machine security identifier (SID). NT should be re-installed on either SERVER01 or TESTDOMAIN.

      For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp [microsoft.com].

  • 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.

  • It is no myth (Score:3, Insightful)

    by blake1 (1148613) on Tuesday November 03, 2009 @10:53PM (#29972806)
    Speaking from experience, having two machines with the same SID on a single Domain you will have issues related to the computer account in Active Directory. Remove one of these computers from the Domain and the others will experience Netlogon errors and various other issues as a result. Although NewSID may no longer be relevant due to lack of Vista/2008/7/2008R2 support, you should always sysprep /generalize to prevent these issues from occuring. Not too sure why an MS blogger would have this stance, I've seen it numerous times (10+) with my own eyes. The fix is to either perform an offline workgroup join and generate new SID's on all but 1 affected machine, or to remove machines, NewSID all but one, and rejoin the Domain.
  • I ran into problems in the past.

    When windows 2000 was first released, at my old job we did a complete deployment of Win200 on an NT4 server domain not knowing anything about sysprep or SID's. Every once in awhile we noticed that machines would randomly freeze for no reason. Looking on the net we found other people running into the same issue and found that resetting the SID's would fix the issue. After running sysprep on all of the PC's in the labs, the freezing stopped completely. We then just used sysprep

    • Correlation is not causation. Sysprep does a number of other things with a large impact on the system and registry, regenerating the system SID is just one of them. Where I work we were deploying sysprep'd images for our workstations which was increasing setup times and causing a few other issues. I insisted on setting up our images sans sysprep and that SID duplication was not an issue in any practical sense for workstations. Fast-forward 3 years later and we've deployed hundreds of workstations across doz
      • by rikkards (98006)

        This is correct.
        Where I work we had a bunch of local admins who were pushing out File and Print Servers but not sysprepping. What they would do is bring the machine online and then rename it. As far as they were aware everything was working fine. However, we were also monitoring the servers through SNMP and their dns name was always coming up as the original machine so all of a sudden there were about a dozen machines all named the same. We contacted them and they sysprepped the boxes and everything turned

  • In other words... (Score:5, Insightful)

    by jkrise (535370) on Tuesday November 03, 2009 @10:59PM (#29972850) Journal

    Microsoft is now my employer, and I have no reason to cater to the needs of the user community anymore.

    • by heffrey (229704)

      He's been at ms for a while now sysinternals still going strong and I reckon it's far better having him on the inside than on the outside.

  • by shemp42 (1406965) on Tuesday November 03, 2009 @11:06PM (#29972898)
    I have said this for years, glad its finally being widely accepted. My coworkers when ghosting machines would be fanatical about changing the SId's. I have a bad memory and would often forget to change them with no problems. I finally just started skipping the step of changing SID's and never had any adverse issues. When I told me coworkers about this they would rattle off a liteny of problems that I "could" encounter. After 10 years its nice to know I was right all along. So now a drum roll please...... IN YOUR FACE....MY COWORKERS!
    • Your "in your face" message might be more effective if you delivered it to your co-workers, rather than the internet. :P
  • Great. (Score:5, Insightful)

    by Wumpus (9548) <IAmWumpus AT gmail DOT com> on Tuesday November 03, 2009 @11:39PM (#29973124)

    Doesn't it bother anyone else that even Microsoft doesn't have a clue how the OS they developed works anymore? That something like this is even an issue?

  • 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 Spad (470073)

      As others have stated, Sysprep does more than just changing the SID (In fact you can tell Sysprep not to regenerate the SID if you want to). Just because duplicate SIDs aren't an issue doesn't mean that you won't have problems if you fail to Sysprep machines before deployment.

  • Given that it will undoubtedly be necessary to NewSID machines after all, who's got a copy of NewSID?

    And, um, you know... this wouldn't be a way for Microsoft to discredit Ghosting?

    • Given that it will undoubtedly be necessary to NewSID machines after all, who's got a copy of NewSID?

      http://thepiratebay.org/details.php?id=3504780 [thepiratebay.org]
      This is a snapshot of all of the SysInternals utilities made immediately after Microsoft purchased the company. I don't know which version of NewSID is in it (I'm downloading it myself right now). Hopefully, someone will create a torrent containing the final version of NewSID and put it somewhere.

      And, um, you know... this wouldn't be a way for Microsoft to discredit Ghosting?

      Actually, I'm wondering exactly who made the "occasional reports that some Windows component would fail after NewSID was used". Other people are speculating that res

  • Obviously this has gone undetected so long because of the lack of understanding of the issue in general and the users lack of access to the code in special. How many of these issues are still hidden?
  • by BitZtream (692029) on Wednesday November 04, 2009 @04:29AM (#29975166)

    Not so much of Mark, if he doesn't want to maintain it, thats fine, it was free, I get it.

    However ... this is typical of MS.

    They tell us (developers) that the sid will be unique. We write software that expects this and uses the sid as a unique ID.

    Now they come along and say 'naaa, its not important to be unique, use the same sid all you want, no one will notice!'

    And then I have to say ... thank god for real OSes where backwards compatibility is a rule for a reason, not just because they need it to maintain compatibility. They throw corner cases to the wind and go back on something they've said for years, completely ignoring the fact that people have built things based on something they said was a requirement.

    This is the forth change that will break (or potentially in this case) software I have to maintain. Two patches that remove existing functionality in the name of security with the argument that 'no one uses it that way', to which Google can clearly show to be wrong. Even better is that one of them, a change to the DHTML control breaks some of their own apps, OWA for instance.

    Its fucked up when you have to find a hack via Google to fix a bug in MS software that they say doesn't effect anyone ... except everyone that uses one of their more popular clients. Their response is 'patch exchange' which breaks OTHER things.

    STOP

    CHANGING

    BINARY

    COMPATIBILITY

    you worthless fucks. Yes, I'm annoyed.

    • Re: (Score:3, Insightful)

      by DrXym (126579)
      I think you would be hard pushed to find any OS which tried to maintain the level of backwards binary compatibility as Windows has traditionally provided. Sure some things break from release to release, but generally the majority works extremely well. Given the hideous complexity of Windows this is nothing short of a minor miracle.
      • by BitZtream (692029)

        Run Solaris or AIX some time.

        Windows is better than a free OS, but its at the bottom of the barrel for commercial OSes.

        Solaris wills till run most SunOS apps that weren't too tightly integrated. Show me a working OS/2 or Win1/2/3 app in Windows XP or Vista/Win7

  • 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>

  • I'll miss NewSID (Score:5, Insightful)

    by Darkon (206829) on Wednesday November 04, 2009 @06:37AM (#29975938)

    Not that I ever used it to generate a completely new SID, but what I did find it invaluable for was to set a machine's SID back to its old value after a re-install. This did away with the need to change the ownership on all of the user's files still on the hard drive and meant that most of the time their user profile would just keep on working as if nothing had changed.

    • Not that I ever used it to generate a completely new SID, but what I did find it invaluable for was to set a machine's SID back to its old value after a re-install. This did away with the need to change the ownership on all of the user's files still on the hard drive and meant that most of the time their user profile would just keep on working as if nothing had changed.

      So, if you clone them all with the same SID you'd be better off, right?

  • by Yvan256 (722131)

    Microsoft bought Commodore? When did that happen?

  • ....What would BILL do?!?!?!?!??

In any formula, constants (especially those obtained from handbooks) are to be treated as variables.

Working...