FSLogix and using the “OnPrem” Cloud cache

Recently I had a little challenge with an on Prem VMware Horizon VDI environment and the implementation with FSLogix Office and Profile Containers.

Due to restrictions there was only one file server available based on Microsoft. In case of an outage the server is replicated to another datacenter but it would take a short time to be available.

This and the fact of course the server needs Windows Patches with their respective reboots gave me a bit of a puzzle.

Why? Well if an FSLogix container is mounted and the file server is rebooted.. please prepare for unforeseen consequences

Ok let us not get dramatic here but I got your attention.

In case of the FSLogix Office container Outlook would freeze and that would result in a lot calls to your support team. More important: possible loss of work resulting in annoyed users. We don’t want that to happen do we?

In case of the Profile container.. it is like pulling out the profile in a running session.. once again unforeseen consequenses.

But did you know you could use the FSLogix Cloud Cache to mitigate this, even just for your on premise environment?

First things first:

What is FSLogix Cloud cache and how does this work?

Cloud Cache is a feature that works with Profile and ODFC containers to provide resiliency and high availability. Cloud Cache uses the locally mounted container to provide periodic updates to the remote storage providers. Cloud Cache is designed to insulate users from short-term or intermittent local (inner-region, close proximity) storage issues. Based on the configuration, it can also be used as part of a Business Continuity or Disaster Recovery (BCDR) plan when using remote storage providers in different regions. Using Cloud Cache puts a performance and storage requirement on the virtual machine to accommodate the extra I/O operations and storage required by the local cache.

So what this does instead of mounting the container remotely on the file server it creates a local container and mount this one. As you access the data, the data is cached locally at block level so do not worry the entire container is copied over.

Every write you do will also be cached locally and then written to the remote share.

As the name suggests this was initially designed when using cloud storage, for example Azure Files.

When there is a short disruption in connectivity the user could continue to work and wouldn’t notice a thing.

But you could also benefit from this solution on premises when there is a risk of a (short) disruption of the file services.

How to configure this?

Normally you would configure (If using GPO’s and I’m presuming you do) the VHD locations setting to configure the VHD location. When using CloudCache please set this to not Configured or Empty

Instead open the Cloud Cache folder in the GPO

Edit the following GPO

CCD Location.

Enter the location of the container in the following format:

type=smb,name="WINDOWS SMB PROVIDER"

In my lab this results in the following connection string

type=smb,connectionString=\\LAB\FS\FSLOGIX\%USERNAME%

Clear cache on Logoff.

I did not configure this since I’m using non persistent VDI. Enable this when using Shared desktop solutions like RDS, Xenapp etc etc

Healthy Providers Required for register

The explanation in the GPO explain this well

this setting specifies the number of healthy CCD Locations required to allow a sign in. If using the default setting, users will always be allowed to sign in, even if no CCD Locations are available.

If a user signs in with no available CCD Locations, FSLogix assumes that one or more CCD Locations will become available prior to the user signing out. If a CCD Locations does not become available during the time of the user session, then the user is prevented from signing out (discussed in Healthy Provider Required For Unregister).

I set this to 1 when using Profile containers. I don’t want the users to login when their cached profile is not available. On the other hand this could also be a non issue when only using it for Outlook Cache.

Healthy Providers Required for unregister

This setting specifies the number of healthy CCD Locations required for a user to sign out. The default setting is 1, meaning that at least one remote CCD Location is required for the user to sign out.

If the number of available CCD Locations, when a user attempts to sign out, is less than the number set for Healthy Providers Required For Unregister, the user's sign out will be prevented for the time specified in CCD Unregister Timeout.

What this one actually does is holding the logoff of the user session in case the container location is temporarily unavailable. It will hold this until the CCD location comes available again writes back the cached data and then finishes the logoff.. Also think this one trough. You don’t want to hold the session indefinitely but you also don’t want the data in the cache to get lost. (depending the stuff you allowed to cache) You can configure the CCD unregister timeout in the advanced folder of the GPO

Multiple Locations

But did you know you could also use cloud cache configuration to create an active/active container on multiple file servers locations? Just add multiple SMB locations and the FSLogix agent will keep the containers in sync by writing to both location simultaneously, so no in theory no more replication needed.

Enter the multiple locations like this in the CCD Location GPO setting:

type=smb,connectionString=\\Location1\Folder1;type=smb,connectionString=\\Location2\folder2

In case one location is unavailable it will automatically do the non-cached reads on the secondary location. Of course you could also use this keep the reads in the most preferred location but fail over to the other location in case it becomes unavailable. For example when using the VMware Horizon Cloud Pod Architecture and have active pools on multiple sites.

But Consider:

• You will put more strain on the local storage of the (for example) VDI. This could either be a benefit when you have space and IOPS to spare on the local storage but the central storage solution is under pressure . Seen this multiple times when using VSAN. It could also be a strain when the storage is limited when for example using local storage of the host for cache.

• You will use more storage per VDI/Session. Keep this in mind when sizing. Especially when for example using Citrix Provisioning. Full writecache means end of session…

Hope this was informative, if you have any questions or remarks please let me know!