Yep, true. Also when doing the syncing first thing in the morning you could have quite a spike on your bandwidth utilization...
joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Monday, July 19, 2004 2:48 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] outlook / gc client discovery You're recommendations are solid, Joe, but I would use caution with the cached mode OL2K3. The problem you run into is kind of a self-induced bandwidth outage with cached mode. What I mean by that is that you end up downloading all of your content to the local machine vs. just the headers and deleting them over the wire. The end result is that you end up moving the message across the wire fewer times when not in cached mode, but often at the expense of user experience. I usually view cached mode as a "slight-of-hand" trick to make the user feel good about themselves and make their mailbox more usable. The thinking being that if they didn't know it was sent an hour ago, they won't miss it. Should have waited to see your response before posting before. I love a good disagreement though and it's hard not to try and learn something from it through asking questions. I just flat couldn't wait ;) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, July 19, 2004 2:31 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] outlook / gc client discovery Never feel bad about disagreeing with me nor anyone. Debate is good, there is no one that knows everything, I am positive I don't know everything. With a WAN link of 128k I would also expect you had to start making a decision on whether or not you were just going to drop the Exchange Server on the slow side of that link. Obviously it completely depends on how many people and are there and what else they are doing across the WAN like for instance lots of email (read tons of RPC traffic), running APPS, web surfing, etc. Additionally a concern would be what OS is the GC because obviously there is one there and what is the domain functional mode? If you have a lot of universal groups across the forest and/or lots of domain changes unless you are in K3 FF then considerable bandwidth could be eaten tyring to maintain the GC state to be fairly close with the main GCs. Additionally if you are on 2K you have to be very considerate when making schema changes that impact the PAS as 128k could result in a bad day (or more likely bad several days) for someone making a PAS set change. In fact, the intitial deployment to a Fortune 5 company I know of put a GC in every site, once it was found out how Exchange really used GCs and learned how hard a Schema Update was going to pound the environemnt the decision was made to pull all of the GCs back out of the WAN sites and went from about 350-375 GCs to about 30-40. And even that made for a painful Schema update though in great part it was due more to the indexing bugs at the time in addition to the full sync of the GCs. At least in doing that pull back we saw the fear go out of the eyes of the onsite MCS guys helping plan out the schema update. Most likely, my recommendations to someone trying to do centralized Exchange with WAN links at painful speeds like that unless it was only a couple of people on the other side would be O2K3 with everything in full caching mode or more likely, use OWA. Then depending on what is running locally and your Uni group strategy you consider yanking the GC portion of the DC out of that site and set the DC for ignoregcfailures. If you use Uni's for deny you absolutely can't do this, but I can't stress enough how you shouldn't use active Deny's at all, they are dangerous simply from the standpoint of confusion let alone possible issues with GCs and such. Make sure people don't get access through passive deny, i.e. never granted. Much safer and easier to troubleshoot. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Cornetet Sent: Monday, July 19, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] outlook / gc client discovery Ouch, I hate to disagree with Joe, but we've "been there, done that". While it's true that the GC traffic volume pales in comparison to the Exchange traffic, the important metric here is not the bandwidth usage, but rather the end user experience. Your users will notice very pokey name resolution and GAL lookups if they are hitting a GC across a WAN. A T1 isn't bad, but a 128K link with moderately bad latency is absolutely painful! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, July 16, 2004 4:43 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] outlook / gc client discovery I like to put this most simply as.... Use the GCs for the clients that the Exchange Servers are using. If you have an Exchange Server in your local site using a local GC, use that GC, would be silly to go across the WAN. However if your Exchange Server is across the WAN, use the GC across the WAN as well. Comparatively the traffic is nothing compared to Exchange AND you are less likely to be bitten by the "loosely consistent" nature of Active Directory. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Wednesday, July 14, 2004 2:46 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] outlook / gc client discovery Sponsorship? I have no idea what you mean <g> "point taken about the size of the address book being small compared to but my mind has been that we have servers there with the required directory information, we might as well use them ???" Just because you can, doesn't mean you should. They are two totally different concepts to say the least. The address book lookups is typically very small. Although I currently enjoy large network links, that has not been the norm during my career. I've made similar recommendations when using 9.6 Kbps links, although that would arguably be a case for considering putting in a local Exchange server else use avian packet carrier or cached mode to at least give the illusion of usable performance. Generally speaking, wherever you put a site, you may also want to consider putting an Exchange server and GC's. They're not that different. If you instead decide to put the Exchange mailstores, where all the user data is located, in a central location, then why would it make sense to put the GC in a decentralized location? It's a nice to have, but it's not a requirement in most situations. It becomes more of a requirement depending on the links, but if you need to rely on it, you either have a geographically dispersed network and want more finite control over user traffic patterns (i.e. don't want the french mailbox users to have to use the south american GC for address book lookups)else you have a penchant for zeroing in on unimportant things. I'll assume the previous in your case because that would make a lot more sense. Bottom line is that there is no reason you wouldn't want to create a 5.5 - like topology if centralizing. You would create an active directory site, put in as many GC's as you needed for Exchange servers/users, and for each of those machines you'd hardcode the GC's DSProxy can hand out. Or maybe even create your own Exchange domain without users or your own domain forest depending on requirements. But to spend the time to reduce the smallest amount of traffic seems counterproductive to me except in situations noted above. My thoughts anyway. Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, July 14, 2004 1:04 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] outlook / gc client discovery thanks both for post replies - helpful in the extreme i do sense that the issue of GC and by implication dlist etc retrieval over a WAN connection is not regarded as such as a major issue - can only assume that you have the luxury of very well connected sites ?? point taken about the size of the address book being small compared to but my mind has been that we have servers there with the required directory information, we might as well use them ??? i take point about risk about client not being "intelligent" in its choice of GC with respect to domainprep etc - suppose this is where Dsaccess has a bit more intelligence than the client based discovery process - which it seems we are not sure about will be doing some capturing of the startup of outlook clients so hopefully something will stick out here thanks again for your help i always wonder about the sponsorship owed by microsoft to this mailing list ?? 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/upgrad emig > 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/ 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/
