Caching… Office 365 rules (not)

Finally… after months of testing, debating and begging for funds your company trades the known on-premise Exchange and SharePoint server with the online cloud version in Office 365. Just like all the other companies you know, so: why not?

One important reason: You need caching!

As you move from your on-premise servers with 0ms-latency from your VDI or RDS environment, you will quickly find out that this latency jumps to 50-100ms (or more). For your IT testers this is no problem. They send and receive 10 mails a day and have 1 scheduled appointment: ‘time to go home’. They will all state that it feels a bit slower, but it’s nearly not noticeable.

I would advise: add a management secretary in the testpool. They receive 10 mails a minute, manage 10 mailboxes, have 15 shared calendars and a lot more. They will notice, most likely instantly after migrating (and come and visit you).

The answer you come up with: We enable caching!

But… caching requires to store the cache. Anywhere… Preferably somewhere you can access it again after logging on the next day as well, to prevent losing this cache (and having a daily performance penalty for building the cache from scratch). Little note, most applications don’t like (or don’t allow) to store the cache on a network location, like in your homedrive. Also your storage cluster will thank you for not doing that (fileservers start having issues if ~100 users have their OST files on a fileshare due to the large number of open handles).

Doing a quick search helps identifying that you are not the first to have this issue. There are several options to tackle this, but the simplest is to prevent the data having to be re-downloaded next time you logon. This can be realized by placing the cache data in a persistent storage. And this persistent storage is: a virtual hard drive (VHD).

This VHD can be placed on a normal network share. It can quickly be mounted (at user logon) and you can redirect data to this VHD. It solves several issues, like the load on the fileserver (VHD communication is by far less demanding because it’s a single file). The solutions you find either cost money, or are bound to a specific platform (VMware layering does not work efficiently in combination with Citrix, Microsoft UPD is limited in configuration and management, Citrix UPM actually is an optimized roaming profile) or another reason you or the management would say ‘not now’…

But: We have Scense!

As always, the flexibility of Scense allows us to build the solution ourselves! What we want to do is mount a VHD, how hard can that be…? Even Windows XP already could do that! And with the new tools this just gets easier (I mean: Powershell has VHD commands built-in), but we even could fall back to good old DiskPart. What we want to do:

  1. Check if there is a VHD for the user available
    • NO: Create one (clone a template)
  2. Mount this VHD to the B:-drive, and hide the drive (not visible in explorer)
    B:…? Why would you do that?
    Answer: have you ever seen a virtual machine with a floppy disk? Even 2 disks? B: is the ‘never used since 2000’ driveletter, so why not re-use it?
    By hiding it, users will not start to browse the drive and fill it with pictures of their cat.
  3. In case the mount fails: NET USE B: %TEMP%\DRIVE-B
    This way we always have a working B:-drive. This makes the following steps a lot easier…
  4. Redirect all cachedata to the B:-Drive
    For example: Outlook OST, OneNote-cache data, your CAD application, …
    Preferred: put data in separate folders to be able to easily clean it up later on.
  5. At logoff: unmount the VHD

Biggest advantage: It is quite dummy proof and even if the mount fails: you have a work around. This is not optimal (as it will download the data during this session), but we could optimize by eg. ordering Outlook to work in Online mode for the time being.

  • RDS Note:
    The above currently ONLY works on VDI or systems where only 1 user is logged on at a time. Disks are system wide, so this B:-drive can be mounted only once. If you want this to work on a RDS system the B:-drive has to be mounted as a sub-folder in the user profile. The disadvantage however is that not all applications like symbolic links or mount-points, like OneNote, OneDrive…

On the Scense Forum I uploaded the extension to mount a personal VHD at logon. Feel free to download it from there (link).
This extension is a (working) proof of concept. You will need to customize it to fit your needs. It has some known restrictions:

  • It uses powershell, so it will only work on Win8.x/10/Server 2012/2016
    Similarly: the used simple approach of mounting it to the B:-drive does not work in Multi-user situations (RDS servers, …)
  • The demo uses a VHD on the (local) D:-drive (demo purposes)
    Change the location in the mount (@logon) and unmount (@logoff) extensions
  • The VHD has to exist, it has to be formatted and the drive assignment for the partition has to be B:
    The script only mounts the disk, it does not assign the driveletter (who extends the script?). Similar the SUBST-fallback-action should be part of the mount-process, so it is a single activity. I left it separate as the SUBST can be practical in other situations as well.
  • It could be desired to have a template-copy operation.
    Create a template VHD, put it in a common location and during the mount, if the disk should be mounted but not yet exists: copy the template…




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s