Cloud Cache, the newest technology to come out of the FSLogix locker, allows you to store multiple copies of your OST or Profile Containers on SMB file shares without the need to deploy complex replication infrastructure. It also reduces IOP consumption on storage locations by caching containers locally on your machine. The Cloud Cache technology itself won Best of Citrix Synergy 2018 New Technology and Best of Show awards at Citrix Synergy 2018 in Anaheim, CA.
Companies all over face the challenge of making data highly available and accessible on-demand, anywhere in the world. That same challenge exists for user profile data. FSLogix already has a solution that makes user profiles roam between virtual and/or physical desktops, they also have a similar solution for roaming Office 365 data files. With or without FSLogix containers in your environment though, you had to make sure that such data was highly available regardless of file server failure, storage failure, or even datacentre failure.
Typically, in the case of profile storage, you would have to deploy complex replication technologies such as DFS Namespaces or DFS replication to achieve the goal of a robust profile solution, or deploy hardware level replication using Network-attached Storage solutions.
FSLogix now cuts out that complexity completely, as it is able with the Cloud Cache feature to keep containers which hold profile related data in sync across multiple data locations. This really simplifies not only the deployment of containers, but also the high availability requirement that generally comes with it.
What’s more, the technology is also able to cache containers locally on your machine. This means that all those read operations that used to hit your file servers, are now directed to the cache. As a result, interactivity between the Windows Operating System/applications and the containers are improved resulting in a better user experience.
Let’s run through some scenarios where Cloud Cache can add great value to your environment if you are an already existing FSLogix customer or not.
Example scenarios:
Storing copies of profiles across multiple on-premises storage locations:
- Using Cloud Cache, you simply create a registry string specifying the data locations that a container should be copied to. This string resides on each desktop that uses FSLogix apps. There is no need to deploy DFS type replication technologies, or hardware replication. Simply create SMB shares within the same datacentre or across multiple datacentres that could potentially span the globe and add those locations in to the string. As users log on and their profile or OST containers are created, the containers magically replicate to all other defined locations.
Easily replicate data to your disaster recovery datacentre:
- Like above, you simply reference the SMB file share(s) that exist in your secondary datacentre and that data is replicated. Maybe you have a set of physical desktops using FSLogix Profile Container, and the primary datacentre fails. On each physical endpoint, Cloud Cache detects that the primary SMB file share is unavailable, so switches the machine over to the secondary location residing in your DR datacentre, allowing continuous access to your profiles.
Replicate data to cheaper storage:
- You may have a requirement to replicate profile related data to a secondary location, but on cheaper storage. So, your primary SMB file shares reside on more expensive, high-performing flash storage, and you have the backup storage configured which is cheaper to run and simply acts as a passive failover target in the event that the primary location goes offline. Using Cloud Cache, you can simply reference the cheaper storage as a secondary storage location and profile data is continuously replicated to this location to protect from primary storage location outage.
Migrate from one storage location to the other:
- You likely have faced the issue before. Your main profile file servers have run out of disk space, or maybe it is time to replace the operating system or even the underlying storage. You now must plan out keeping profile data for hundreds of staff available during migration. Cloud Cache makes it a breeze to do just that. Simply stand up your new storage or file servers running the latest operating systems, edit the string I mentioned before on each of your physical or/and virtual desktops, specify the new SMB file share as a secondary location. At this stage the profiles will synchronise to this location (from primary). Once synchronisation is complete, switch the secondary location to primary and you are done.
What is required to get Cloud Cache up and running?
- Windows 7 32/64bit and above Desktop OS running the FSLogix Agent.
- Windows Server 2008 R2 and above Server OS running the FSLogix Agent.
- Either Profile Containers or Office 365 Containers configured via the ADMX Group Policy provided with the installation media.
- Configure the CCDLocations string with references to each of your SMB file shares that containers will be replicated to.
Seeing Cloud Cache in action:
Setting up Cloud Cache:
Before using Cloud Cache, you need to update your physical or virtual machines with the latest Cloud Cache supported FSLogix Apps version. Obtain the latest media and copy the ADMX/ADML files to your SYSVOL PolicyDefinitions folder.
The installer takes just a short moment to complete.
Click Restart to complete the installation. 
Make sure via Group Policy that you set policy setting Enabled to Enabled under Computer Configuration -> Administrative Templates -> FSLogix -> Profile Containers or else Office 365 Containers if you aren’t redirecting the entire profile to a container.
Note: Do not set a VHD location.
Now, on each virtual or physical desktop that has FSLogix Apps installed and that will use Cloud Cache, create a CCDLocations string under HKLM\SOFTWARE\FSLogix\Profiles. The string value will contain each SMB share that will store a copy of your containers in the format of type=smb,connectionString=\\yourSMBshare.
My example: type=smb,connectionString=\\file01.jgspiers.com\CCShare
Note: You don’t have to reboot the machine for this string to take effect.
The next time a user logs on to those machines, a container will be created in the previously specified SMB share. In this example to grow the container, I created a couple of different files on the Desktop, Documents and Downloads folders.
I also configured an Outlook email account so that my OST would be captured in the container as well.
Navigating to the primary Cloud Cache SMB location (file01.jgspiers.com\CCShare) I can see that a container was created for me and is currently just over 600MB in size. I have a secondary Cloud Cache SMB share which does not have a copy of the profile yet, this SMB location is file02.jgspiers.com\CCShare.
Replicate containers to a secondary location:
To replicate containers to a secondary SMB storage location, it is simply a case of adding the secondary location to the CCDLocations string mentioned previously. Yes, it is that easy.
My new example: type=smb,connectionString=\\file01.jgspiers.com\CCShare;type=smb,connectionString=\\file02.jgspiers.com
The next time you log on to the machine that has this CCDLocations string set with multiple SMB shares defined, your container is automatically replicated to the secondary location as shown below. Now you have a fully redundant solution that is easily configurable compared to other methods such as when using DFS and dealing with multiple targets.
Log files:
Log files are kept on each desktop machine under %ProgramData\FSLogix\Logs and in particular the Profile log is useful to confirm that a container was successfully loaded. As shown in the below log file, the LoadProfile successful message shows for which user a profile container was successfully loaded for.
Failover testing:
So, what happens when the primary file server fails? In this case, FSLogix Cloud Cache quickly detects a storage location as being unavailable, and will switch to the next available storage location as defined in CCDLocations. In my case, file02.jgspiers.com
file01.jgspiers.com has been completely turned off, but you don’t have to manually enable new SMB targets or activate failover processes, everything is taken care of automatically by Cloud Cache.
As shown again in the logs, when logging on to a machine the container was not found on file01.jgspiers.com due to a failure however it was found on file02.jgspiers.com, as you can see by the File was found on SMB provider: \\file02.jgspiers.com\CCShare\ and Successfully attached messages. 
Hopefully this demonstration showed you just how easy it is to configure Cloud Cache and have a fully redundant profile solution in minimal time.
IOPS reduction:
Not only is Cloud Cache beneficial for replicating multiple copies of containers easily to SMB shares, it is as hinted in the name also beneficial in reducing load on those SMB file shares that provide you with containers. When you download your user profile and use technologies such as Microsoft folder redirection or Citrix Profile Management, a lot of read requests are sent from the endpoint to file server hosting your data. The nature of FSLogix Containers already reduces the network load on your file servers, and now with Cloud Cache in the mix the read IOPS are dramatically reduced, too. This is achieved as the container is cached on the local machine you are using. That may be any number of your physical or virtual desktops. You can either persistently cache the container, or you also have the option of clearing it down between reboots.
Take the below example. Here I am logging on to a machine using plain FSLogix Profile Containers. The read IOPS (in red) peak at 163 IOPS per second, now multiply that by the hundreds during a 9am logon rush.
Once you have deployed Cloud Cache alongside your Profile or OST Containers, logging on to an endpoint that has the container cached results in zero reads being sent to the primary SMB file server. Not only does this result in a better performing file server, but your own endpoint performance when logging on and browsing the contents of your profile is improved because that data is now local.
Another example of IOPS consumption is shown below using FSLogix Profile Containers without Cloud Cache and browsing through emails. Even a delicate activity such as this sends IOPS to the SMB file share. However, again with Cloud Cache deployed no read IOPS were sent to the file server, and for that reason I didn’t even bother taking a screenshot!
Some of the benefits of caching a profile locally include:
- Reduced load on file servers.
- Better performance within a desktop as profile data is local.
- Applications that depend on the profile continue to perform as that profile is local.
- Trips to SMB shares that may be stored in the public cloud are saved as instead the trip is kept local.
- Products like OneDrive will not have to make trips to Office 365 every time you are accessing data there, as it is now cached locally on the endpoint.
Summary:
I covered in this article how Cloud Cache extends the functionality of FSLogix Profile and Office 365 Containers by seamlessly replicating containers to multiple storage locations for high availability. Furthermore, Cloud Cache reduces read IOPS consumption on file servers by caching containers on local physical or virtual machins.
Finally, you may be wondering where the “cloud” in Cloud Cache comes from. Future releases will add support for native cloud storage, allowing you to avoid expensive SMB-based resources or complicated storage gateways. When available, you’ll be able to use cloud locations just as you would any SMB locations, and even use a mix of both. The first public cloud storage solution FSLogix expects to support will be Azure Page Blobs, and additional services will be added based on customer feedback and demand. Cloud functionality is expected to become available in Q3, 2018.
I did all of my testing with the Tech Preview, and if anything changes when Cloud Cache goes to GA, I’ll update it here. I want to mention that from my own testing of Cloud Cache, I see a tremendous amount of potential in this technology due to the way it will allow customers to deploy highly redundant and flexible profile solutions with ease.
Flo
October 3, 2018Thanks for the post, great article!
IOPs reduction is a important topic in our environment but when using PVS with non-persistant VM’s, caching containers locally does not really work, right?
BR Flo
George Spiers
October 8, 2018Caching containers does work for non-persistent VMs, but they will re-cache when the VMs reboot. You will be able to experience the caching benefits however during the VM run-time.
Of course persistent and physical PCs don’t have to re-cache every time, which is an added plus.
Calib Williams
February 28, 2019Thanks for the write up.
Is there a process of moving all of your current FSlogix profiles to the new Cloud Cache? Also can you choose the location of the local cache?
Thanks!
George Spiers
March 7, 2019You can specify the location of the local cache via GPO, for example the D:\ drive. Cloud Cache works on your existing SMB storage. If you want to move to a new location, you can create a new CCDLocations path. Once you specify the CCDLocations it will automatically upgrade the existing profile containers or O365 containers to a cloud cache compatible one and initiate the synchronisation to the other locations specified.
Hermann
April 1, 2019Hey,
i have configured the CLoudCache with 2 Locations. The VHDX Files are replicated and it looks fine. But if i disable the share for the first location, the Users can’t login to the Server. If i enable the first Share again it works fine. Must i define some other Settings?
George Spiers
April 2, 2019Have you looked at the log files? %ProgramData\FSLogix\Logs
Double-check permissions, also double check you can use the second location by itself.
Hermann
April 12, 2019Hey,after i change the DFS Namespace to \\Servername\ the problem was solved.
Ray
April 6, 2019This is awesome dude
Is it configurable through GPO or just reg settings?
George Spiers
April 9, 2019You can configure via GPO as well
Hermann
April 12, 2019What is the best Practice with PVS?
When User copy Files from Filserver to Userprofile the Cache filled up.
Regards
Hermann
George Spiers
April 16, 2019What cache filled up, the PVS Write Cache or do you mean the FSLogix container? Assuming you are using Profile Containers.
Anonymous
April 23, 2019Hey, we use Profile Containers and the PVS Cache D:\ filled up.
Also the C Drive running out Diskspace when some Users are logged in with a large Profile (40GB).
Wich Size should the virtual C Drive have?
And what can i do that the PVS Cache not filled up?
Regards
Hermann
George Spiers
April 24, 2019You can move the Local Cache location to your Write Cache D:\ drive for example, so that C:\ space is not affected. Just make sure the Write Cache drive is large enough to store the Local Cache (Container). Also you should make sure that the Container is cleared at logoff. You can do that via Group Policy.
James
November 12, 2019I enabled the Write Cache Director to point to D:\FSLogic\Cache. I see the VDA gets the policy in the registry but nothing is written to the cache directory and the vdiskdif keeps increasing and a quick rate. Am I missing something?
Richard Hughes-Chen
May 15, 2019Anyone had much success with simultaneously accessing Profile or O365 containers with Cloud Cache? I’ve setup
profile types which create RW disks on the CCD share, the first machine is fine but subsequent machines (Windows 10 VDAs) take forever to login.
Bogdan
November 20, 2019I had also this issue and I came up in disabling the CC. I used the CC only with one location just to get the benefit of the local cache in case the storage is not available for short periods.
Sandeep Goli
June 18, 2019Hey George,
Another great article from you. Thank you:). Where is the CloudCache hosted? can this be on a local VM based File Share server or Can it be on a NAS box like Unnity? Also, i would like to know if this can be worked with Citrix AppLayering, that means Applications will be dynamically assigned from AppLayering appliance and User Profile to be from FSLogix? I might be sounding stupid but I have to enable two sites that we have to be active.
Regards,
Sandeep
George Spiers
June 20, 2019Hello, yes SMB storage is supported on-premises or in public cloud. The Containers can also be hosted on Azure Page Blobs. It can work with App Layering.
Sandeep Goli
June 20, 2019How FSLogix replication between CloudCache SMB shares located at different Data Centers happens in real time? Why I ask is because when the profile container VHDX is mounted when a user logs in and reading it’s content and replicate in real time is not possible. Or it replicated the disks as is?
Richard Hughes-Chen
June 20, 2019It does replicate in real time from what I have found. I am also looking to implement this in a Active Active setup but what strikes me is it doesn’t seem to handle concurrent connections that well as the 2nd logon is Read Only.
sam
November 1, 2019Hey George,
Is there a good configuration example using Azure Blobs as a CCDLocation? I am trying to get this configuration working, but it fails. SMB shares works fine. I think my connection string to Azure Page Blob is wrong.
George Spiers
November 18, 2019Not much out there, but did find this: https://www.youtube.com/watch?v=b-0qSFk-6nE
Ray
August 6, 2019Can I take my existing location that is used. Which is just the plan path in fslogix profile and office container. Then add the same paths into the cloud location. Put the same path first. Let me I had o. The basic location. Then add a second path for redundancy? I don’t want to hinder current profiles. I assume I have to undo the basic path as well. Not sure how to go about doing this.
George Spiers
August 16, 2019Yes that is possible and essentially enables Cloud Cache in your environment.
Richard Hughes-Chen
August 16, 2019Anyone experiencing black screen when using the Cloud Cache in Windows 10 1809? Works fine with Server 2016.
Splinter
January 27, 2020Try yo disable your virus protection or exclude. Vhdx extention scanning.
Richard Hughes-Chen
August 16, 2019Ok so seems that upgrading to latest general release FSLogix_Apps_2.9.7117.27413 has fixed it but I now seem to have the issue with Server 2016 intermitently. So I am not thinking is it because I am sharing the same CloudCache location for both RDS and VDI containers? should these be separate for the O365 vhd cache?
George Athin
September 2, 2019Thanks for the article George,
I configured successfully cloud cache with 2 file server locations. My concern though, is the local profiles created on concurrent users sessions, they are using One drive and have large profiles. Is there any advise/idea for mitigating this situation ?
George Spiers
September 2, 2019I suggest redirecting most of the profile, and also analysing some of the local profiles to see what you could exclude from storing in a Profile Container. You can then set exclusions for the things you don’t want in your Containers.
Richard
September 2, 2019Hi George, Can FSLogix be used with “Roaming Profiles” for OneDrive and Teams without moving fully to FSlogix Profile containers? I have the Office containers working in a POC at the moment but the client need to keep Roaming profiles for the time being.
George Spiers
September 5, 2019You could use the Office 365 Container for Teams/OneDrive, and then Roaming Profiles for the rest.
Neven Kottnig
October 25, 2019Hi George,
what about XenApp and XenApp applications (formerly known as Published Desktop)
and configurations in non-persistent environment, in regards to “cached” O365 containers to XenApp server users is logged on?.
Does it make any sence, since users will not logon every time to the same XenApp server….?
Knd regards,
Neven Kottnig
George Spiers
November 10, 2019You can cache to a persisted drive if you want, but I see what you are saying. I typically wouldn’t cache to non-persistent machines. Whilst caching will reduce IOPS to file servers and likely users will receive a better experience, caching every morning during logons storms would make me uneasy.
Richard
November 13, 2019Hi George, I thought that Office containers did cache locally when using Cloud Cache but you can clear the cache file on logoff.
George Spiers
December 3, 2019Yes if you enable Cloud Cache, the container will cache by default to C:
Francis
September 15, 2020Hi,
As far as I can read it seems it caches read when they happens but not caches all the profile at logon (except if all profile was read).
https://docs.microsoft.com/en-us/fslogix/cloud-cache-resiliency-availability-cncpt
So if this is right, this should not cause much troubles to enable it for un-persistent VDI as it will not generate more read but only use space for cache.
John
December 20, 2019George,
Any idea of the IOPS impact on the local VM with Cloud Cache? I’m concerned about stressing our VDI datastores. FSLogix indicates that standard VHD(X) redirection is about 2 IOPS per user – any idea if it’s the same for Cloud Cache? We are primarily interested in FSLogix for handling OST files.
George Spiers
December 29, 2019Cloud Cache is no different. With Cloud Cache you can cache the VHDX to the virtual machine, reducing IOPS on your datastores.
Matt
February 17, 2020Hey I noticed your connection string for the CCLocation has a comma instead of a semi-colon in-between the two smb locations. I was looking at the ADMX template in my environment and it says to use a semi-colon.
George Spiers
May 10, 2020Thank you – just a typo in text.
Amit Singh
April 17, 2020Hello,
I have setup FSLogix to store .OST files only and create a windows file share to store those .OST files. But i want to distribute the OST files loads on 2 or 3 file servers as we have 1000 users who are using VDIs desktops. How i can do that? please suggest me ASAP.
George Spiers
September 7, 2020Couple of options: Different policies applying to different VDI desktops. Desktops restricted to certain user groups. Shares that make use of AD attributes to point users at correct file server.
Jim
May 1, 2020Hi,
Does using Cloud Cache to replicate Profile Containers from a local data center to a remote DR site cause a lot of WAN traffic to the DR site at user logon?
George Spiers
September 9, 2020Profiles are replicated continuously, not just at user logon. There will be a bit of extra traffic if a new profile container is created. Subsequent logons you would expect not so much.
IT
October 12, 2020Hi George,
is there any estimation about the cloud cache storage capacity requirements?
Phill
October 22, 2020Thank you for the article. As a test, I set up Cloud Cache to replicate the VHD profile of a single PC to an SMB storage at a different location. It works but I can see that it is using a lot of bandwidth on our network. Any suggestions what I can do about that?
Mario Grunert
February 8, 2021Looking through a bunch of Fileshare and having these scripts sounds for me not like a stable way. I think it is more important to spread the users equally over several shares in a “fixed” manner. What about mapping the file share by logon script ?
For scaling up to 4 Fileservers with 4 Shares each this would doing the cake.
[byte]$hash=[math]::Abs($env:Username.GetHashCode() % 16)
$fsxpath = “\\EMERALDFS{0:d2}.OZ.LOCAL\FSXSHARE{1:d2}$\fsx\{2}” -f [byte][Math]::Floor($hash / 4 + 1), [Byte]($hash % 4 + 1), [string]($env:USERNAME)
New-SmbMapping -LocalPath F: -RemotePath $fsxpath -UseWriteThrough -RequirePrivacy
This would distribute all users :
\\EMERALDFS01.OZ.LOCAL\FSXSHARE01$\tinman.nobrain
…
\\EMERALDFS04.OZ.LOCAL\FSXSHARE04$\lion.noheart
Ilyas Ahmed
December 25, 2021Hi George,
Hope you are doing well.
I have Active / Active DR for Citrix VDI using ADC GSLB. Prepared two profile server both Sites and configured CCD location string for the same. I am able to login on Site A and checked profile container is created at both sites profile servers.
My issue is when I am login into Site B I am not able to load the profile form the Site B profile server.
Could you please help me how to achive this in case of Active / Active DR?
Thanks in Advanced.
Abhishek Mishra
February 17, 2022For site B – you need to configure site B SMB shared path in FSLogix policies to load site profile server.it always connect first smb available in CCD location, incase of failure it will connect second SMB.
For example site A (GPO)
\\siteA , \\site B in CCD location
For example B (GPO)
\\siteB,\\SiteA in CCD location
Regards,
Abhishek Mishra