To achieve optimal results when you use Outlook with Remote Desktop Services, pay attention to how you customize your Outlook configuration. For example, in Outlook 2010 you can configure Cached Exchange Mode with Remote Desktop Services.

The article is careful to mention that you’d need to have enough disk space on the server to handle each user’s OST file. Maybe this makes sense for small environments with only one Terminal Server and tidy mailboxes. I can count on less than one hand how many firms fall into that category.

Based on our experience, we recommend disabling Cached Mode on any XenApp server we put in place. At the same time, we want to allow our users to run in Cached Mode on their Windows 7 desktops. How do we achieve this?  Through the use of Loopback Policy, we can ensure that when users log in to a XenApp server, Cached Mode will be disabled.  This policy will override the settings within a MAPI profile that is roamed or flexed to the XenApp server. When the user logs back into their Windows 7 desktop, they are happily working in Cached Mode again.

This is just another example of how technology can change without much fanfare.  For many years, we never hard to worry about this situation. The mere fact that the user was logging in to a Terminal Server with Outlook 2003 meant that Cached Mode would be disabled no matter what. But with Outlook 2010 and Server 2008 R2/XenApp, a successful implementation relies on a successful configuration of the environment. You can download the Microsoft White Paper on the planning considerations of Outlook 2010 on Server 2008 R2 here.

I recommend reading Andre’s post to get more information on this topic.  The short version is this – Exchange/Outlook best practices do not necessarily work in a VDI environment.

When using Outlook in an Exchange environment, it is recommended to use Cached Exchange Mode.  In this mode a copy of the user’s mailbox is downloaded into an OST file and stored offline on the user’s desktop.  This mode offers better performance for the end user and reduces utilization on the Exchange environment as well.  In addition, using Cached Exchange Mode allows users to use Outlook Instant Search for fast searching of items in their mailbox.  Instant Search works by indexing the contents of the OST file so all searches occur locally and not on the Exchange server, further improving performance and reducing utilization on Exchange.

VDI environments that we see at our clients are typically configured as non-persistent or floating pools of desktops.  That is, each user connects to a pool of identical desktops and grabs whatever desktop is available.  When the user logs off, any changes written to the VDI desktop are discarded and the desktop returns to a pristine state.  There are mechanisms and tools in place to make sure user data is retained at logoff.

So if user data is retained at logoff, why can’t we use Cached Exchange Mode in non-persistent VDI environments?

• The OST file is equal in size to the user’s mailbox so storing a 15-30GB OST (not unusual at our clients) is not that practical from a performance or storage perspective.  If this data is being stored on the SAN, then you’re essentially doubling your Exchange storage (which may already be doubled or tripled if you’re using Exchange 2010 w/ DAGs).  In addition, the length of time it would take to download that file every time and the I/O impact that would cause makes it completely impractical.
• OST files are not supported when stored on network shares, so redirecting the OST to a home directory is out.
• Indexing of files on virtual desktops is typically disabled to reduce I/O demands.  This would prevent the use of Outlook Instant Search even if the OST was present.

For these and other reasons, Outlook is typically configured in Online mode when used with VDI.  This keeps all mailbox operations and searches on the Exchange server, placing the processing and I/O burden solely on the Exchange environment.  That sounds bad, but advances in Exchange technology specifically with Exchange 2010 have made this much less of an issue.  In fact, Microsoft states that IOPS requirements for Cached Exchange Mode and Online mode are essentially equal now, meaning there is no I/O “penalty” for using Online mode.

Exchange 2010 Performance

Let’s take an example scenario of 500 VDI users all running Outlook in Online mode against an Exchange 2010 backend.  We’ll estimate high and assume they all have a mailbox profile of 300 messages sent/received per day.  According to Microsoft that amounts to a 0.3 IOPS per user requirement of 150 IOPS total, or roughly equivalent to the capabilities of one 15k RPM disk.

We can make it worse and assume that all 500 users also have Blackberry devices, which introduces a multiplier of 2.16 IOPS per user.  (Note: this number is specific to Exchange 2007 as I haven’t been able to find a definitive number for Exchange 2010, but expect that the multipler will be even lower)  That brings our IOPS per user calculation to 0.65 (2.16 x 0.3), bringing the total IOPS requirement for all 500 users to 324 IOPS or roughly three 15K RPM disks (excluding RAID penalty, though this is less of an issue on modern storage arrays).  It is unlikely that all 500 users would have Blackberry devices and also send/receive 300 messages/day, so the actual requirement is likely lower than that.

Searching in Outlook

What about searching from Outlook?  Doesn’t that impose a significant IOPS burden on the Exchange server?  According to Microsoft, the penalty for searching in Online mode is just 10-15% of the database I/O based on user profile.  Using our 300 messages sent/receive per day number of 0.3 IOPS/user, 15% of 0.3 is just 0.045 additional IOPS. It’s no wonder that Microsoft states “Search catalog read I/O occurs when clients issue search queries, and it’s a rare enough occurrence to not be relevant to Exchange 2010 storage design.”

In other words – it doesn’t impact the Exchange environment enough to matter.  Is searching in Online mode slower than using Outlook Instant Search?  No question it’s slower, but search performance has improved significantly with Exchange 2010 so it isn’t as bad as it was in the past.  And the impact on the performance of the Exchange environment is almost negligible.

Summary

Quick breakdown of the numbers used above:

500 users each with a Blackberry and sending/receiving 300 messages/day = 324 IOPS

Impact of all 500 users performing searches = 0.3 x 15% x 500 = 22.5 additional IOPS

Drawbacks to Online Mode

It’s not all rainbows and unicorns when it comes to using Outlook in Online mode unfortunately.  In my opinion the major drawback of using Outlook in Online Mode is not performance but rather availability.

In Exchange 2010, the RPC endpoint has been moved from the Mailbox server to the Client Access Server.  This change means, among other things, that users are not interrupted when moving databases between nodes in a DAG.  Unfortunately that is only true if the user is using Cached Exchange Mode, as Online Mode users experience a brief period where Outlook becomes frozen and unresponsive.

Similarly, if the Exchange environment experiences an outage then Online Mode users are completely frozen and locked out of their mailbox with no access to messages.  Cached Exchange Mode users would not be able to send and receive new messages but would still have access to the contents of their mailbox since they are working off a locally cached copy.

Conclusion

There are many significant advances in Exchange 2010 that have reduced the overall disk I/O requirements down to a tiny fraction of what was required in previous versions.  There is no longer any penalty for using Online Mode vs. Cached Exchange Mode in terms of IOPS required per user, and the example above clearly shows that it is easy to meet the I/O demands of even heavy Exchange users.  The user experience may be slightly better with Cached Exchange Mode but likely not by much.

Most of the issues with Outlook in a VDI environment are around availability, not performance.  Although these cannot be eliminated, properly architecting your Exchange 2010 environment can help eliminate single points of failure and provide excellent availability to users.

If you’re considering VDI and are concerned about Outlook performance, I’d strongly recommend moving to Exchange 2010.  Many of the problems are addressed in Exchange 2010 and it can deliver a good Outlook experience for all VDI users.

NOTE: Adobe Acrobat Reader X includes a feature called Protected Mode that limits an application’s access to registry and file systems. This feature is enabled by default. Because WorkSite Integration requires full access to the local machine, you must disable this feature.

The feature can be disabled from the General Preferences in Adobe Reader X, and should be included into your MST transform package.

Regarding Update 2, there are a handful of issues resolved, but one in particular stands out to me because I’ve already witnessed it.   From the Release Notes:

NT-26001: When dragging an e-mail to a WorkSite folder using Outlook 2010 with Cached Exchange Mode disabled, the user receives the following error; ‘Cannot move the items. The item cannot be moved. It was either already moved or deleted, or access was denied.’

This can easily be avoided on Windows 7 desktops simply by enabling Cached Mode (which is a good idea for a number of reasons that you should already know about, so I won’t get into them).  However on XenApp servers, where Cached Mode is not available, this can be an annoying bug.  The email does in fact get filed, but the error just isn’t pretty at all.   If you are planning an Office 2010 roll-out with iManage, this update is a must-have.

In Outlook 2003, 2007, and 2010, reminder windows pop up in Outlook, but they do not steal the focus if you are working in another program.  For example, if you currently working in Word or Internet Explorer, you won’t see a reminder window if one pops up, since you’re not in Outlook.

In previous versions of Windows, this wasn’t as big of a deal because you would still see the reminder window in the task bar.  So even though you didn’t see the actual window, you would see the tab for it flashing on the taskbar.

In Windows 7 however, the default grouping of same-application windows, makes is much harder to see when a reminder window pops up. For example, the image below shows a second Outlook window, which is actually a reminder window.

As a result, Windows 7 users may find that they’re more likely to miss reminders and meetings.

The Solution – An Outlook Addin to Bring Reminders to Focus

Kraft Kennedy has created an Outlook addin which responds to the “reminder” event in Outlook, and uses Windows API functions to locate the reminder window and force it into the foreground.

With this addin installed, users would see the reminder window pop up in front of whatever application they are working in, and it will stay in the foreground until the reminder is dismissed or snoozed.

People who may have missed reminders before should now find that it is no longer an issue.

The image below shows a reminder in the foreground, over an Internet Explorer session.

We’re giving this addin away for free to anyone that is interested, but with no support.  If you’re interested in using it, please contact Michael Worth at  (212) 692-5610 or worth@kraftkennedy.com.

• Outgoing messages stay in the Outbox for up to 1 minute
• New messages do not arrive in the mailbox for up to 1 minute
• Items that are deleted or moved between folders may take up to 1 minute for the change to be reflected

This issue does not happen with Outlook 2003 in Cached Mode or in Outlook 2007/2010 in Online or Cached Mode.  The issue arises because Outlook 2003 requests UDP notifications from Exchange to determine when to retrieve messages.  When a new message arrives in an Exchange mailbox, Exchange 2007 and earlier would send a UDP notification to Outlook, which would then trigger Outlook to retrieve the message and display to the user.  In the absence of receiving any UDP notifications from Exchange, Outlook reverts to a scheduled polling of Exchange that occurs every 60 seconds, by default.

Exchange 2010 no longer issues UDP notifications to Outlook and, as a result, Outlook is then wholly dependent on its own polling frequency to retrieve new messages.  Outlook 2003 in Cached Mode and Outlook 2007/2010 are not affected by this issue because the former uses a different synchronization algorithm to send or retrieve content and Outlook 2007/2010 use an asynchronous notification process that does not rely on UDP notifications.

There are a few solutions and a workaround for the problem, as I note below.

• Implement Cached Mode for Outlook 2003 – This solution resolves the issue, as described above, but still leaves a legacy Outlook client in use.
• Upgrade to Outlook 2007/2010- We recommend that firms strongly consider upgrading the Outlook client to 2007/2010 when deploying Exchange 2010 due to all of the new features that require a newer Outlook client (OAB web-based distribution, Autodiscover, Personal Archive, etc.).  We also recommend Outlook in Cached Mode as a best practice, provided workstation hardware is sufficient for mailbox sizes.
• Reduce Polling Frequency of Outlook to Exchange- This involves the steps as outlined below to add a registry value on the Exchange 2010 CAS role to reduce the maximum polling frequency of Outlook.  While the registry value supports anywhere from 5 seconds to 2 minutes, Outlook 2003 cannot poll any more frequently than every 5 seconds.  As a result, this represents a best case scenario for Outlook 2003 in Online Mode and something where users will still likely notice delays.
  • Install Exchange 2010 Update Rollup 1.
  • On all Exchange 2010 CAS servers, navigate to  HKLM\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem and create a REG_DWORD entitled “Maximum Polling Frequency” with a value from 5000 to 120000 (decimal value).
    • Note that, as mentioned above, configuring this to anything less than 5000 will have no additional effect on Outlook 2003.
  • Restart the Microsoft Exchange RPC Client Access service on your CAS servers.  You shouldn’t need to restart your Outlook clients but you may want to as well.

Update:  As of 10/27/10, Microsoft has confirmed that this registry value can be configured as 5000 and result in a 5 second polling frequency.  It was previously documented that anything below 10000 would have no additional effect on Outlook polling.

Update:  This specific issue, related to UDP notifications, was formally resolved in April 2011 via Update Rollup 3 v3 for Exchange 2010 SP1 (see http://support.microsoft.com/kb/2009942 for information and the steps to re-enable UDP notifications).  Unfortunately, there were some additional permutations of this type of problem discovered for all versions of Outlook when operating in Online Mode, not just Outlook 2003.  These have been resolved in Exchange 2010 SP2 (see http://support.microsoft.com/kb/2579172 for more information).

This architecture is common to all versions of Outlook and Exchange, through 2010, and is not really a bug, so much as an architectural decision by Microsoft to keep item-level permissions in the client-tier.  The end result is that people should realize that just because they mark an appointment or other item private in Outlook, it doesn’t mean that no one else will be able to see it.  Items that are extrememly sensitive should probably not be stored in Exchange in the first place, or you should take off all delegate / view rights to your mailbox.  People who you give delegate rights to should also be people who you trust.

Developers should note that when writing custom applications with WebDAV, Exchange Web Services, or any other method, all items will be returned including private items.  The custom application should look at the sensitivity setting of each message before displaying it.  If the sensitivity is private, then the mesage should not be displayed.  We, at Kraft Kennedy, have run into this issue several times when creating custom applications with WebDAV that pull back appointments from the Exchange calendar.

Microsoft has details about allowing other users to manage your mail and calendar here: 

http://office.microsoft.com/en-us/outlook/HA100750811033.aspx?pid=CH100788801033

Note, the last paragraph of the article:

Symptom:  A meeting for which you are the owner/organizer disappears from your calendar after sending an update to all attendees if the meeting request was sent to a distribution list or group of which you are a member.  The meeting does not disappear if you are explicitly in the attendee list.

Workaround:  Before sending a meeting request to a distribution list or group, expand the membership by clicking the “plus” sign next to the name.  Once you see all of the members expanded, you may send the meeting request or remove yourself from the attendee list so that future updates will not fall victim to this bug.  I would recommend that you remove yourself entirely as an attendee in case other issues arise as a result.

We are unclear as to whether Microsoft is aware of this bug or has a fix in development. Hopefully the above workaround will help some of you that are experiencing this problem.

Another way to distribute the connection to a user is by sharing it through an Outlook context menu.  If you’ve already connected the library to Outlook, just right-click the folder in Outlook and choose “Share…”.  Then you can choose the people you want to email the connection to.  Anyone who receives the message will get an “Open” section in their “Share” ribbon in Outlook 2007, and can click to connect to or preview the library.

White these methods work well, they’re not efficient for distributing SharePoint connections to large numbers of people.  Fortunately, you can write scripts that directly run stssync commands and then deploy those scripts to multiple users.

In a batch file, the command looks like:

start iexplore.exe stssync://sts/?ver=version&type=folder-type&cmd=command-name&base-url=sts-url&guid=the-guid&site-name=site-friendly-name&list-name=list-friendly-name&list-url=list-url&user-id=uid

You can repeat this command multiple times in the batch file for each library that you want to connect to.

Ver 1.0 is used for Outlook 2003, and ver 1.1 is used for Outlook 2007.  The command fields are based on the properties of the library, with the only difficult one to find being the GUID.  In order to find the GUID, you have to actually open the source code of the default web page for the library and search for the text “ExportHailStorm.”  That javascript function includes the library’s GUID and other properties.

Additionally, if you roll out reg keys first according to this article (http://support.microsoft.com/kb/941836) then you can mark these libraries as trusted, and the user won’t get the Yes/No box asking if they want to connect the list to Outlook.  Otherwise the user will be prompted for each list that you attempt to connect.  By rolling out that reg key first, you can ensure a truly silent install.

This specification has some more details on the stssync protocol:

http://msdn.microsoft.com/en-us/library/dd587524(office.11).aspx