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.

Horizon (with) View: 5 phase design framework

In the last couple of weeks I have been presenting about VMware Professional Services, and more specific, the way they handle a View project from start to finish. VMware PSO follows a standardized framework to deliver a successful Horizon View implementation. This framework, in my honest opinion, isn’t rocket science but surprisingly, I hardly see the steps in this framework being taken by customers or partners when they are doing a VDI project.

I would like to share the framework with you so you will understand how we are approaching a larger Horizon View project. And no, this approach isn’t a secret. In fact, there is a public white paper available on the VMware website which talks about this framework and how we used this with a customer, a car manufacturer, to come up with a 2,100 seat, twin data center Horizon View design and implementation.

The framework consists of 5 phases:

View framework

 

Assess:

During this phase, one of the steps is to investigate your current environment: you monitor your physical desktop environment so you gather information about RAM, CPU, IO and application usage. Tools to do this in a detailed matter are, for example, Lakeside Systrack and Liquidware Labs Stratusphere. A new and easy tool is the VMware Cloud-Hosted Systrack tool. This will give you a good understanding about resource usage of your employees. These tools will also come up with reports and even a recommendation on how many specific ESXi servers you will need when moving to the virtual world. And yes, I agree, the virtual environment will look different than the physical one, and resource usages will be a bit different but at least your will have a good understanding on resource usage and not completely be in the dark.

Also in this phase is describing/understanding the business needs. This is a very important step because this will be the justification for the project and in the end, the justification for the available budget. You can read the business drivers in the car manufacturer use case.

Discover:

One of the steps to take in this phase is to organize workshops. Get employees involved as well. Interview them, ask them what they think about the current environment, what can be done differently, better.

Also, build business use case. Describe which groups are present in the organization; what do these groups needs to get from an IT point of view.

Another step is to build a small scale Proof of Concept/Proof of Technology.

Plan and design:

Picture1

No real need to explain this phase but see below the steps to take within this phase. And do follow them clockwise. To give you an example: I have seen customers buying end point devices first and in the end finding out they didn’t buy the right end points.

Start with Use Case Definitions. Know which groups and users are within your organization and what kind of desktop and apps you would like them to get.

With the Use Cases in mind, you can make a Pool Design easily and with that in mind, you can design View Blocks and Pods, design vSphere, storage and networking. Last but not least, because you know what end users need to get and how they will get it, you know what they need to access everything…the end points.

Build and Test:

In this phase you will build the designed environment. An important step here is load testing. Test the environment and see if your design is working with full load. If it isn’t behaving as expected, this is the time to make adjustments like adding more resources.

Optimize:

And the last phase is to optimize your newly implemented solution, check it is according best practices etc. After that you can bring it into production.

These are the phases we follow during a project. Again, no rocket science but a very structured way of handling a project. Hopefully you think a lot of these steps are open doors/obvious. I just noticed in reality that this framework is just not that common.