configuring NOT to register domain wide DC locator records might work also. jorge
________________________________ From: [EMAIL PROTECTED] on behalf of Tony Murray Sent: Tue 12/13/2005 11:00 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS Thanks Jorge and Deji for your responses. It sounds like we're all pretty much of the same opinion, i.e. that there will be a sequence of attempts against a list of DCs in Forest B. It would still be good to understand the how the DNS interactions work in this situation. I've searched around for documentation, but with no success so far. Tweaking the DC locator records for the DCs in the Forest B domain sounds like an interesting idea. I suspect some adjustmens to SRV priority might do the trick. As you indicate, I would need to find a way of doing this such that it doesn't impact anything else. Tony ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Wednesday, 14 December 2005 9:39 a.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS I would think the client receives a list of referrals and use the DC on top of the list and goes down the list until it finds a DC that responds. A client simply does not know why a certain DC does not respond. It can be anything... firewall, network, DC down or whatever. As there is no sites and subnets synchronization in place yet the DC retrieving the referral does not know in which site to query for a DC, it will query for the DCs in a certain domain. Do you have the possibility to tweak the registration of domain wide DC locator records for the DCs in forest B that are not reachable (taking into account that it does not impact services in forest B) Cheers, Jorge ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Monday, December 12, 2005 22:09 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Cross forest trust and DNS Hi all Need a bit of help with this one. Here's the scenario. Two Windows Server 2003 forests federated with a cross forest trust. Forest A has 4 DCs, all of which are reachable from Forest B. Forest B has approx. 30 DC, of which only those in main site (10) are reachable from Forest A's network. There is no site and subnet synchronisation in place. My concern is that not all the DCs in Forest B are reachable from Forest A ((because network routes are only in place to the main site). DNS secondary zones are being used and these obviously contain information about the unreachable DCs in Forest B. What happens when a client in Forest A need to access a resource in Forest B? The routing of Kerberos authentication requires DNS lookups for DCs in Forest B. If the client in Forest A receives a referral to an unreachable DC in Forest B, does the request simply fail or is there some built-in intelligent retry mechanism? In other words will the client in Forest A eventually be referred to a reachable DC? I realise there are long term solutions to this (site and subnet synchronisation, the addition of network routes), but I am keen to understand the DNS interactions so I can determine whether this will work in the short term. Tony 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.
<<winmail.dat>>