Slashdot Mirror
The Machine SID Duplication Myth
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.'"
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.
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
:-)
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
Here's to the crazy ones
At least in my experience.
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'...
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
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?
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?
"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.
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.
http://alternatives.rzero.com/
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?
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.
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 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.
In Soviet Russia, Trojan exploits YOU!
Microsoft is now my employer, and I have no reason to cater to the needs of the user community anymore.
If you keep throwing chairs, one day you'll break windows....
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"
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!
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.
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
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!
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.
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.
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?
The machine receives a new sid when joins the domain.
A ggreat deal of Microsoft security is unfortunately just like the underwear of Brittany Spears.
GOOGLE IMAGES: britney spears commando
#include <stdio.h>
int main()
{
printf( "%d\n", 42 );
return 0;
}
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.
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.
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...
"... I declare our city to be a free and independent state to be named Tri-Insula!" --Fernando Wood, Mayor of NYC 1861
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."
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
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.
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?
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?
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.
Maybe it's because I have a cold, but this seems reminescent of an old heresy, and about as silly to non-believers.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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>
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 ?
"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."
So no one at MS ever wrote a specification of how SIDs are supposed to work? That could be checked against the code and the behaviour of test systems.
Bah Microsoft!!
MSFT retired NewSID because they want you to buy licenses separately instead of cloning omg i am drunk
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.
I, for one, wish to speak a word of thanks. This was a step of courage.
If only half of the people working on a non-solution, on which they own their daily bread, where so courageous.
H
dude, write "NSFW"!!!
always!
Do not clone Windows from drive images. Ever. You will never understand why things are broken down the road.
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.
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
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 resetting the SID also resets the product activation clock. That would be a very interesting "failure" as it would explain the speed with which NewSID was removed. Obviously, the guy that created that torrent no longer seems quite as paranoid as he probably did when he created it.
Nothing for 6-digit uids?
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 in this particular case, NewSID is more efficient. Or, is there some problem of which we are not aware? What other machine identifiers does Sysprep change, besides the SID? The lack of clear, concise documentation of Windows raises the cost of ownership.
Here is official Microsoft policy as of 2009-11-04, 05:36 PDT: "Because the SID identifies both the computer or domain and the user, unique SIDs are essential to maintain support for current and future programs."
The Windows XP Service Pack 3 Deployment Tools still mention changing the SID using Sysprep. Note that the help file for those tools still references XP service pack 2. That's typical Microsoft uncaring sloppiness, in my experience. The Sysprep Command-Line Options help file, in deploy.chm, still says that there are cases where changing the SID is necessary.
There may be many programs not supplied by Microsoft that depend on differing SIDs. This is not a decision that Microsoft should make unilaterally.
Do older Microsoft Windows operating systems require a unique SID in ways that Mark Russinovich is not considering?
Quote from the article by Mark Russinovich: "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."
Translation of that quote: "We didn't do any testing."
I think that at least some disk imaging and backup software, such as Acronis, changes the SID after a clone.
Some web sites are still offering NewSID 4.10 for download. For example, NewSID 4.10. But, is that a good copy? What is the MD5 or SHA1 or SHA256 of the latest version of NewSID.EXE?
Is it legal to download something that Microsoft supplied in the past? In the U.S., there is a law of Fitness for Merchantability. Does that law protect Microsoft's users, since in some cases we can't use what we bought without NewSID, or some other SID-changing utility?
What is the real reason NewSID was removed from availability for download? To me, Mark Russinovich has always seemed completely honest, and far more knowledgeable than any other programmer I know of at Microsoft. On the other hand, Microsoft managers have sometimes seemed to me to have chosen to do something that they think will be more profitable for Microsoft, but very much against the best interests of customers.
Note that the "markrussinovich" who posted comments in the Microsoft TechNet story does not have a TechNet biography.
Some people have had trouble with SID-changing utilities. Some of those troubles were caused by not letting the SID-changer finish scanning an entire partition or hard drive.
This is a BIG issue for us. Our experience is that Microsoft Windows has an extremely high cost of ownership, due partly to the sloppiness of the design. Mark Russinovich's SysInternals tools for Microsoft Windows have been very helpful for us in lowering that cost a little. Those tools should always have been supplied by Microsoft, in my opinion, and now that SysInternals is owned by Microsoft, they are.
How is this shit spewed from a Microsoft Marketeer worth posting to Slashdot?
Oh, yeh. Its not.
...because it's fixed a problem that I was having right now!
Microsoft bought Commodore? When did that happen?
For your pleasure. Britney Spears Sans Panties.
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 customer and says "That'll be $500." The customer says "You're crazy if you think I'm paying you $500 to hit my car with a hammer." The mechanic says "You don't understand. Hitting the engine with a hammer is free. Knowing where to hit it? That's $500."
I like this version better because (a) almost everyone has experience with a car and a mechanic, and (b) it teaches people that the "work" may often *appear* simple but in actuality even the lowly blue-collar mechanic has information you don't to fix a problem.
I've told this anecdote countless times to my IT consulting customers who are, on occasion, miffed because they called me in to resolve a problem and I billed them an hour for what appeared to be a trivial amount of work. Almost always they kind of laugh and "get it" that what they're paying for isn't always some large unit of labor but for the skills and experience of someone who knows something they don't.
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.
the way I see it is that MS is just dropping support for xp/2003, retire the deployment tool for legacy os.
If only they would give us something worth to replace my XP....
....What would BILL do?!?!?!?!??
Regards;
So Microsoft doesn't give a crap about fixing the SID problem when cloning systems with Cygwin installed? Well, knowing MS, they probably consider breaking Cygwin as a side benefit.
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 details but maybe this helps jog the memory.
I have no idea if the problem was really SID's or as TFA suggests, the issue was elsewhere but got blamed on SID's..
We discovered during an SMS 2003 rollout that if you try to initiate a Remote Assistance session to a machine that had NewSID run on it (part of our post-imaging processes), that Remote Assistance would not connect.. so, good riddance to NewSID as far as I'm concerned. (Running Sysprep on the machine would fix the problem.)
I am cool because I bash MS on Slashdot even though I have no idea about how domain SIDs and machine SIDs are different. I also refer to every unique identifier for every application as a "SID" because it gets duplicated when I clone workstations, just like SIDs do. And I really, really, really know what I am talking about because I duplicate workstations for a living and that is what all the best IT professionals do all day long. It doesn't matter that I don't take time to understand the underlying workings of the OS that I am tasked with supporting. It is much easier to say that MS is dumb, that Mark R. is now assimilated into the borg, and that they are both wrong because neither one knows more about Windows networking than I do. Linux is obviously better because it doesn't use UIDs in any way, right? Right?!
If SIDs can be infinitely duplicated and it impacts nothing at all, then what's the point of having SIDs in the first place?
I'm not sure this is any more useful to your post, but I very clearly remember going through this when I was contracted to make a machine imaging setup for a computer lab back in the NT 4.0 (possibly even 3.51) days. NT4 Server/DC, and NT4 Workstation machines. Once you joined the domain with one machine, any cloned one refused to join the domain. I ended up with sysprep scripts and all kinds of other junk and cloned them at the point of the first (or maybe second....I don't recall) reboot during a fully scripted setup to solve the issue. This was before tools were available to deal with this.
Do not fold, spindle or mutilate.
Microsoft actually explicitly supports ghosting nowadays, assuming you do it their way. Check out the Windows AIK and this guide. It's pretty nice, and if you want to automate things you just need to mount the boot image (using dism) and edit Windows\System32\startnet.cmd
Microsoft actually explicitly supports ghosting nowadays...
OK, add one word: this wouldn't be a way for Microsoft to discredit competing Ghosting?
What competing Ghosts? I don't think anyone's bought a copy of Ghost since Ghost 8. If you look hard enough anywhere there are more than fifteen computers in the same room, you can find a copy of the Ghost 8 executable. I think it just gets spontaneously created after a certain silicon threshold.
Who needs Ghost, we did it using a picoBSD boot floppy that dd-ed an image of the partition table and system partition onto the raw hard disk over ... damn, I forget whether we used nfs or ssh or http now... and then ran setsid after first boot.
Don't know if newsid was out yet.
In a network of cloned boxes using Microsoft Message Queue, we have found there are issues with dropped messages to/from a common server. Creating unique SIDs solved our problem...
I've built MANY MOSS (SharePoint) farms and the ONLY way to get them to run without generating errors in the logs is to build each machine individually and not from VMware templates or cloned images. Interestingly enough, NewSID did NOT solve the problem, but to be sure, there IS SOMETHING that causes this -- and probably updating/extending NewSID would have been the way to go.
For 8 years I had windows clients and FreeBSD servers.
Most of the clients were re-imaged nightly with a complicated
script that set $COMPUTERNAME to be equal to the name returned by reverse lookup of their IP address which was set by dhcp.
I understood the argument against identical SIDs to be that SIDs were used to create the individual user accounts, and that duplicated SIDs meant that users on two machines could have the same UID, which meant that user A on machine 1 could pretend to be user B on machine 2.
In my case the only IDs on local machines were system IDs. All user IDs were at the domain level.
So I didn't worry about SIDs. As far as I know this never came back to bite me.
Third Career: Tree Farmer Second Career: Computer Geek First Career: Teacher, Outdoor Instructor, Photographer.
what, celebrity mechanic? the president?