Al has posted a ton of good info. A couple of points to add.
Another thing to be concerned about with having the client find its own GC is that in some orgs, the GCs that the Exchange servers are likely to hit tend to be very well maintained (heck Exchange is using them, you are in for deep doo doo if you don't...), more so even than regualar DC/GCs. Also you may hit a GC that is out in the boonies that doesn't get replicated too as often as one in the datacenter site with the Exchange Servers. I know that to all good Admins, every DC/GC is equal to the next, however those that have dealt with Exchange will often start to look at the Exchange GCs as more equal right along with the PDC. You tend to have the monitors a little more hair-trigger'ish with the Exchange GCs as most DCs can fail and have no serious impact on the environment, an Exchange GC blows and you end up in front of managers to start trying to explain how DC failover is supposed to work and why they couldn't get their mail and why 50,500,5000,50,000 people chewed them out and etc etc etc. On the second aspect of this, doing the 5.5 architecture. I would take it even further than what Al is indicating. I would say that the 5.5 architecture is when you spin up a separate single domain forest specifically for Exchange. If you have a decent sized environment, I think you should right off think about setting up Exchange in a dedicated site, that way you can handle better what I specify in the paragraph above concerning GC equality without having to hard code the GCs on the Exchange servers - hardcoding is always a pain to work with as someone will forget. If you have a decent sized environment with multiple domains with mail users then the separate single domain forest becomes more and more "interesting" as a solution. If you are concerned about security and separation of duties between AD Service Admins and Exchange Service Admins, a separate single domain forest is your only feasible solution. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Monday, July 12, 2004 4:45 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] outlook / gc client discovery Note quite. Closest GC is a way to tell the LookOut client to use it's own closest GC vs. asking the Exchange server for that information. The danger here of course, is that you *can* get a GC from a domain that has no Exchange information (not domain prepped) and then cause failure. They may have changed that behavior to be similar to the DSAccess process that builds a list of GC's for use based on the criteria, but I haven't looked lately to check. AFAIK, it just uses the Active Directory information and wkstn information to conclude what the closest GC is and uses that. So in the end, you are reading the kb correctly as to when to use this reg key; you want to use when you want to prevent WAN traffic for GAL lookups etc. That leads to the other concept, which is to create the 5.5 topology/architecture from 2003 parts the thinking being that if you cross the wire for mail data, it's not that much more data to get for GAL lookups and you can probably better use the hardware for Exchange Server-specific lookups (Exchange heavily relies on a GC for operations). There's some sound logic in there.... Local GC's *may* be discovered. If you only have ten GC's in the whole domain, then those are the ten that will be in the list, right? Keep in mind I know nothing of your environment. :) But if you have ten that are local in respect to Exchange, then those would *likely* be the ones handed to the client on startup vs. the one's local to Outlook client location without any client registry modifications. Again, that's because the MAPI knows nothing of Active Directory or sites etc. It knows about a server with a directory and referrals and that's about it. So what happens in normal operation is that the client starts, asks the Exchange server for the directory information and receives a referral to the GC that Exchange hands out on a round-robin basis based on the list populated by DSAccess or manually by the administrator. When I say recreate the 5.5 architecture and toplology, I'm saying that you can create Exchange servers with their own dedicated site and dedicated GCs that you hard code in the list if not 10 of them. That way, when a client starts, it asks for the directory service it needs to use and it's given a GC local to the centralized Exchange server where it's mail is also located. Remember that directory lookups are typically small compared to the data transfer of the messages, so this is not seen as a big hit for most companies that deploy a centralized Exchange topology (strangely, this is exactly the selling mantra of the Exchange product line; but I digress..). The added advantage is that if you deploy a few dedicated Exchange GC's, then you also have GC's that can service the Exchange boxes and don't have to worry about your other infrastructure being impacted by mail storms, DL expansions, etc. Does that help to illustrate it Graham, or would a visual be better? If you need a visual to see what I mean, drop me a note off-line. -Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Monday, July 12, 2004 1:14 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] outlook / gc client discovery Al, thanks for the post reply. I thought it would have been miraculous for the Outlook client based on that registry change to totally change in behaviour ! duly noted on the multi-domain issues - not an issue as all clients / groups will be in same domain as GC / DC so a read/write copy of the domain will be available. not sure if i read you correct but does the Outlook config with the 'CLOSEST GC' registry value reflect the closest GC to the Exchange server and not the client ?? i suppose if u read KB319206 properly it does say when the Exchange server AND GC are in a site remote to the client !!! do i then read this whole issue correct in that unless the FQDN of the server is hardwired into the Outlook client then in a topology of remote GC's / centralised Exchange servers then local GC's will not be discovered. are you able to elaborate further on "consider the recreation of Exchange 5.5 functionality with regards to directory service" ?? GT ----- Original Message ----- From: "Mulnick, Al" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 12, 2004 5:36 PM Subject: RE: [ActiveDir] outlook / gc client discovery > Graham, that's a fairly common question actually, although usually in > the Exchange groups. It still could be considered on topic here for > part of that data. > > FWIW, it's the dsproxy process that hands out GC's to clients to use. That's > because of the legacy restrictions the client brings to the equation (see: > http://www.microsoft.com/technet/prodtechnol/exchange/2000/deploy/upgrademig > rate/series/planningguide/p_08_tt1.mspx and search for DSProxy)Note > that different versions of Outlook will respond differently to this > process after > the first contact is made an a GC is found. DSProxy picks it's GC's > based on a number of criteria such as whether or not the domain it's > talking to is > domainprepped, how close to the Exchange machine the GC is (network), etc. > > > In multi-domain environments, it's not always a good idea to use the > closestGC method (see: > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q319206). > Rather, using a pre-defined becomes more usable as long as that GC > remains operational and up to date. Since that's against what Active > Directory can > do (multi-master concept) then it becomes a burden that many will > gripe about (and rightfully so on that one). For those situations, > recreating Exchange 5.5 with Exchange 2003/Active Directory seems to > be the best > workaround: i.e. creating a set of GC's specifically for Exchange usage. > This has the added benefit of dedicating GC's to Exchange (better > performance) and putting it under Exchange operational control > (environmentally isolated). Some would call that a detriment others a great > step forward, but all can agree it's just about a waste of hardware :) > > The problem is that the client doesn't send any site-awareness information. > Since Exchange 2003 can't take us back in time while still having to support > legacy clients (else many wouldn't buy the upgrade right?), you need > to work > with it to your environmental strengths IMHO. > > Why does it only maintain 10 of each? How many does it need? If 10 aren't > available, don't you have bigger problems to worry about? The q > article discusses your second question and gives details about the > behavior. Like I > said, be careful to note the versions and if you're spread out over > many sites with a centralized Exchange server, consider the recreation > of Exchange 5.5 functionality with regards to directory service. > > Al > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner > Sent: Monday, July 12, 2004 8:10 AM > To: [EMAIL PROTECTED] > Subject: [ActiveDir] outlook / gc client discovery > > dear all, am a bit nervous posting this on account of going way OT as > this post falls quite definitely under Outlook 2002 configuration, but > there is obviously relation to AD so here goes ... > > understanding the mechanisms of GC 'discovery' would it seem be very > important to optimal deployment of outlook / exchange especially in > remote office scenarios. > > the default outlook configuration seems to use the "view" of the AD topology > in terms of DC's and GC's as is learnt by DSACCESS - and reads this > from the > server on which the outlook client is homed > > qu 1. why does it only maintain 10 of each ??? - this is a bit like > that odd > limitation of 25 DC addresses in the WINS (1C) record - and which 10 > does it > learn ??? > > qu 2 seems we can override this default behaviour with a registry > value (closest GC) - does this reconfigure outlook to behave like the > logon server > discovery process and use native DNS lookups ??? > > hope the mail list can be of help on this one > > GT > > > 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/
