>>>One of my major uses of differencing disks is to configure a SINGLE server in multiple ways to see how the different configurations affect the same server so I can test apps under those different configs. Maybe one version of the differencing is applying a bunch of specific QFEs, another is loading a specific SP, another is the base image. >>>Depends entirely on what you are doing. If they don't have to communicate with each other or to a domain, sure you can.
All very true. >>> I don't think I can convince you of anything other than what you have set your mind on what virtualization is. Darn right about that ;-p >>> All I can say is that I would fight tooth and nail to prevent auto re-SIDding of virtuals based off of differencing disks. This is the second time you've snuck "auto" into the conversation. I don't believe I did say "auto" change the SID. I said some intelligence to detect that this is a diff disk, and an option to be able to say "yeah, whack the SID". A checkbox that then triggers something inside vmadditions (or a custom script) will do fine, thank you very much. >>> Fortunately, I don't believe that it is going to happen. Of course not. Not after you've totally dissed it :) >>>The virtualization software, in order to accomplish this would have to reach quite deeply into the OS itself which is what I think should be avoided. It doesn't have to, really. Imagine a check-box, that puts a flag in .vmc, that gets launched as soon as you boot up the vm off the diff disk. You get prompted with something like "Hey! are you going to use this machine like Joe does, or are you going to use it like Deji does?" If you choose the Joe option, it then goes "ho hum ..... what fun is that?" and quick. If you choose the Deji option, it goes and launch something NewSID-like and change the SID. But, since I don't think I can convince you of anything other than what you have set your mind on what virtualization is, I'd have to stop here [1] :O [1] I asked Jorge to try this out in VMWare and see if, perhaps, they have figured a way around this. Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCT Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of joe Sent: Thu 12/22/2005 6:52 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust > Don't you have 2 different SIDs in place right now (the base image and the differencing machine)? Not necessarily. One of my major uses of differencing disks is to configure a SINGLE server in multiple ways to see how the different configurations affect the same server so I can test apps under those different configs. Maybe one version of the differencing is applying a bunch of specific QFEs, another is loading a specific SP, another is the base image. Then when I figure out which way covers my concerns and offers the most speed or reliability, I fold that back into the main image and move on from there. Allowing differencing disks to represent multiple servers simultaneously is just another use of differencing disks. > you still can't have it loaded in MULTIPLE different ways AT > THE SAME TIME without contending with duplicate SIDs. Depends entirely on what you are doing. If they don't have to communicate with each other or to a domain, sure you can. > And why would it be problematic to just tell the process to just go ahead > and generate another SID every time we create a differencing disk? I don't think I can convince you of anything other than what you have set your mind on what virtualization is. All I can say is that I would fight tooth and nail to prevent auto re-SIDding of virtuals based off of differencing disks. Fortunately, I don't believe that it is going to happen. Not because it is impossible. But because it truly doesn't make sense except in some very specific cases which happen to be the only cases you use. The MAC address analogy just doesn't work, we are comparing apples and pine cones. The device driver asks the physical device, hey what do you have set for your MAC address? The device, in this case, completely virtual, can look it up in a table in the virtual server software and say, well it is this because the others are taken and reports that back to the device driver which reports it back to the OS itself. Further if the device driver is supplied by the virtualization software, you can have even more shennanigans going on there because it is aware of what is going on. The SIDs OTH, are stored on files, registry entries, and securable kernel objects all over the OS, none of which have to call out to an external device EXCEPT for the virtual disk. The virtual disk is not going to be able to differentiate a stream of bytes on the virtual disk as a SID or as part of an image, they are simply a stream of bytes. The OS isn't calling out to the SID device to ask the machine what the current SID is and even if it did, it would then have to change the entire mechanism for representing that SID in persistent store because you couldn't hard code it like it is now without constantly having to have some process in the OS changing it. Obviously that would be extremely disruptive to the functioning of the OS as it is written now. The virtualization software, in order to accomplish this would have to reach quite deeply into the OS itself which is what I think should be avoided. These reasons are why this is a change that would need to come out of the OS itself versus the virtualization software. I personally want my virtualization software to act like physical hardware and the OS have no clue it is running in a virtualized way. Obviously, this is not completely possible and possibly not entirely desirable (say for things like drag and drop capability hooks allowing you to send a shutdown command directly in from the virtualization software without sending a key sequence from the virtual kbd). joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 3:57 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust >>> I guess you could say MS should detect it is running a Windows guest >>> on a differencing disk and that it should auto-change the SID but what if the reason for the differencing disk isn't to run multiple different copies simulataneously but instead to have the same machine loaded in different ways? I would be rather pissed if the virtualization software took it upon itself to just start changing core configurations like that. What if you decide to later merge one image back into the parent, what do you do then with the SID change? I don't follow you here. How is the fact that we don't auto-detect/auto-change right now address your concerns here? If you decide to merge a differencing disk (today), don't you still have to contend with the DIFFERENT SIDs issue? Don't you have 2 different SIDs in place right now (the base image and the differencing machine)? If you only want the same machine loaded in ways, you still can't have it loaded in MULTIPLE different ways AT THE SAME TIME without contending with duplicate SIDs. So, how does this scenario negate the need for more intelligence and easier SID remediation? I am trying to also understand how the fact that there is a "device" in play wrt the MAC address analogy negate the opinion/idea that we can abstract a SID (or at least a SID generation mechanism) up to the OS layer. We are talking Virtual here. Arguably, none of this is REAL. We can lie to the OS and say there is this piece of hardware, no go and use it. And we can re-use that same hardware multiple times without those instances stepping on each other. We can (or should be able to) do the same thing with ANY other aspect of the Virtual environment. Again, riddle me this. When you change the SID on your new differencing machine, you will notice that that information is NOT written to the Base Image at all. So, the changes do not go to the base image. It is far removed from the Base image. The SID of the base machine is not changed. So, this change, ostensibly, is written somewhere else far removed from the base image. If this is so, why is there any affinity with the Base image's SID in the first place? And why would it be problematic to just tell the process to just go ahead and generate another SID every time we create a differencing disk? The "byte combination" is written and kept elsewhere, we can write any permutation of that "combination" on the fly - with some intelligence. Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCT Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of joe Sent: Wed 12/21/2005 11:51 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust But the SID isn't a "device". It is simply a number stamped on ACLs and other logical constructs all throughout the OS load. A virtual disk or a virtual NIC or a virtual you name it is a fixed device with a driver in front of it that everything that wants to use it has to go through. The SID thing is more like a byte combination and saying every time you see this byte combination replace it with something else. The devices are absolutely not handled that way. It isn't a case of oh they are writing to the USB, instead redirect to this or that. The OS is writing to a USB driver and that driver figures out what to do with the data. That is what drivers are all about and why you can write say a printer driver to generate a PDF instead of a printed doc. The affinity of the SID is to the virtual machine. The disks being used are linked to specific machines. A base image used by multiple (or even one) differencing disk is not directly linked. It is an indirect association and the OS itself has no clue that is happening, it sees the one differencing disk as a single true disk. In order for MS to automatically cover for this they would be building a very special environment to run Windows in a very special way, not trying to virtualize hardware and personally, I would rather they work their ass off to become indistinguishable from hardware versus having a special Windows environment. I don't see this as a virtualization issue as much as I see it as an OS issue. You know that you shouldn't have duplicate SIDs. You know that a differencing disk is one that takes a BASE image and uses that verbatim except where you make changes to the image on the differencing disk. I guess you could say MS should detect it is running a Windows guest on a differencing disk and that it should auto-change the SID but what if the reason for the differencing disk isn't to run multiple different copies simulataneously but instead to have the same machine loaded in different ways? I would be rather pissed if the virtualization software took it upon itself to just start changing core configurations like that. What if you decide to later merge one image back into the parent, what do you do then with the SID change? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 1:52 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust Look at it this way. When you run NewSID (or any other SID whacker), you are not actually modifying the main image. Your changes are written to the differencing disk. So, it's somewhat hard to understand the SID affinity. In physical hardware environment, we know that we have ANOTHER COPY of an image, and that the SID is baked into that and every copy we make of that copy. But, since we are actually ABSTRACTING in the Virtual environment, and we are not actually doing anything with (or to) that SINGLE COPY that we have, why can't we abstract the SID as well? Why not virtualize the SID much like we do with MAC addresses right now? Anyway, it's not so much a gripe or complaint as it is a way for me to document that observation. SID duplication having been a "known issue" for so long, you think that MS would sneak something into this "differencing" concept to take care of SID duplication. I mean, since this is a Parent-Child relationship, when you boot up the child and go change the computer name, why not do something about this SID then (natively, I mean). Or put some intelligence into VMaddition to detect that this system is running off of a differencing disk, then provide a mechanism for SID whacking. Or how about just making SID whacking part of the process of creating the differencing disk in the first place? Say, like put a 3rd option in there where you specify the differencing disk name, the parent disk name, and a check box to generate a new SID? Again, not a gripe. But "differencing virtual hard disk" and SID duplicated, "differencing virtual hard disk" and SID duplication, "differencing virtual hard disk" and duplicate SID did not produce any hit on Google, MSN or searchoff. So, obviously this is not documented anywhere. Not even in the help files. When you find an explanation for the first one, please share. Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCT Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of joe Sent: Wed 12/21/2005 6:56 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust I am a little confused why there is a thought that running duplicate images without changing the system SID within Virtual Server would make one immune from duplicate SID issues? The idea behind the virtualization software is to duplicate hardware, not protect the OS running on the virtual hardware from anything. That being said, I admit the results of the first test are confusing to me, I wouldn't have expected that to happen, the system SID as far as I know is not related to the objectSID of the machine in the domain, there should be no confusion there. I will try to play with that. I wonder if MS added something to the later OSes to dissuade the improper imaging that people might use to get around activation. The second test of trying to make the second virtual a DC in the same forest makes sense to me and I would have expected it to occur. Obviously the domain already exists message is because the lookup is by SID and not by name. A machine uses the SID it currently has for the domain SID when it is promoted as the first DC of a domain since it should generally be unique due to the initial machine SID generation routines (just like a GUID *should* be unique). Since it is a dupe, you hit an issue. I would agree that MS should probably check that better since this is more likely to occur with virtualization. MS doesn't check things like SIDs/GUIDs because of the idea of statistical improbability. If you follow the standard processes as outlined by MS, you shouldn't feasibly run into the duplicated numbers due to that statistical improbability of natural duplication. I never enven thought about it. My base images have newsid baked right into them. The first thing I do when I bring up a new differencing disk is to newsid and rename them. I know Dean actually has a build routine that does it automatically (at least on his ultra uber cool automatic VMWare setup). As an aside, one thing that is cool that I picked up from Dean is the idea to compress the stacked (differencing) images. As Dean mentioned to me, I have not see much of a perf hit for doing this and the disk savings is great. If I notice a speed hit say like Exchange possibly I will install the Exchange Bins and Data on a second uncompressed disk but still get the savings for the OS disk, usually in the realm of 12 or 15 to 1. After you newsid the differenced machine, the differenced disk file usually goes up to about 1GB, then the compression brings it back down to 100MB. Usually what I do is set up my virtuals in project folders like say E2KTST and then under that folder will be the machine definition files and the main disk and then a Stacked folder which is compressed and that is where the differencing disks go. If I chose to add an additional disk to a stacked machine I will put that disk in an additional folder under the project folder called something like FullDisks. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 3:17 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust In trying to validate Jorge's issue (http://www.akomolafe.com/JustSaying/tabid/87/EntryID/13/Default.aspx), I accidentally discovered a silly one in Virtual Server. See http://www.akomolafe.com/JustSaying/tabid/87/EntryID/14/Default.aspx Maybe it's not time to switch after all :) Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCT Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of Tony Murray Sent: Tue 12/20/2005 8:46 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust Hi Jorge Just finished testing with Virtual PC 2004 SP1. No issues found. The trust was established without having to match username and passwords. You've probably seen Deji's email saying he also had no issue with Virtual Server. I'm not ready to abandon VMWare quite yet, but it does give pause for thought. Tony ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Tuesday, 20 December 2005 4:34 a.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust Hi Tony, While creating my test environment that I will use at DEC, I also tested the following: ADCORP.LAN -> DC01 (W2K3SP1) -> DC02 (W2K3) promoting to DC and use DC01 (W2K3SP1) as source -> NO ISSUES! BRANCH.ADCORP.LAN -> DC11 (W2K3SP1) promoting to DC and use DC01 (W2K3SP1) as source -> -> ISSUES FOUND! (changing pwd solved issue) -> DC12 (W2K3) promoting to DC and use DC11 (W2K3SP1) as source -> NO ISSUES! SUBSIDIARY.ADCORP.LAN -> DC21 (W2K3SP1) promoting to DC and use DC02 (W2K3) as source -> -> ISSUES FOUND! (changing pwd solved issue) -> DC22 (W2K3SP1) promoting to DC and use DC21 (W2K3SP1) as source -> ISSUES FOUND! (changing pwd solved issue) It looks like if the DC to be promoted = w2k3SP1 then the issues mentioned occur Cheers, jorge ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Sunday, December 18, 2005 21:38 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust Hi Tony, R2 does not change core binaries so there should be no change there. I can save you time when it comes to the R2 test as I found it first in R2, then tried SP1. Both with the same issues I have not tried pre-SP1 myself I'm not sure, but I think it does not occur in pre-SP1 because I had never seen it before until working with R2 and SP1. Jorge ________________________________ From: [EMAIL PROTECTED] on behalf of Tony Murray Sent: Sun 12/18/2005 9:01 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust Hi Jorge Ok, I'm back at work and the workaround using the same username and password combination does the trick. I found one other interesting glitch. Here's the sequence. 1. Cross-forest trust setup fails with RPC connection failure. 2. Change ForestA administrator name and password to same as ForestB 3. Set up one side of the trust in ForestA. All ok. 4. Attempt to set up ForestB side of trust. Fails with RPC connection failure. 5. Remove trust in ForestA. 6. Go back to ForestB and set up one side of the trust. All ok. 7. Go back to ForestA and set up the other side of the trust. All ok. Weird. If I have time, I'll do the same thing with Windows 2003 (no SP1) and with Windows 2003 R2. I'll also see if the behaviour is different with Virtual PC. Tony ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Monday, 19 December 2005 2:05 a.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust Just before going to a party yesterday, I was playing with 2 VMs. Each Vm was a DC in its own forest/doman and I wanted to create a trust between the two. How difficult is that? Well, not that difficult, until you get the error... ;-(( default tests: nslookup, mappings, etc and everything OK There is a big difference here. With the DCPROMO thing I goes wrong after entering the credentials to dcpromo the DC With the TRUST thing I goes wrong as soon as you enter target domain The fun part is (quote from the DCPROMO story I wrote): <QUOTE> To test permissions and credentials I created a mapping (to the ADMIN$ share) from the stand alone server to the forest root DC and used username administrator and password CORP. result = OK To test permissions and credentials I started LDP on the stand alone server and connected to the forest root DC and used username administrator and password CORP. result = OK. I was able to anything in the directory. To test permissions and credentials and joined the stand alone server and made it a member server of the forest root domain using the username administrator and password CORP. result = OK. </QUOTE> Someone posted on my blog that this problem did not exist in pre-SP1 w2k3. So if someone can test that, please do so and post your findings here. Thanks! I'm sure the password thing will work. There is another solution and that is to connect to \\SERVER\IPC$ <file:///\\SERVER\IPC$> using the target credentials. What I have seen is that it sometimes worked and sometimes it did not. Remember, that in a multiple DC environment the DC might choose another DC then you did! Cheers, Jorge ________________________________ From: [EMAIL PROTECTED] on behalf of Tony Murray Sent: Sun 12/18/2005 3:58 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] FYI: Failing to create a trust Hi Jorge Weird that you should post this. I had exactly the same problem on Friday when trying to set up a cross forest trust using two vitual machines in VMWare ESX. I also performed the NetMon trace and saw the same SMB STATUS_LOGON_FAILURE error. I'll have to try the password thing when I get back to the office to see if that works in my environment. Tony -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Sunday, 18 December 2005 2:06 p.m. To: ActiveDir@mail.activedir.org Subject: [ActiveDir] FYI: Failing to create a trust Hi, Remember the DCPROMO thing on Vmware I experienced a while ago? (http://blogs.dirteam.com/blogs/jorge/archive/2005/11/14/60.aspx) I found another similar issue, but this time it occured when creating a trust (external or forest) between two forests. The solution is still the same When interested you can read more at: http://blogs.dirteam.com/blogs/jorge/archive/2005/12/18/297.aspx Cheers, Jorge This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
