|
May be I am shooting blanks into the
great wide open, but I have lately been beaten on various occasions by LSA's
loopback check that has been enabled by default in W2K3 SP1 (mainly installing
MOM Reporting Services or having MOM's DB on remote machine – all W2K3SP1 related). I currently do not have an environment to
test this, but it could be worth a shot to try disabling the loopback check as
per: http://support.microsoft.com/default.aspx?scid=kb;en-us;896861 I guess this could be related to the way
the VM's network stack is implemented… Cheers, From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de 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 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 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 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 </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$ 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 Hi Jorge 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. |
Title: RE: [ActiveDir] FYI: Failing to create a trust
- RE: [ActiveDir] FYI: Failing to create a trust Guy Teverovsky
- RE: [ActiveDir] FYI: Failing to create a trust joe
- RE: [ActiveDir] FYI: Failing to create a trust Tony Murray
- RE: [ActiveDir] FYI: Failing to create a trust Tony Murray
- RE: [ActiveDir] FYI: Failing to create a trust deji
- RE: [ActiveDir] FYI: Failing to create a trust deji
- RE: [ActiveDir] FYI: Failing to create a trust deji
- RE: [ActiveDir] FYI: Failing to create a trust deji
