Hello Microsoft community.  We are an IT consulting firm working on behalf of a client with an interesting problem.  Here is the scenario:

• Users in question are on a Server 2008 R2 terminal server with Office 2010 running with Cached Exchange Mode OFF.
• User A is delegating User B's mailbox. 
• User A frequently exports User B's contacts to an Excel file for record-keeping purposes.
• Ever since fork-lifting their Exchange server from an on-premise Server 2003 server to a Server 2008 R2 server off-premise, exporting contacts to Excel is PAINFULLY slow.  A list of 1,000 contacts can take about 45 minutes to export to Excel.

We have tried exporting to other formats (CSV / Tab-delimited) but the same issue occurs.  If, however, you export to a .PST file, it goes through in a matter of seconds.  If a different user in the company working on a traditional workstation with Cached Exchange Mode ON performs the same Export to Excel routine, it goes through in about 15-20 seconds.   This can be reproduced in both Office 2007 and Office 2010, both again with Cached Exchange Mode turned ON but Download Shared Mailboxes is turned OFF.

The problem is that because User A is delegating User B, turning on Cached Exchange Mode & Download Shared Mailboxes would bloat the size of User A's the .OST file and thus take up a lot of space on the terminal server.  Not to mention that when an .OST file gets up to a certain size, it can cause some really odd issues with Outlook.  User A actually has several (approximately 8) other users that they delegate so if we choose the Cached Mode / Download Shared option, the .OST can potentially bloat to 50+ GB.

We can reproduce this problem in our own environment and in other clients we manage where they have en Exchange server off-site and are running Outlook without Cached Exchange Mode.  This almost seems to be a bug in how Outlook exports the file if the mailbox is not in Cached Exchange Mode and the server is not on-premise.

We've been banging our head against a wall on this.  Right now, the user is just allowing more time to export the contacts to Excel but what users to take seconds can take almost an hour.

Thank you.

UPDATE: Exporting to Excel with a different user who has 400 or so contacts, even with Cached Exchange Mode OFF, works fine and speedy.  Performing the same routine with closer to 1400 is a snail's pace, which is definitely odd.  However, trying both users on a traditional PC is speedy in both instances.

Any ideas out there?

• Proposed as answer by Karl Timmermans [Outlook MVP]MVP 16 hours 49 minutes ago
• Unproposed as answer by Karl Timmermans [Outlook MVP]MVP 16 hours 49 minutes ago
• Proposed as answer by Karl Timmermans [Outlook MVP]MVP 16 hours 49 minutes ago
• Unproposed as answer by Karl Timmermans [Outlook MVP]MVP 16 hours 49 minutes ago

Performing the same routine with closer to 1400 is a snail's pace, which is definitely odd.  However, trying both users on a traditional PC is speedy in both instances.

Any ideas out there?

Don't have a specific answer but past experience would point to an issue with the Exchange server and/or connection in use responding to "bulk" mapi requests which is used during the export process especially if the contacts have very large <Notes> field. Absolutely nothing that can be done via Outlook.

Over some 12 yr period - have encountered a handful of Exchange servers that caused our own import/export products to be very slow using MAPI (and even slower when using the Outlook Object Model) - either because of the connection in place or Exchange server configuration or any combination of the two. Logic dictates that when there are 100 configurations that work without issue and one that doesn't work the same  - it's going to be the specific configuration and not any underlying "universal" problem.

Hey Karl.  Thanks for the reply.

What makes the least amount of sense is that depending on the user that performs the export (user on a TS running with Cached Exchange Mode OFF and a local PC user with this mode ON), the speed of the export is completely different.  Same user's contacts, same output file - The TS takes almost an hour to export contacts whereas the PC is a few seconds.  Cached Exchange Mode shouldn't come into play here because both TS and PC users do NOT have the option to download shared mailboxes, but I figured I'd re-mention it.

In any case, thanks again and hopefully someone else will chime in on this.  I'll continue digging on my end.

Hey Karl.  Thanks for the reply.

What makes the least amount of sense is that depending on the user that performs the export (user on a TS running with Cached Exchange Mode OFF and a local PC user with this mode ON),

Going to have to apologize - completely overlooked the TS aspect when I replied but the key difference is "cached Mode" setting. When extracting data in bulk - two contributing factors are (1) the size of the contact item (2) the number of contact items retrieved which have an impact on the data block returned on a single call which if memory serves is around 32kb. If the number of items requested results in a data block > 32kb - less items get returned increasing time. Have no idea on what impact (if any) TS may have on this.

Out of curiosity - purely for test purposes, if you limit the export to one or two fields to ensure that the data returned for any contact is small - is the performance still the same?

That's a good test, Karl, I'll have our client try limiting the fields down to a smaller size.

What doesn't make sense is that Cached Exchange Mode has ALWAYS been off for TS users.  We only recently forklifted the client's on-premise Exchange server to a datacenter and that's when this problem was discovered by the client.  This slow to export problem only seems to impact TS users (even though it used to work fine when Exchange was local) and not traditional workstation users ever since the migration.  However, we can reproduce the same issue, as our own Exchange server is in a data center and if we perform an export routine on our own TS with Cached Exchange Mode off, the same slowness occurs.  Performing the export of the same data from our local Outlook with that mode on works speedily.

Took your suggestion to just export a few fields and got this reply back from the client:

"Unfortunately-thesuggestiondidnotwork.Ijusttriedit;movedoverfivefields(name,company,andEmails1,2,3).Slowasmolasses;nochange."

UPDATE: Exporting to Excel with a different user who has 400 or so contacts, even with Cached Exchange Mode OFF, works fine and speedy.  Performing the same routine with closer to 1400 is a snail's pace, which is definitely odd.  However, trying both users on a traditional PC is speedy in both instances.

Any ideas out there?

• Proposed as answer by Karl Timmermans [Outlook MVP]MVP Wednesday, February 11, 2015 7:03 PM
• Unproposed as answer by Karl Timmermans [Outlook MVP]MVP Wednesday, February 11, 2015 7:04 PM
• Proposed as answer by Karl Timmermans [Outlook MVP]MVP Wednesday, February 11, 2015 7:04 PM
• Unproposed as answer by Karl Timmermans [Outlook MVP]MVP Wednesday, February 11, 2015 7:04 PM

Took your suggestion to just export a few fields and got this reply back from the client:

"Unfortunately-thesuggestiondidnotwork.Ijusttriedit;movedoverfivefields(name,company,andEmails1,2,3).Slowasmolasses;nochange."

Sorry - I missed your reply last week. Would suggest posting the question in the applicable Exchange forum where you're likely to find more specific expertise in terms of EX used with TS. This really doesn't sound like an Outlook specific issue but rather a data transfer issue when TS is in play (or some other specific EX setting that I'm not aware of) - the logic being that Outlook uses the same functions regardless of the backend.

Exchange Server 2013 - Outlook, OWA, POP, and IMAP Clients
http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/threads

Exchange Previous Versions - Outlook, OWA, POP, and IMAP Clients
http://social.technet.microsoft.com/Forums/en-US/exchangesvrclientslegacy/threads

(*** if do find an answer to this - certainly wouldn't mind if you posted it here :-) )