Office 365, Outlook .OST files, Horizon View- The glue: App Volumes

The first time you create an account in Outlook and connect to an Exchange server, it takes a while for Outlook to get ready for use and for you to see you calendar items and emails. During the preparation of Outlook, an .OST file is being created on your machine in C:\Users\user\AppData\Local\Microsoft\Outlook.

So, why is this file being created? The .OST file is being created so you will have a local copy of all items being stored on an Exchange server. Emails, calendar items, reminders etc. This “Cached Exchange Mode” allows you to keep on working in Outlook even when you don’t have a connection (offline) to the Exchange server. A sync with the server will happen when your device is connected to the Exchange server. By default, this option is turned on but you can choose to turn it off. Besides the offline reason, you also could say a cached version is improving performance and user experience. Redirecting the .OST file to a share is supported by Microsoft, but with restrictions. If you want to know the basics around .OST and .PST files, visit here. In this blog, I’m only discussing .OST files. .PST files are very popular as well and you can use the same solution for .PST’s as I describe for .OST files.

In a VDI world, virtual desktops are residing very close to the Exchange server in the data center. And, in a VDI concept, there is no “offline” way of working considering the Exchange Server. So, in this case, there is no real reason to turn on the Cached Exchange Mode. Especially, when you are working with Linked Clone Floating VM’s in VMware Horizon View, where the clones gets deleted/refreshed after logoff. One thing you don’t want is to create that .OST file every time a user logs on to a clean virtual desktop. Best practice is to disable the Cached Mode in Horizon View.

So far so good, right?! That is what I thought as well. But, a new phenomenon is out there; Office 365.

When customers are using Office 365, and to be more specific, also use the email part of it, different rules apply. In that case, the Exchange server isn’t sitting in the customer’s data center, right beside the virtual desktops. The Exchange Server might be in a different country. I have heard several customers now, saying that without using an .OST file, the performance of Exchange in Office 365 isn’t as it used to be when Exchange was on premises.

So, how to deal with this new situation? Best practice is to avoid using .OST files in a Horizon View environment but performance requires them when using Exchange in Office 365. What to do? Well, there are 2 options. Well, 2…. I’m not sure you want to use option #1 but for a couple of exceptions, it might be a valid solution Below the 2 solutions:

  1. Use a Full Clone Dedicated VM for users and enable the Cached Mode. The .OST gets created but the VM won’t get deleted and a user always will end up on the same VM. For a handful users this could be an option.
  2. App Volumes: Use the Writable Disk feature of App Volumes for users to store the .OST file. With a writable volume, user data inside a VM can be redirected to this writable volume. This way, you can use .OST files while using Linked Clone Floating desktops and delete/refresh these desktops after use. Next time a user logs on to a clean VM, the user’s writable volume with the .OST gets mounted and the user can use Outlook with the same performance as before.

With App Volumes you have 2 options to redirect the .OST file

  1. Use the App Volumes ”Profile” template for your writable volumes. This way, a user’s profile will get redirected to the writable volume. By default, the .OST file is being written inside a user’s profile.
  2. Use the “UIA” (User Installed Apps) template for your writable disks. This way you don’t have to redirect a user’s whole profile but just the .OST file. You can use this approach when you use a profile management/user environment management tool like VMware UEM, where UEM saves settings for users to a central place. Make sure you take the .OST file outside a user’s profile; for example, write it to C:\Outlookdata. Saving the .OST file to a different location is possible via a GPO/ADMX setting https://technet.microsoft.com/en-us/library/c6f4cad9-c918-420e-bab3-8b49e1885034#ConfigureDefaultOST

If you aren’t familiar with App Volumes, App Stacks and/or Writable Volumes, please read this VMware blog.

App Volumes and RES Workspace Manager: exclusions

Recently, I have done a Proof of Concept at a customer site with App Volumes. What I didn’t know was the fact that this customer was using RES Workspace Manager. Right after we started the PoC, we found out App Volumes and RES didn’t like each other.

Both App Volumes and RES use filter drivers, and these drivers are conflicting. Symptons are; startmenu settings, which come form RES, aren’t coming through. Also, after mounting an App Volumes app stack, no desktop information is flowing back to the RES management console.

To solve this, you have to update your app stacks and your template(s). You have to modify the snapvol.cfg file in your app stack/template and add exclusions for RES.

To update your app stacks, use the update button in the App Volumes management interface, provision the app stacks, log on to the provisioning machine and browse to C:\SnapVolumesTemp\MountPoints\MountPointxyz\snapvol.cfg and edit the file.

To update your template, follow the procedure described in this KB article.

Below you will find the exclusions for RES for as well 32-bit as 64-bit OS’s. After adding these exclusions, App Volumes and RES worked happily together.

#———RES SOFTWARE EXCLUSIONS BEGIN———————————-
#
exclude_path=\Program Files (x86)\RES Software\Workspace Manager\Data
exclude_path=\Program Files\RES Software\Workspace Manager\Data
exclude_path=%SystemRoot%\System32\drivers\appGuard_amd64.sys
exclude_path=%SystemRoot%\System32\drivers\ImgGuard_amd64.sys
exclude_path=%SystemRoot%\System32\drivers\netGuard_amd64.sys
exclude_path=%SystemRoot%\System32\drivers\RegGuard_amd64.sys
exclude_path=%LOCALAPPDATA%\Res
exclude_path=%SystemRoot%\System32\spool
exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Wow6432Node\RES\Workspace Manager
exclude_registry=\REGISTRY\MACHINE\SOFTWARE\RES\Workspace Manager
exclude_registry=\REGISTRY\USER\SOFTWARE\RES\Workspace Manager
exclude_process_path=\Program Files (x86)\RES Software\Workspace Manager\Data
exclude_process_path=\Program Files\RES Software\Workspace Manager\Data
exclude_process_path=\Program Files (x86)\RES Software\Workspace Manager\svc
exclude_process_path=\Program Files\RES Software\Workspace Manager\svc
exclude_process_name=pwgrids.exe
exclude_process_name=spoolsv.exe
#
#———RES SOFTWARE EXCLUSIONS END————————————