Thanks again. Which domain are your Exchange servers in- one of the 10 Americas domains, or their own domain?
Our lab will hopefully be back up & running this AM, so I might be able to look at this behaviour this afternoon, but I've suggested we do site configurations as our AD is deployed anyway to play it safe. If DSProxy does use GCs from all domains, and if it does do round-robin with the GC list, we're going to encounter this issue even with our relatively small deployment (7,000 users). Andy > 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/ > 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/
