Should mention a few other things, though right?

If you're using cached mode, that's great, but you need to know where the
timeout and loss of connectivity occur.  It doesn't have to be the Exchange
server that is timing out.

Protocol makes a big difference, as does which servers they're utilizing as
well as the server performance itself.  All of these can look like a network
issue.  The reverse is of course, also true - server issues can look like
network issues from the symptoms.

I'd say start by finding out which servers the users are having trouble with
(the GC, the store, what? ) and then find out what the client version and
configuration is.  Also take a look at the server version (both GC and
Exchange server) and configuration and figure out where your issue actually
is.

The client can help if 2003 or later because it will tell you which servers
it's using.  Viewing this from the client perspective might help things to
make more sense. (CTRL + Right-Click the outlook icon in the system tray and
choosing the connection status).

You also have to qualify what "slow" means in regards to normal in your
environment as well as how they are connected when they lose connectivity.

My $0.04 worth.

On 12/12/06, Michael B. Smith <[EMAIL PROTECTED]> wrote:

 Exchange 2003 and above with Outlook 2003 and above put a heck of a lot
more data in each buffer and they compress it. Thus, due to a more efficient
use of bandwidth, the 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:* [email protected]
*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 number was
somewhere around 50ms.

Thanks!



Brent Eads
Employee Technology Solutions, Inc.

Office: (312) 762-9224
Fax:     (312) 762-9275


The contents contain privileged and/or confidential information intended
for the named recipient of this email. ETSI (Employee Technology Solutions,
Inc.) does not warrant that the contents of any electronically transmitted
information will remain confidential. If the reader of this email is not the
intended recipient you are hereby notified that any use, reproduction,
disclosure or distribution of the information contained in the email in
error, please reply to us immediately and delete the document.

Viruses, Malware, Phishing and other known and unknown electronic threats:
It is the recipient/client's duties to perform virus scans and otherwise
test the information provided before loading onto any computer system. No
warranty is made that this material is free from computer virus or any other
defect.

Any loss/damage incurred by using this material is not the sender's
responsibility. 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
[email protected]

To

<[email protected]>

cc

  Subject

RE: [ActiveDir] Remote Exchange Access and Timing







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:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *
[EMAIL PROTECTED]
Sent:* Tuesday, December 12, 2006 12:27 PM*
To:* [EMAIL PROTECTED]
Subject:* [ActiveDir] Remote Exchange Access and Timing


All;

This may be slightly off topic.

Does anyone remember how fast Exchange needs the line speed to be for
remote access? I am working with a client that is having time out issues
with a 248ms (average) packet time. With some static routing I might be able
to get this number down to say 125ms but my fear is that will likewise be
too slow. From a networking (routing) side of things I can see some peering
loss in Europe so there is no really easy answer save building special
static routes or PPP connections, etc.

Thanks!



Brent Eads
Employee Technology Solutions, Inc.

Office: (312) 762-9224
Fax:     (312) 762-9275


The contents contain privileged and/or confidential information intended
for the named recipient of this email. ETSI (Employee Technology Solutions,
Inc.) does not warrant that the contents of any electronically transmitted
information will remain confidential. If the reader of this email is not the
intended recipient you are hereby notified that any use, reproduction,
disclosure or distribution of the information contained in the email in
error, please reply to us immediately and delete the document.

Viruses, Malware, Phishing and other known and unknown electronic threats:
It is the recipient/client's duties to perform virus scans and otherwise
test the information provided before loading onto any computer system. No
warranty is made that this material is free from computer virus or any other
defect.

Any loss/damage incurred by using this material is not the sender's
responsibility. Liability will be limited to resupplying the material.

Message scanned by TrendMicro




Message scanned by TrendMicro



Message scanned by TrendMicro



Reply via email to