Outlook 2002

http://support.microsoft.com/default.aspx?scid=kb;en-us;319206&Product=o
l2002

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner
Sent: Friday, July 23, 2004 1:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [ActiveDir] outlook / gc client discovery


Dear all, thanks all for your positive views on this issue.

first up i apologise for not chiming in the last week - been away at
customer site ! - esp given it was me that opened up the item.

my further research into this seems to indicate that GC discovery
process seems to vary across versions of Outlook - and specfically
Outlook 2003 seems to introduce new processes ??

Would Ken be happy to confirm his version of Outlook - and required reg
mods to support local GC discovery with centralised Exchange servers ? -

I think i have referenced the "closestGC" reg value but am not sure if
this is it

TIA

GT


----- Original Message ----- 
From: "Mulnick, Al" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 19, 2004 8:25 PM
Subject: RE: [ActiveDir] outlook / gc client discovery


> Ken, that is a great response. Thanks for taking the time.
>
> I can see your logic now. :)
>
> Al
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ken Cornetet
> Sent: Monday, July 19, 2004 3:16 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] outlook / gc client discovery
>
> Well, as you (and Joe) pointed out, a WAN link slow enough to give a 
> bad user experience with name resolution will also yield poor message 
> performance.
>
> Obviously, the best solution is to put an Exchange server at the 
> location. Unfortunately, many of our smaller locations are simply 
> unwilling to foot the bill for an Exchange server (and associated 
> trappings).
>
> So, we are left with the task of making things better for the users
without
> spending money. The only thing we can do for free is to make their DC 
> a
GC.
> This speeds up name resolution. We can't speed up messaging 
> performance,
so
> we simply coach the effected users to not send large attachments, and 
> tell others to not send them large attachments. We also show users how

> to use Outlook in off-line mode. We were hoping
that
> OL2003's cached mode would help, but it seems to add as many problems 
> as
it
> fixes (more experimentation is in the works...).
>
> Like most other things, it is a trade-off. Our AD is fairly static - 
> just adding/deleting users here and there, group membership changed 
> now and again. We looked at the GC replication traffic, and decided 
> that it didn't look like a problem.
>
> This seems to work well for us, but obviously everyone's mileage may 
> vary.
I
> can easily see how GC replication would be a problem for large 
> organizations' WANs.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al
> Sent: Monday, July 19, 2004 1:44 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] outlook / gc client discovery
>
>
> Aside from cached mode, I think it's valuable to ask this: Is it ok 
> then
to
> have the user experience bad performance when it comes to message 
> content
as
> long as GAL resolution is good???
>
> The point I was trying to get across is that if the link is good 
> enough to host the Exchange data, it follows that it's also good 
> enough to host the GAL resolution.  The thinking being that the 
> resolution of names takes far fewer packets to traverse the wire than 
> it does to open a message body. Obviously there are exceptions when it

> comes to user experience, and as
Tony
> says, cached mode might be an option to "shield"
> the user from noticing the crappy latency issues.  But cached mode 
> aside,
I
> would expect user experience to suck overall if the GAL functions were

> bad enough for the user to notice.  The only difference across that 
> link is
the
> host they talk to assuming no DSProxy in play.
>
> I'd be interested to hear about the experience and how you solved it, 
> Ken, as I've never seen it go that way with regularity.  I have seen 
> the odd
time
> when your situation was true, but it turned out to be a slow GC anyway

> and that experience was much less dangerous than the Active Directory 
> latency issues Joe pointed out.  Slow data is always better than 
> inaccurate data IMHO.
>
> Al
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray
> Sent: Monday, July 19, 2004 10:50 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] outlook / gc client discovery
>
> This is where Outlook 2003 in cached mode helps.  By default it will
always
> use the OAB.
>
> Tony
> ---------- Original Message ----------------------------------
> From: "Ken Cornetet" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date:  Mon, 19 Jul 2004 09:41:11 -0500
>
> 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/upgr
> ad
> 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/
>
>
>
>
>
>
> ________________________________________________________________
> Sent via the WebMail system at mail.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/

Reply via email to