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: [email protected]
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: [email protected]
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: [email protected]
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: [email protected]
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: [email protected]
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: [email protected]
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: [email protected]
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: [email protected]
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: [email protected]
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/

Reply via email to