latency can increase and still have reasonable
performance.
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *
[EMAIL PROTECTED]
*Sent:* Tuesday, December 12, 2006 3:00 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] Remote Exchange Access and Timing
That de
Of [EMAIL PROTECTED]
Sent: Tuesday, December 12, 2006 3:00 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Remote Exchange Access and Timing
That definitely gives me something to zero in on. Now to find this caching
mechanism. At one time I thought (maybe Exchange 5.5) the magic
onsibility. Liability will be limited to resupplying the material.
"Michael B. Smith" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
12/12/2006 12:31 PM
Please respond to
ActiveDir@mail.activedir.org
To
cc
Subject
RE: [ActiveDir] Remote Exchange Access and Timing
I t
ivedir.org
To
cc
Subject
RE: [ActiveDir] Remote Exchange Access and Timing
What element are you remotely accessing?
I take it you mean a client at a remote site?
Which version of Exchange?
I’m taking it that you mean an outlook client accessing an Exch2003 svr,
if so then an outlook o
I tell my customers 200 ms or better. In cached mode, Outlook 2003 and Outlook
2007 work just fine with that latency (depending, of course, on how much data
you are moving, but “in general”).
If you are “live” and no cached, you really want 80 ms or better, but I don’t
recommend it.
From
What element are you remotely accessing?
I take it you mean a client at a remote site?
Which version of Exchange?
I'm taking it that you mean an outlook client accessing an Exch2003 svr,
if so then an outlook over SSL connection will be fine, especially if
you cache locally... I've got clie
