Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Machine SID Duplication Myth

kdawson posted more than 4 years ago | from the no-harm-in-seeing-double dept.

Windows 201

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.'"

cancel ×

201 comments

Sorry! There are no comments related to the filter you selected.

fp (4, Funny)

Anonymous Coward | more than 4 years ago | (#29972568)

Maybe slashdot should get rid of the dupe sids, too.

Re:fp (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29972600)

Maybe you should eat my scrotum.

Re:fp (0)

UnknownSoldier (67820) | more than 4 years ago | (#29972602)

Ha!

Mod up funny. Although the dupes kind of are one of the running jokes around here.

Re:fp (0)

Anonymous Coward | more than 4 years ago | (#29972620)

But... that would tear a hole in the space-time continuum! Its not meant to be!

Re:fp (0)

Anonymous Coward | more than 4 years ago | (#29972900)

best first post in a long time

Except for Domain Controllers.. (3, Informative)

tensop (1232374) | more than 4 years ago | (#29972610)

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:Except for Domain Controllers.. (2, Informative)

rfunches (800928) | more than 4 years ago | (#29972742)

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.

Re:Except for Domain Controllers.. (5, Informative)

mysidia (191772) | more than 4 years ago | (#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.

Workstations with same SID won't logon (1)

gustavopuy (1524959) | more than 4 years ago | (#29973930)

If I clone Xp workstations with the same SID they can't logon to Active Directory and got an erratic behavior. After a new SID generation all back to normality

Re:Except for Domain Controllers.. (0)

Anonymous Coward | more than 4 years ago | (#29973990)

Yeah, I had this bite me just last week. I created a Windows Server 2008 VM. I cloned it and made it a domain controller. I then took the original VM and joined it to the domain. That machine was really messed up and domain authorizations were failing; for example, no domain admin user could have Admin rights on the client machine. The client machine just would not recognize the domain rights. I then of course realized I forgot to change the SID and then all was okay with the Universe.

Re:Except for Domain Controllers.. (1)

shaitand (626655) | more than 4 years ago | (#29973598)

Yup

first post (1)

lapinmalin (1400199) | more than 4 years ago | (#29972622)

and i didnt use any SID duplication

Well... it WAS a problem... (2, Insightful)

flydpnkrtn (114575) | more than 4 years ago | (#29972624)

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 SID, AD had a hard time distinguishing them for security reasons, much as if two users' SIDs collided...

But who am I to question the great creator of psexec and psinfo, Lord Russinovich :-)

Re:Well... it WAS a problem... (3, Interesting)

ErMaC (131019) | more than 4 years ago | (#29972744)

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:Well... it WAS a problem... (2, Funny)

flydpnkrtn (114575) | more than 4 years ago | (#29972762)

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:Well... it WAS a problem... (2, Informative)

gslavik (1015381) | more than 4 years ago | (#29973712)

Add Sophos enterprise to that list.

Re:Well... it WAS a problem... (5, Informative)

fan of lem (1092395) | more than 4 years ago | (#29972768)

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.

Re:Well... it WAS a problem... (0)

Anonymous Coward | more than 4 years ago | (#29972788)

That was my first thought too. Clients with the same SID is still a problem with the latest WSUS. At a minimum the admin discovery won't recognize multiple machines with the same SID as unique machines so depending on the update time, random machines won't get a patch because the server think it already got it.

Re:Well... it WAS a problem... (2, Informative)

Anonymous Coward | more than 4 years ago | (#29972800)

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

Re:Well... it WAS a problem... (3, Interesting)

pyite (140350) | more than 4 years ago | (#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.

Re:Well... it WAS a problem... (1)

Anpheus (908711) | more than 4 years ago | (#29973704)

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

Re:Well... it WAS a problem... (1)

pyite (140350) | more than 4 years ago | (#29973772)

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

Re:Well... it WAS a problem... (4, Informative)

nabsltd (1313397) | more than 4 years ago | (#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.

Re:Well... it WAS a problem... (0)

Anonymous Coward | more than 4 years ago | (#29973852)

WSUS has it own "WSUS-SID" per client.

Re:Well... it WAS a problem... (2, Informative)

gotpaint32 (728082) | more than 4 years ago | (#29974000)

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.

Re:Well... it WAS a problem... (1)

Macfox (50100) | more than 4 years ago | (#29974398)

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.

WSUS needs unique SIDs (0)

Anonymous Coward | more than 4 years ago | (#29972628)

At least in my experience.

Re:WSUS needs unique SIDs (1)

beav007 (746004) | more than 4 years ago | (#29972930)

WSUS makes up its own SIDs. As long as you don't have two computers with the same SUSClientId, you're fine.

Go Figure (5, Insightful)

Anonymous Coward | more than 4 years ago | (#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'...

Man with a hammer (3, Funny)

NoYob (1630681) | more than 4 years ago | (#29972908)

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:Man with a hammer (3, Funny)

norpy (1277318) | more than 4 years ago | (#29974008)

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 problems in the past. The engineer reluctantly took the challenge. He spent a day studying the huge machine. Finally, at the end of the day, he marked a small "x" in chalk on a particular component of the machine and said, "This is where your problem is." The part was replaced and the machine worked perfectly again.

When the company received a bill for $50,000 from the engineer for his service, they demanded an itemized accounting. The engineer responded briefly: One chalk mark $1. Knowing where to put it $49,999. The bill was paid in full, and the engineer retired again in peace.

Re:Go Figure (1)

kestasjk (933987) | more than 4 years ago | (#29974630)

I think God just takes the piss out of artists and software developers when it comes to work vs reward.

42 (2, Insightful)

Anonymous Coward | more than 4 years ago | (#29972650)

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

ID (1)

pete-classic (75983) | more than 4 years ago | (#29972666)

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

Re:ID (3, Funny)

riff420 (810435) | more than 4 years ago | (#29972708)

Obviously SOMETHING needs to go in that text input box. Duh!

Re:ID (2, Funny)

pete-classic (75983) | more than 4 years ago | (#29973070)

Very nice.

Bill Cosby did a bit, "Why is there Air?" He's well known for being a Doctor of Education, but as an undergrad he was a Physical Education major. His mock reaction to this fact, "Ha, ha. Phys. Ed. You're dumb."

He relates the story of attending a Philosophy class where the titular question is posed. He comically states his surprise at the question. Something like, "Any Phys. Ed. major can tell you that. To fill up footballs, and volley balls, and soccer balls!"

You stand in fine comedic company!

-Peter

Re:ID (2, Funny)

JustOK (667959) | more than 4 years ago | (#29973380)

I had to take Golf Ball Inflation six times before I passed.

Re:ID (0)

Anonymous Coward | more than 4 years ago | (#29973652)

I like Bill Cosby too, but his doctorate is honorary.

Re:ID (2, Informative)

Dahan (130247) | more than 4 years ago | (#29974688)

He has (numerous) honorary doctorates, but he earned his Ed.D.

Duplicate UIDs (2)

l2718 (514756) | more than 4 years ago | (#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 (3, Insightful)

RAMMS+EIN (578166) | more than 4 years ago | (#29973498)

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.

Re:Duplicate UIDs (1)

SpaceLifeForm (228190) | more than 4 years ago | (#29974262)

I've always concluded that Windows can cause problems.

Does not matter what subsystem or module apparently.

Re:Duplicate UIDs (1)

BitZtream (692029) | more than 4 years ago | (#29975122)

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.

It's the usual story (5, Funny)

dbIII (701233) | more than 4 years ago | (#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.

Re:It's the usual story (5, Funny)

flydpnkrtn (114575) | more than 4 years ago | (#29972750)

Based on this post, I move that we change the default Slashdot analogy model from cars to one based around celebrity wardrobe malfunctions. This was simply awesome sir

Re:It's the usual story (0)

Anonymous Coward | more than 4 years ago | (#29973272)

That's one nipple medallion of an idea.

Re:It's the usual story (2, Funny)

jkrise (535370) | more than 4 years ago | (#29973286)

Thanks for a good laugh, Sir! But at least in Britney's underwear, it covers something useful.

Re:It's the usual story (3, Funny)

humphrm (18130) | more than 4 years ago | (#29973336)

Or, its covering of something is useful.

Re:It's the usual story (1)

hitmark (640295) | more than 4 years ago | (#29975408)

more like covering something used...

Google "COMMANDO" (5, Funny)

mosel-saar-ruwer (732341) | more than 4 years ago | (#29973350)

A ggreat deal of Microsoft security is unfortunately just like the underwear of Brittany Spears.

GOOGLE IMAGES: britney spears commando [google.com]

Re:Google "COMMANDO" (0)

Anonymous Coward | more than 4 years ago | (#29973872)

Ohhh! I think Informative would fit quite well. I actually learned something new.

Re:Google "COMMANDO" (1)

mosel-saar-ruwer (732341) | more than 4 years ago | (#29974232)

And yet I got modded "Troll".

Go figure.

Hmm... Pretty sure I ran into an issue somewhere (1)

davidbrit2 (775091) | more than 4 years ago | (#29972690)

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?

Re:Hmm... Pretty sure I ran into an issue somewher (1)

alexschmidt (1026034) | more than 4 years ago | (#29973078)

Absolutely correct! I use VMWare images of Win2k Server et al and we had to use NewSID to avoid problems. Your images have one SID so when you try and run multiple copies, (especially with a Parent/Child DC's) you get problem. For us, it happened about 50% of the time. For some reason, some students could make all kinds of copies of Win2kserver, run them and have no problems.

Re:Hmm... Pretty sure I ran into an issue somewher (3, Informative)

Anpheus (908711) | more than 4 years ago | (#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."

With an important caveat! (5, Informative)

derinax (93566) | more than 4 years ago | (#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.

Re:With an important caveat! (5, Interesting)

mysidia (191772) | more than 4 years ago | (#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:With an important caveat! (1)

gollito (980620) | more than 4 years ago | (#29972952)

I know for a fact that this is an issue with Server 2008 and Exchange 2007. I had a client that cloned all their 2k8 servers from a single image and after they put it into production their Exchange server suddenly stopped authenticating users. Turns out it was a SID related issue. Working with Microsoft support they had me try the NewSID app, which didn't work, so I was left with unjoining the server from the domain, sysprep'ing it, and then joining it backup. This was after 3 days of trying everything else before taking this drastic step. Had the NewSID app worked properly I would have been done within the first hour of working with MS tech support.

Re:With an important caveat! (2, Interesting)

alexschmidt (1026034) | more than 4 years ago | (#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.

Oh, right... that. (3, Interesting)

tverbeek (457094) | more than 4 years ago | (#29972716)

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.

Anon E. Moose (0)

Anonymous Coward | more than 4 years ago | (#29972790)

I personally on recently had found this one. I'm dead set against virtualization when computing power is so cheap and folding@home or seti@home or similar needs more!

Anyway. I had vista issues. Literally identical virtuals and host. Host remained the default SID. Both vista had this run on it. 1 totally blubbered. The other worked well enough to call success. Had to go use sysprep to fix it.

More recently server 2008 and server 2003 issues. newsid worked fine for me. Everyone else had issues. All requiring sysprep.

So inevitably it comes down to... why not update sysprep and use that instead? Or even... upgrade the issue of SIDs themselves?

Not Convinced (0)

Anonymous Coward | more than 4 years ago | (#29972796)

I have observed problems with duplicate SIDs on a small Windows domain (10-15 computers).
The set of workstations with the duplicate SIDs were constantly having issues printing to the shared printer.
The problems were intermittent, and the shared printer would work for a long time before the problem happened.
This never happened on any of the systems with unique SIDs.

It is no myth (3, Insightful)

blake1 (1148613) | more than 4 years ago | (#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.

Re:It is no myth (1)

jarocho (1617799) | more than 4 years ago | (#29973378)

Sysprep and NewSID are very different tools, which ultimately lead to very different conclusions for the machine(s) either are applied to. I've never used sysprep when NewSID would suffice.

I think retiring NewSID is shortsighted. As folks here have already indicated, WSUS is the prime example I can immediately point to. I'm sure there are others. Perhaps Russinovich has never worked with load-balanced servers built from the same clone/image/template, which end up in different WSUS groups (Night A versus Night B, and so on). But in the absence of NewSID or a replacement, the task of separating one from the other becomes a lot more of a challenge than it has to be. What a shame.

Re:It is no myth (0)

Anonymous Coward | more than 4 years ago | (#29974074)

WSUS doesn't use the SID as the ID from everything I can see, we have had duplicates and it is caused by a WSUS client ID being duplicated in imaging and is easily fixed through deleting the registry entry for it.

Re:It is no myth (1)

cantcomplain (1604473) | more than 4 years ago | (#29973962)

AD SID and machine SID are different. If you join a system to the domain and then clone it, you'll have two identical *domain* SIDs and problems related to that. If you RTFA and comments, they're talking about having duplicate *machine* SIDs. If machineA connects to machineB, it uses either credentials from the domain or the destination system, so MachineB having a duplicate SID as the MachineA isn't relevant because they're not being compared or checked against each other.

I've had problems (1)

Deathlizard (115856) | more than 4 years ago | (#29972844)

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 at image completion time to deploy and never had a problem since.

At some point, SID's may have been used for legacy domains. There is a chance that Active Directory Domain's removed SID importance and that's why it doesn't matter anymore.

Re:I've had problems (1)

parlancex (1322105) | more than 4 years ago | (#29972984)

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 dozens of domains in the same forest and issues are nowhere to be found.

In other words... (5, Insightful)

jkrise (535370) | more than 4 years ago | (#29972850)

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

Re:In other words... (1)

heffrey (229704) | more than 4 years ago | (#29974714)

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.

Isn't it ridiculous? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#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"

Finally validation! (3, Funny)

shemp42 (1406965) | more than 4 years ago | (#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!

Re:Finally validation! (1)

bigstrat2003 (1058574) | more than 4 years ago | (#29973802)

Your "in your face" message might be more effective if you delivered it to your co-workers, rather than the internet. :P

Good to finally have confirmation! (1)

KingRobot (703860) | more than 4 years ago | (#29972994)

I too, have known this for a while... I've been running three pairs of Domain Controllers that are exact clones of each other (apart from the network name), for the last 6-7 years. While I had read the occasional documentation that claimed it would cause problems, I never experienced any, nor could I found anything that would say what the problems might be or how they would be caused. Good to know my intuition and testing held out to be true!

I seem to remember ... (0)

Anonymous Coward | more than 4 years ago | (#29973090)

that it DOES make a difference when REMOVING a PC from a domain, at least 2000 or XP machines. We didn't run newsid at first and found that by removing ONE PC from the domain it removed them ALL from the domain even when the PC names where different.

Things might of changed with a 2K3 / 2K8 domain with Vista and WIn 7 clients.

Great. (4, Insightful)

Wumpus (9548) | more than 4 years ago | (#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?

Re:Great. (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29973246)

No, not at all. Despite the Borg icon, employees of Microsoft do not share a collective mind. Different people understand different parts of the system; nobody or almost nobody understands it all. Every large company is the same way.

Re:Great. (4, Insightful)

Wumpus (9548) | more than 4 years ago | (#29973422)

But not every product is equally complex. I can't think of a feature that's critical to the proper basic administration of a Unix network that's equally poorly understood, to the point that it's considered news when someone figures it out after 10 years.

The feeling I often get when developing for Microsoft's platform is that it is gratuitously complex. Complex APIs are routinely replaced with new, more complex ones. API calls that take a dozen or so arguments, with some of them pointing to structures containing dozens of members, return error codes that complain of a bad argument - good luck finding out which one of the 30 or so the system found to be offensive. Bugs go unfixed for years. It's all rather unpleasant, really.

Re:Great. (0)

Anonymous Coward | more than 4 years ago | (#29973848)

I get the same feeling when using Linux. I find that X.org crashes apparently at random and I try to run some full screen games and I happen to lost all my data (i.e. gnome apps that were running - crash). But dont worry ! the kernel didnt crash ! so it all must be fine !

Linux just feels an inferior clone of unix (hell, is there anything that linux distros wont copy from earlier successful proprietary software?) and held together by duct tape..

Now if you're a competent user you might be able to pull it off. Seeing as how its only successful in the server space - where dedicated professionals are maintaining the system - and a failure in the desktop space - where you don't get competent people operating the system - shows how poorly integrated it is for average users.

Re:Great. (1)

0ld_d0g (923931) | more than 4 years ago | (#29974076)

The feeling I often get when developing for Microsoft's platform is that it is gratuitously complex.

What Microsoft platform are you talking about? Win32? DirectX? XNA? .NET? F#? MFC? ATL? WPF? PowerShell? Silverlight?

Those are just APIs anyway. The "Microsoft platform" here is meaningless. The Operating system just sends machine opcodes from compiled binaries to the processor and doesn't care which tools you used to create the binary. (Yes .NET type languages have another translation abstraction from bytecode to machine instructions but its essentially the same)

The process by which you get compiled code is determined by which toolset you use, which language, which library, runtime etc, etc. So whats you're beef here?

That every developer tool (whether its written by Microsoft or others) and programming library and language that can be used to create a compiled binary file on windows is "gratuitously complex"? I wont be so bold as to presume you are stupid enough to make that claim, but what you said sounded to me like you are not basing your opinions on rational thought.

Re:Great. (1)

that this is not und (1026860) | more than 4 years ago | (#29974476)

I think it was a general indictment of the Closed Source approach to software development and maintenance. When faced with an unknown binary, there's not a heck of lot you can do but poke away at it hopefully.

The process by which you get compiled code is determined by which toolset you use, which language, which library, runtime etc, etc. So whats you're beef here?

The process is key. That's what every modern business expert will tell you. And do you know what the documentation of the process for a piece of software is? Do you? It's the Source Code. Yes, that includes the Makefile and documentation of the toolchain used for the build.

When businesses figure this out, slop slingers like the boys in Redmond are in deep trouble.

Re:Great. (1)

0ld_d0g (923931) | more than 4 years ago | (#29975386)

When faced with an unknown binary, there's not a heck of lot you can do but poke away at it hopefully.

Thats true from a user standpoint, but the OP was talking about it w.r.t to being a developer.

And do you know what the documentation of the process for a piece of software is? Do you? It's the Source Code. Yes, that includes the Makefile and documentation of the toolchain used for the build.

I don't get how that's relevant to the point at hand. Anyway, I'm not debating the process. I just don't get the argument against the NT platform here that the OP was trying to make. There exist poor tools and libraries on any platform. But blaming the platform for the poor tools? Heck if you think all tools made by Microsoft are horrible.. well. don't use them. That doesn't make NT bad at what it does. Also its a pretty weaksause argument when you bring up number of arguments to APIs as an example of "gratuitous complexity" (Also, AFAIK, there isn't a Win32 API offhand that takes 30 arguments)

Re:Great. (0)

Anonymous Coward | more than 4 years ago | (#29974902)

What Microsoft platform are you talking about? Win32? DirectX? XNA? .NET? F#? MFC? ATL? WPF? PowerShell? Silverlight?

Win32, I'd imagine, since it's the platform from Microsoft that's in discussion.

The "Microsoft platform" here is meaningless.

He didn't say 'the microsoft platform', he said 'microsoft's platform'. That is, one of (presumably many) platforms to come from Microsoft.

Re:Great. (0)

Anonymous Coward | more than 4 years ago | (#29974254)

The problem being that a lot of the essential stuff is now only understood by people who are either 6 feet under or probably retired in isolation somewhere. Which leads to dumbass stuff like the "let's replicate all the bugs because we're not sure how the code does it" tags in ooxml.

Re:Great. (1)

osu-neko (2604) | more than 4 years ago | (#29973256)

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?

Par for the course. Welcome to the tech world. At most companies there's a bunch of stuff running that no one who currently works there knows how it works, they're working of the notes of the people who left, who made those notes while trying to figure out how it works, after the generation before them already quit...

Suddenly the part of Foundation where planets are just working to maintain stuff they don't understand doesn't seem so far fetched...

I have been saying this for years. (0)

Anonymous Coward | more than 4 years ago | (#29973236)

The machine receives a new sid when joins the domain.

my NewNewSID program fixes these problems (1, Funny)

Anonymous Coward | more than 4 years ago | (#29973356)


#include <stdio.h>

int main()
{
    printf( "%d\n", 42 );
    return 0;
}

Duplicate SIDs are a huge problem with KMS (2, Interesting)

Asmor (775910) | more than 4 years ago | (#29973358)

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.

KMS has nothing to do with SID - it's the CMID. (1, Informative)

Anonymous Coward | more than 4 years ago | (#29974400)

Sysprep does *many* important things, not just change the machine SID.

For example, it sets the machine up to recreate a new machine SID *and* it sets itself up to rejoin the domain, which gives it a new domain account and hence, a new domain-SID for the machine (tehnically, SID of the computer's account on the domain.)

SYSPREP also changes the CMID of the machine. It's this CMID that has to be changed for KMS to see it as a seperate computer.

http://support.microsoft.com/kb/KB974176

So, yeah. Duplicate SIDs are NOT a KMS problem, but duplicate CMIDs are. Running SYSPREP fixes it not because SYSPREP changes the SID, but because SYSPREP *also* changes the CMID.

Really? (4, Interesting)

Sycraft-fu (314770) | more than 4 years ago | (#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.

Re:Really? (1)

Spad (470073) | more than 4 years ago | (#29975274)

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.

but they have the source! (1)

Stardate (13547) | more than 4 years ago | (#29973654)

can't they just grep through it for all references to the SYSID and see what decisions are based upon it? i wish it was as simple as this...

Re:but they have the source! (0)

Anonymous Coward | more than 4 years ago | (#29974266)

can't they just grep through it for all references to the SYSID and see what decisions are based upon it? i wish it was as simple as this...

maybe they have some proprietary binary files in their build, and none dares to touch :)

sysprep already does this for you (0)

Anonymous Coward | more than 4 years ago | (#29973964)

When using Sysprep the tool will automatically generate a new (clean) SID for the cloned machine at first boot, if you intend to create clones rather than a backup image for example where you would want to restore the original SID. the exception is when the -NOSIDGEN argument provided with sysprep is used, it will force the cloned machine to retain the SID of the original system, soemtimes this is desirable,sometimes not. Not sure how someone would confuse this, its clearly stated in the documentation for sysprep since 2000. Literally 30 seconds on google and Voila, RTFM folks.

So who's got a copy of the final release of NewSID (1)

argent (18001) | more than 4 years ago | (#29974080)

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?

Closed source (1)

rolfc (842110) | more than 4 years ago | (#29974298)

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?

Theological disputation... (0)

Anonymous Coward | more than 4 years ago | (#29974724)

Maybe it's because I have a cold, but this seems reminescent of an old heresy [wikipedia.org] , and about as silly to non-believers.

Ignorant and inconsiderate (3, Informative)

BitZtream (692029) | more than 4 years ago | (#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.

NewSID allows for activation reset? (5, Interesting)

ard (115977) | more than 4 years ago | (#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>

May this harm SAMBA (0)

Anonymous Coward | more than 4 years ago | (#29975392)

Does any version of SAMBA (either out there or in progress) presume that all SIDs are unique ?

I notice that MS only says that none of *their* software does ?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?