Optimize Microsoft Office and Outlook in VDI Environments

If the functionality that is provided by Outlook Cached Mode is required, it is possible to place a user’s .OST on a networked path using VMware View Persona Management profiles, View Persona Management Folder Redirection, or Microsoft Folder Redirection.  However, this may be outside of Microsoft’s support policy.  Per Microsoft KB 297019:

Outlook 2010 functionality is supported when networked .pst or .ost files are used under the following conditions:

• A high bandwidth/low latency network connection is used.
• There is single client access per file (one Outlook client per .pst or .ost).
• Either Windows Server 2008 R2 Remote Desktop Session Host (RDSH) or Windows Server 2008 R2 Virtual Desktop Infrastructure (VDI) is used to run Outlook remotely.

If a specific Outlook feature stops working or the .pst or .ost file becomes corrupt and you can reproduce the issue in the above environment, contact Microsoft Support.

Because a thick-installed or ThinApp’d version of Outlook does not meet the requirement of running on a RDSH or Windows 2008R2 VDI, redirecting the OST to a network share may not be supported.  However, a VMware View Composer Persistent Disk provides local-drive access to an OST.  The configuration of a persistent disk is done at the expense of using a Floating pool assignment model in View (persistent disks are only available in Dedicated Pools), and may cause an increase in disk capacity requirements and administrative overhead.

Previous to Exchange 2010 and Outlook 2010, Online Mode (Cache Mode disabled) operations incurred greater I/O against the Exchange Mailbox servers than did Cached Mode operations.  Exchange 2010 and Outlook 2010 have been optimized so that Outlook Online Mode clients and Outlook Cached Exchange Mode clients generate the same I/O profile against an Exchange Mailbox Server.  If you are running pre-2010 versions of Exchange/Outlook in your environment, consider the impact of disabling Cached mode when sizing your Exchange Servers.  See https://technet.microsoft.com/en-us/library/ee832791.aspx for more information.

Windows Search can generate a high amount of I/O while consuming CPU and memory.  However, many users have become accustomed to using Windows Search, whether natively or through Windows Search API’s, such as in Office 2010 Instant Search for searching Outlook mailboxes.  Many optimization guides for View desktops, including VMware’s official ‘VMware View Optimization Guide for Windows 7‘, suggest disabling Windows Search.  VMware’s guide has an attached script that automatically disables Windows Search.

On non-persistent / stateless desktop pools, the Windows Search index must be rebuilt at each refresh or recompose.  This can place a high amount of I/O and compute pressure on the desktop infrastructure while opening the very real possibility that the Windows Search Index is not built when a user logs in and is destroyed when the user logs off the desktop.  Clearpath recommends disabling Windows Search on stateless linked-clone desktops.

If persistent desktop users depend on Windows Search, consider using Group Policy Object (GPO) settings to reduce the impact of the component by controlling which drives and directories Windows Search should index.  For example, disable indexing of the C: drive, but enable indexing of the user’s Persistent Disk drive directories.

OST files also provide Instant Search capabilities for the Exchange Mailbox, by integrating with Windows Search 4.0.  Per https://technet.microsoft.com/en-us/library/ee832791.aspx,

In terms of mailbox search capabilities, end users have two options:

• They can use the built-in content index that’s available on the Mailbox server.
• They can install a desktop search engine client and have a local index generated on the client of the mailbox’s data and perform local searches.

End users that use desktop search engine clients with Outlook Online Mode may incur additional read I/O operations against the database. Currently, the only known desktop search engine that doesn’t incur additional read I/Os is Windows Desktop Search 4.0. Windows Desktop Search 4.0 uses synchronization protocols that are similar to how Outlook Cached Exchange Mode synchronization protocols index the mailbox contents.”

If disabling Windows Search, Exchange’s built-in content index may need to be tuned to deliver more up-to-date results to users.  Increasing the index frequency may cause additional load on your Exchange mailbox servers.  Monitor and size for this accordingly.

Many antivirus vendors provide Outlook plugins with enterprise endpoint security products.  Carefully consider the use of these plugins as they can cause increased load on VDI and Exchange environments where stateless desktops are deployed as the scanned object cache may need to be regenerated at each login to a floating/stateless desktop.

If defense-in-depth for your messaging environment is in place, providing scanning in the message delivery path and against the Exchange database, the need for an Outlook-specific plugin may be offset.

Carefully weigh the options when deciding on a deployment of Microsoft Office Outlook 2010 in a VDI environment.  Consider the VDI environment performance, Exchange Server performance, user Search expectations, manageability (View Persistent Disks), and supportability from Microsoft.