Yep I think you are being smart doing it that way. In the meanwhile I haven't read the dsaccess/proxy paper in many months, I will try to relook at it to see if I get the same understanding from it. When I read it the first time I didn't have an understanding of what to even look for.
I can tell you positively though our main North America Site has 10 GCs exactly 4 from North America 1, 4 from North America 2, 2 from South America. It is actually *unusual* if I get a GC from my domain (North America 1) and all GCs are operating fine at very low utilization (we only have about 15,000 people on E2K across 3 mailbox servers right now with all of that GC coverage). joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, November 27, 2003 6:45 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] The behaviour you're describing is a little different than what the directory access whitepaper describes; it claims that DSProxy removes GCs from the working GC list that are in nonlocal DOMAINS, so that it ends up with a list of up to ten GCs from the same site and DOMAIN as the Exchange server; it was the domain part that made me think it wouldn't be much of an issue for us. We were going to IP address the root DCs/GCs into a different subnet anyway, to give us the option to defines sites down the road fairly painlessly if we had to (the whole AD structure is going to be in a single data centre); from what you're saying, though, I think we should play it safe and define sites right off the bat. This won't be the 1st time in history a MS process didn't behave exactly as advertised :-) Thanks again, Andy > Yes your description of what dsaccess/proxy does is what we understand. > However non-local simply means GCs not in the site that the exchange > server is in. > > If you have GCs that are DCs from multiple domain within a single > site, ANY one of the GCs could be what gets returned to the clients. > > I.E. In our example, we have a site that has Exchange servers and GCs > that are DC for two different North America Domains and a South America Domain. > The Exchange server could give out any one of those GCs as a local GC > to the clients to use. So if you have say a North America 1 User and > they can get a South American GC which means they won't be updating > things like public delegates, DL's, nor certs and possibly other things. > > Basically your design has to be that there are only GCs from one > domain in a single Exchange AD Site. So say are like us and have three > domains in the American Data Center. We actually need three logical > Active Directory sites to hold those domains in if they are all mail > enabled. If you don't mind hardcoding things you can get away from > that but hard coding leads to times later where you find someone > screaming "who was the bright moron who hard coded this..." - followed > by "Well the reason everything was down because someone in their > infinite wisdom hard coded this value and everyone forgot about it and then we killed that last domain controller and...". > > joe > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, November 26, 2003 8:33 AM > To: [EMAIL PROTECTED] > > Since my original post, I've done further research into this (I can't > do any lab testing at the moment because our lab's in the process of > being rebuilt for our formal Proof of Concept the end of this week). > > I was reading the "Understanding and Troubleshooting Directory Access" > (http://www.microsoft.com/downloads/details.aspx? > displaylang=en&familyid=c976433f-f979-4745-b7a6-9d8446ef6409) > Exchange 2000 whitepaper, and the understanding that I came away with > for the DSProxy process is that is obtains a working GC list from the > DSAccess process, removes any nonlocal (from the Exchange server's > perspective) GCs, and uses the resulting list for client > proxies/referrals on a round-robin basis (for load balancing). > > Since our lab is unavailable at the moment, though, I can't confirm > any of this. Is this the behaviour you've seen, or have you found that > clients get GC referrals to nonlocal GCs? > > With this behaviour, it looked to me like it would be a big issue in a > multi- user domain environment with lots of cross-domain interaction, > but we should be OK with the bulk of our users in the same domain as > the Exchange servers. There will be a 2nd user domain, but they're a > very autonomous section with a much more secure, highly classified > network that will have their own Exchange server > (s) in their domain, so there shouldn't be much cross-DL and delegate > management, if any at all. > > Thanks, > > Andy > > > > Yes you absolutely will run into the issue. > > > > The problem has nothing to do with load, it is how DSPROXY hands out > > GC's to clients. If you have GC's from multiple domains in the site > > where your exchange servers are, the exchange servers will have them > > all (up to I think > > 25 or something like that) in its GC list, any and all of those are > > valid to be given out to ANY client requesting a GC irregardless of > > the domain of the client or the user. You must break out your > > Exchange stuff into single domain AD sites or you must hard code the > > Exchange Servers DSACCESS list or hardcode the clients. > > > > On the positive side I really escalated this problem within MS as an > > MVP and our MS Premier Alliance folks really escalated this problem > > through their channels. Although Exchange Dev dismissed and said it > > would be corrected previously, they are now being forced to look at > > it > again. > > > > My recommendation to everyone this list is if you have multiple > > domain GCss in a single AD site and use Exchange 2000/3 call now and > > bitch to MS about this functionality. Initially they falled back on > > the old tried and true, people don't really have this problem, it is > > just you guys because you are doing things differently... > > > > Right off the bat we know it can affect DL's, Delegates, and email Certs. > > > > > > joe > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Tuesday, November 25, 2003 7:14 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > > > Good Morning: > > > > Long time lurker, 1st time poster :-) This topic was somewhat > > covered in a thread initiated by Joe, but I have a follow-up question. > > > > Our scenario: > > Approximately 6800 users. A Windows 2003 AD design with an empty > > forest root domain, and 2 child domains, 2 DCs per domain. The bulk > > of the users will be in one child domain, and there won't be much > > interaction between the 2 child domains. The root and the main child > > domain will both be within the data centre in a single site. We will > > be deploying Exchange 2003 in the main child domain. > > We are in the lab proof of concept phase, and the question has > > arisen whether when users attempt to manage DLs once we're in > > Exchange native mode, if they'll be potentially referred to a GC in > > the root domain, thus having their modification attempt fail. The > > time to determine this is now, before we move to the pilot (which > > involves deploying AD, then deploying the 1st > > E2K3 server). > > > > My initial thought was to simulate a heavy messaging load to DLs > > (UGs) with Loadsim. Using that approach, though, is there a > > relatively easy way to determine what GCs are being hit? Or is there > > a completely different approach I should be taking? > > > > Or, is the thoughts of the big brains on this list that this won't > > be an issue at all? Any and all feedback would be greatly appreciated. > > > > ADthanksVANCE, > > > > Andy Schan > > Messaging > > Contractor > > > > List info : http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > List info : http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
