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. Sounds simple, but let’s have a look.

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.

Looks like there is no right or wrong,and the VDI architect will need to ponder all variables and the organisation’s context before making a decision. What is your take on this discussion?

I would like to thank the following people for contributing for such interesting topic: Chris Drake, David Noonon, John Dodge, Michael Francis, Russel Wilkinson and Stephane Asselin.