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.

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.

Support for PST in Network Drives

One of the main challenges on VDI has always been around use of Outlook PST’s.Although PST’s are meant to be used as archiving or backup solutions , Smaller mail box size in large Organizations meant that People use PST all the time. I would not like to get into a discussion if one should use PST or not. As a VDI administrator ,  I might be against the use of PST’s but then decision varies from Organization to Organization and we have to live with it. PST’s are generally stored on Home drives ( Data Drive) that are presented to a User in a VDI session. Predominantly , Home Drives are carved out of NAS or on a more generic term “Network Drives”.  Until now , PST’s accessed over Network was not a supported Microsoft Configuration  which meant that you cannot log a case with Microsoft for any issues pertaining to use of PST’s on Network Drives.

Starting with Outlook 2010 , Microsoft has termed that “Network access of PST and OST as a Supported configuration” under specific conditions namely,

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

This is a welcome change from a VDI Administrator perspective. There are always advantages and disadvantages of using PST on VDI and you would be the best person to judge if it’s suitable to your environment. Sometimes you don’t have a choice !

More details on Support for PST in Network Drives can be found in this Microsoft KB and would recommend reading the Planning Consideration White paper that can be found here.

VDI is a multitude of technologies that must work together in a premeditated way; and this we already know. However, couple weeks ago an interesting discussion in one of VMware’s internal forums sparkled my attention. The topic demonstrates clearly the level of attention and detail that a good VDI design should have. The central point of the question was about Microsoft Outlook configuration for VDI environments.

The PST
The practice recommends that PSTs be avoided in VDI, whenever possible. The reason for that is that the existence of PSTs in a given virtual desktop will tie that virtual desktop to a user, which is fine in the case of persistent desktops. What about if the desktop needs to be recomposed?
Well, a possible solution for that would be PST files in a Persistent Disk (UDD). If users are allowed to create PSTs in Persistent Disks, in a Persistent Desktop it’s then indispensable to carry out backups of these PSTs. The backup would have to be disk based and not agent based, since the user may leave Microsoft Outlook open inside the virtual machine. Of course there are way to solve that, like executing a automatic logoff or using a agent that support open files.
Let’s not forget that the main idea behind the creation of PST is due to the existence of the mailbox limit size imposed by administrators to save storage space on Exchange Servers. However, letting users create PST files they would be consuming the same amount of storage space from a same or different storage array. The Persistent Disk could be eventually located in a cheaper storage tier such as a NAS or SATA disks.
Anyway, seems like a good idea not to let users create PST on local disks, therefore increasing storage allocation for the Exchange Servers. In this way desktops could be part of floating pools and the users would have their independence from a single desktop that contains their PST.

The OST
The second problem to be solved are the OST files that are created when using Microsoft Outlook in Cached Mode. These cache files must be local and Microsoft does not support them in network shares. OST files are offline copies of server content that are locally indexed and synced with the server creating a high demand for disk traffic and IOPS. Additionally, every first use of Microsoft Outlook with Cached Mode enabled will force Outlook to sync server contents, causing a huge burst in network traffic and disk throughput and IOPS.
In a similar fashion to PSTs it is possible to accommodate OSTs in Persistent Disks, however the same constraints and issues apply. To keep up with the amount of IOPS a possible solution to consider is the use of SSDs, but the additional storage costs would not make sense from a TCO perspective.
Seems like it’s best to disable Cached Mode.

Disabling Cached Mode
Disabling Cached Mode we will be eliminating OST files, therefore getting rid of the persistent disk (UDD) requirement and also reducing network and storage bursts during the replication and indexing periods. However, now we have transferred the workload to Exchange Server.
Because OST files don’t exist anymore Microsoft Outlook will solely rely on being Online with the Exchange server for the user to send and receive and access mail, and this will put the IOPS burden on the Exchange Server, possibly impacting all users in the organisation should the server is not properly sized for the workload.
Another downside of Disabling Cached Mode is that Outlook Instant Search is unavailable if OSTs are disabled, and it will not index against Exchange Server. Since most users use advanced find to search for anything, the overall IO load could be much higher than it would have been if left on the virtual desktop. In summary, may be better to enable Cached Mode.
An interesting point raised during the conversations is that it is easier to manage Microsoft Exchange IOPS and network since it’s a single entity. Virtual Desktops are multiple and each individual desktop could have different requirements.users in the organisation should the server is not properly sized for the workload.