Hi all,

Here are a few examples of which issues you can expect as well if some software are preventing access, even temporarily, to Outlook Cache mode files:

- a manager with many secretaries who have delegations rights on this manager’s mailbox, and who organize meetings on behalf of the boss – inconsistencies will arise overtime on meeting organizer and meeting attendees, which can be directly related to AV scanning Outlook cache files (OST, OST.tmp,xml,…) – or any other software who can have a handle on these files.

- desktop load from other application also plays a role in the frequency the above mentioned issues appearance, as applications like Outlook may be slower to process elements and will need more time handling OST, ost.tmp, profile_name.xml, .oab, etc… files and need more constant access to these => if the antivirus are handling these files at the same time, chances to have issues are multiplied.

- Outlook in cache mode is freezing as the application is trying to access its OST or other cache related files (as well as PST files sometimes “hooked” by AV software – remember not to put PST files on network shares or mapped drives) – Outlook in cache mode will NEVER freeze, unless the mentionned case on this example, OR any piece of online mode that is used on the user profile (Example: access to shared folders or mailboxes for which cache mode is not configured – this is a check box on the Outlook options for the current profile, or the OAB is not downloaded, then Outlook uses Online mode Address Book for example)

Note that frequency of these also increases as certain conditions of daily utilizations are met.The above examples of issues can be hard to reproduce on a lab.

I’m adding some more information regarding Outlook latency causes that can be on the Desktop side.

> Outlook 2007/2010 – More precisions about Antivirus exclusions and things that can slow down your messaging client in general

http://blogs.technet.com/b/samdrey/archive/2012/10/10/outlook-2007-2010-some-basic-advice-if-you-experience-startup-latencies.aspx

> Plan antivirus scanning for Outlook 2010

http://technet.microsoft.com/en-us/library/hh550032(v=office.14).aspx

Quotes:

- We recommend that you turn off scanning of the following Microsoft Outlook files:

• *.oab (Outlook address book files)

  %userprofile%\AppData\Local\Microsoft\Outlook\Offline Address Books\<guid>

• *.srs (send/receive settings files)

  %userprofile%\AppData\Roaming\Microsoft\Outlook

• Navigation pane settings file profile_name.xml files

  %userprofile%\AppData\Roaming\Microsoft\Outlook\<profile name>.xml

  where <profile name> is the name of the Outlook messaging profile, as shown in the Control Panel, Mail applet.

• outlprnt (print styles)

  %userprofile%\AppData\Roaming\Microsoft\Outlook

-  If you use antivirus software to perform file-level scanning [Outlook files], while Outlook is in use, data corruption issues might result.

- We we do not recommend that you scan *.pst, *.ost, and other Outlook files directly. Instead, we recommend that you scan email message attachments on the email server and on the Outlook client computer.

> How to troubleshoot performance issues in Outlook 2010

http://support2.microsoft.com/kb/2695805

Quote:

- The performance issues may be caused by one or more of the following: 

• Insufficient computer specifications
• Absence of the latest service pack for Outlook 2010
• Large Personal Folders files (.pst) or Offline Folder files (.ost)
• Outlook .ost files or .pst files that are stored on a drive with insufficient write performance
• Third-party add-ins
• Gadgets that access Outlook data (Windows Vista only)
• Microsoft Office Communicator integration
• Antivirus software interaction
• Windows Desktop Search indexing
• Incomplete closure of .pst files or .ost files
• POP3 accounts on Windows Vista clients
• Many Really Simple Syndication (RSS) feeds
• To-Do Bar and Online mode with Exchange server
• Damaged Outlook messaging profile

Just pasting the new Paging File size guidance on Exchange 2013 OS because we tend to forget the below new stance:

Moving forward with Exchange 2013, we recommend a fixed pagefile of the smaller of RAM size + 10MB or 32,778 MB (which is 32GB + 10MB).

http://blogs.technet.com/b/exchange/archive/2014/04/03/ask-the-perf-guy-sizing-guidance-updates-for-exchange-2013-sp1.aspx

Thanks Jeff Mealiffe !

Sam.

Hey,

Just taking Richard Schwendiman’s awesome Mail Flow schema and put the corresponding Receive Connectors as we “see” them from either Exchange Management Shell (in the Green Boxes, results of Get-ReceiveConnector for Get-ReceiveConnector -Server e2013 | fl name,bindings,transportrole,permissiongroups,authmechanism) or Exchange management console (focusing on the “Security” section of the EMC)

In your servers, for the connectors names in both EMS and EMC, you’ll see “Default <YourServerName>”, “Client FrontEnd <YourServerName>”, etc… instead of “Default E2013” , “Client FrontEnd E2013”, etc….

Full-resolution picture:

Sources:

• Exchange 2013 Mail Flow Demystified…Hopefully! by Richard Schwendiman :

http://blogs.technet.com/b/rischwen/archive/2013/03/13/exchange-2013-mail-flow-demystified-hopefully.aspx

• An Exchange 2013 Lab with default installation

Here I’ll just show a few examples just to make it sure if you have a doubt, that RPC Averaged Latency counter(s) is/are in milliseconds always, not in seconds, whether you query the counter(s) via Perfmon or Powershell (get-counter).

Perfmon in general always shows latency or times counters in milliseconds, usually in the format “0.000” for the Latest, Maximum, Average and Minimum values.

Here are a few examples.

I will do 2 sets of verifications to prove that the value we see for the RPC Averaged Latency (MSExchange RPC Client Access counter set) is in milliseconds even if it’s in the format “0.000”.

So first one, for two of my recent Exchange 2010 customers, I did a performance health check, and during the time frame of the test (2 hours), we had very few users, and we were good on RPC latencies (that is, below the 250ms error threshold for MSExchange RPCClientAccess – for MSExchangeIS, the error threshold is 100ms in average in Exchange 2010/2013).

So first one, we have a spike of “25.000” and an average of “6.587” … so if it were in seconds, we would have had a spike at “25.000 seconds” (that is 25,000 milliseconds) and an average of “6.587 seconds” (that is 6,587 milliseconds – six thousands five hundred and eighty seven milliseconds)… over an error threshold of 250ms (0.250 seconds) … then if we assume these values were really in seconds, for this first customer, the Exchange server would have been unusable ! and it was not the case, we were all good - so on this case, it’s definitely 25.000 milliseconds for the spike, and 6.587 milliseconds for the average.

And another view generated by PAL (Performance Analyzer of Logs by Clint Huffman):

For the second one, a customer for which I’m dedicated, which was measured with just about 30 users on it (my test mailbox also was in as well), so very few load – you see a spike at “5.000” and an average of “3.800” – again if it were in seconds, it would be 5 seconds for the spike (=5000 milliseconds) , and 3.800 seconds (=3800 milliseconds) – wayyy above the 250ms error threshold again and if it was the case, we would be unresponsive on the client side, and even the Exchange server would definitely have a problem - so it’s 5.000 milliseconds for the spike, and 3.800 milliseconds for the average.

See below the performance show which shows in thick the RPC latency (MSExchange RPCClientAccess), the Active User Count in brown (again MSExchange RPCClientAccess list set), and in blue (or thin black) the RPC Operations/sec activity which was very low (usually a full loaded server with 5000 mailboxes shows about 2000 RPC operations per seconds – here we only had 25 RPC ops/sec in average:

And a final test on my own lab:

And from the test I just did on my Lab (the red line is the CPU work – the black one is the RPC Average Latency, which I have very few here) :

Average = 0.330 , Max 1.000

And the Outlook latencies on the client side show 3ms max for the Exchange Mail connection:

(the 72ms is for the “Exchange Directory” connection which is slow because I’m running 4 vms on my Laptop – 1 Exchange 2007 + GC, 1 Exchange 2010 + GC, 2 Exchange 2013 configured as a DAG, all these on 2 AD sites) – and in Outlook 2010/Exchange 2010, there is no direct connection to the GC for directory requests (Outlook 2010 connects to Exchange 2010, which does NSPI requests for client directory requests – that adds overall time and raises the “Exchange Directory” times you see on the “Connection Status” window)

But see, “Avg Resp” is always in ms on the “Connection status” otherwise if it were 3 seconds here, my Outlook client will be unresponsive and always freezing, which is definitely not the case – as we recommend a round-trip time from Outlook to Exchange of 110ms max otherwise we will see lots of freezing, and RPC “waiting for server” dialog boxes.

So that corresponds to the 1.000 ms spike I see on my server (if I had 1.000 sec spike on the server, I wouldn’t have 3 ms of “Avg Resp” time seen on the client but a value closer to 1000ms).

So in conclusion, the value we see in MSExchange RPCClientAccess is in milliseconds, and more generally, all values you’ll see on Perfmon counters for Exchange and AD latencies are in milliseconds just like Technet’s latency thresholds.

Sam.