To make a long story short, we will now be forced to use sysprep, which is what Microsoft has wanted all along, which effectively renders any imaging tool useless. The standard stuff about imaging part way through is only a partial solution, and while it may apply to physical boxes, it will mean that cloned VMs will have the same machine SID.
Our practice in the past has been to clone the VMs outside the domain, run NewSID and rename them in the process, then joining them to the domain. We had to do this because we have one situation where 14 separate computers are all build from the same image. The log in as a *local* account, yet map a drive to a network share using a domain account. Since the passwords of the local account and the domain account are the same, this works. The machines are kiosks, and auto-logon. The users never see the passwords. Until NewSID came along, this was a horrible nightmare. Servers would occasionally and randomly deny access, usually fixed by a reboot. If two machines have the same SID, then the first local created on each machine will have EXACTLY the same SID, and will appear to all other computers as exactly the same user, since the RID portion of each SID will be the same, and the base portion will also be the same. Please keep NewSID --MB On Thu, Nov 5, 2009 at 6:16 AM, Ben Scott <mailvor...@gmail.com> wrote: > On Wed, Nov 4, 2009 at 12:10 PM, Mike Gill <lis...@canbyfoursquare.com> > wrote: > > http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx > > The comments are interesting. > > One thing that is clear is that people are not clear about the > difference between the SID of the local machine, and the SID of the > machine's domain account. > > (My understanding: If you clone a machine which is joined to a > domain, then the clone will try to use the same machine account SID on > the domain, and fail miserably. NewSID won't fix this; NewSID just > changes the SID of the local machine. This is why SYSPREP forces a > domain re-join. So if you cloned a domain member and then had > problems, that's likely irrelevant to the machine local SID.) > > But I do agree with a lot of the comments in that just because the > people Mark talked to could not think of a failure mode doesn't mean > there won't be one. > > There is a lot of code in Windows that nobody really groks. > Microsoft calls this "legacy code", but since it's still shipping with > the OS and doing important things, it's still critical that it works. > Who knows what might be using the local machine SID? > > Some of the comments also suggest that some other Microsoft products > might use the local machine SID as a convenient unique ID. > > Some of the comments also suggest that some third-party products > might use the local machine SID as a convenient unique ID. > > I think it's very good that people are looking at this issue and > examining it with fresh eyes. Common knowledge is commonly wrong, and > should be checked. But the conclusion that the machine local SID > doesn't matter seems premature at this point. > > -- Ben > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
