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.
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 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 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.