RE: [ActiveDir] Site Link Bridging

[Lee, Wook]

Title: RE: Site Link Bridging

To me, it just sounds like someone didn’t divide the two physical sites into the proper AD replication sites. Either they didn’t map the subnets properly or the servers are not in the right sites or something along those lines. It also begs the question of what their domain structure is and where the clients are. The APIs for DSGETDC behave differently from what Exchange does for DSAccess, so it’s not surprising that you get different answers for GC placement depending on whether you talk to AD guys or Exchange guys.   So if clients are not getting authenticated by the “right” DCs, e.g. the NY folks are being authenticated by NJ DCs, then I would do the following:   A)      Check that there are in fact separate AD sites for NY and NJ. If they don’t have that, then all bets are off. B)      Check that the server subnets are divvied up properly between the two sites. C)      Check that the DCs that are physically in NY site are in the NY AD site. Ditto for the NJ DCs. D)     Check that the SRV records for the two sites contain the expected references to their respective DCs. E)      Check that the client subnets are divvied up properly between the two sites. F)      Check that the clients don’t have any negative DNS cache entries.   If all of that is true, then have a test user in which ever site log in to their client desktop and see which DC is authenticating them. You should check secure channel and other fun stuff. I’ve been surprised more than one when running nltest /dsgetsite on a client only to discover that the site the client was actually in bore no resemblance to the site I thought it was in. All it takes is a typo or a clicko to put a subnet in the wrong site.   The question of Outlook address book performance is highly dependent on the version of Outlook as well as Exchange in addition to the where the servers are and how everything is configured. You can have perfectly fine login performance and still have crappy Outlook and address book performance or vice versa depending on how thing are arranged. Without further details, there’s no way I would offer any suggestions, but I’m mostly an AD guy. J   As for time sync, if they care about a 3-5 *second* time skew, then they’re doing something pretty funky. A 3-5 *minute* time skew on the other hand is something that the operating system will complain about.   Wook   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, May 09, 2006 6:40 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Site Link Bridging   Having site link bridging should not have resulted in DCs from different sites registering in the same site unless their wasn't full coverage for the domains or if one of the sites didn't have a GC. Something isn't right here.   Not that that might not be a response they heard from an architecture review though, the quality of those reviews/health checks/RAPs and the guidance given at the end vary drammatically in quality based on the analyst involved. I have found in general though the AD folks can't give any good advice on Exchange and the Exchange healthcheck folks can't give very good advice on AD and MSFT doesn't have an all consuming healthcheck that takes all of it into account. So you end up getting a case of one healthcheck pointing at the other for sources of problems. Usually what you see is the AD folks saying everything is fine and the Exchange folks saying AD is in trouble but not being able to point at anything in particular.     joe   -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm        From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 09, 2006 6:41 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Site Link Bridging A friend of a friend when designing a new forest was asked to disable site link bridging (forest wide) based upon the reasoning given below.   I fail to see any connection between the description below and site link bridging.   Does anyone see how these issues could be caused by bridging and furthermore, why the issue would have been resolved by disabling bridging???   neil PS I don't necessarily believe that MS really did suggest disabling bridging would help - I merely copy/pasted the original thread :)   ___________________________ Neil Ruston Global Technology Infrastructure Nomura International plc Telephone: +44 (0) 20 7521 3481      We had an issue where the Domain Controllers in the New York site and New Jersey site were being registered under one site in DNS. This was causing users to authenticate to DC’s over the WAN link as well as Exchange servers using GC’s over the WAN link. This was causing some delays in users logging on as well as outlook being slow using the address book.  Also servers were synching up their time with DC’s in other sites causing w32 time errors at night and during the weekend while backups were running. This caused some servers to have their time offset be 3-5 seconds.  We had Microsoft on-site services evaluate the infrastructure and they recommended that we disable the Site Link Bridging to increase performance of the above issues.   PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies.