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/
