Architecting for FSLogix Containers High Availability

FSLogix Profile Container is becoming the go-to solution when it comes to profile management. Even before the Microsoft acquisition, FSLogix was a popular solution, however now that it is effectively an entitlement for the majority of customers, its use will be greatly increased.

Implementing the solution is relatively easy. Dealing with high availability and navigating the options associated with containers, however, is not a simple task, and there are a few points to look at while deciding what architecture may be best suited from an HA perspective.

FSLogix Profile Container and Office Container are simply redirecting a local profile into a VHD/VHDX, making it a block-level solution to profiles. These containers are mounted at user logon effectively mobilising a local profile. A mounted Container is effectively locked at the file system level resulting in challenges with consistent replication.

The following post will discuss scenarios relating to HA options and considerations around replication requirements.

VHD Locations vs Cloud Cache

There are two ways of defining profile locations in the FSLogix world. The first is the traditional path which allows writes to effectively any presented SMB share. Anytime the use of a VHDLocation is defined; we are automatically subscribing to a single active profile location methodology. Only one location can ever be active at one time.

FSLogix does not limit us to defining one location in the VHDLocation pathing; however, only one location based on the order defined, read, and detected as available will be active.

The second option is FSLogix Cloud Cache, an emerging capability which promises the holy grail of Active-Active profile locations.

This dream is realised with Cloud Cache by allowing us to define multiple profile storage locations, be it SMB or Azure Blob at the same time. Because both locations are active and there is a cache capturing reads and writes in the middle, seamless failover between locations can be achieved.

There are five common deployment scenarios I am going to outline below, along with the pros, cons, and considerations associated with each of them, as well as some tooling that can fill in the gaps.

Single SMB Location with single VHD Path

Depicted below is the most common and most simple deployment of the FSLogix solution. It leverages a single SMB location, (be it a Windows File Server, Scale-Out File Server, NAS presented storage such as Nutanix Files or NetApp option)s and requires simply defining one profile share location.


This model is simple to implement; however, in terms of HA, offers a single point of failure for container access.

Additionally, any backup solution that does not do block-level backup can struggle to backup the open container once it is mounted and locked.

Typically environments using this model of access rely on a storage level backup and replication solution alongside a manual restore process.

Multiple SMB Locations with Single VHD Path and DFS

The next scenario is the next most common deployment I have seen, and this is simply implementing what we have traditionally done with other profile solutions to achieve active/passive access. Simply placing a Distributed File System Namespace in front of one or many SMB locations.


In this model, the same rules apply as far as a single VHDLocation is defined. However, the DFS namespace controls where that data lands and in which order.

DFS-N should always be configured in an Active-Passive methodology, ensuring that referrals and folder targets are appropriately leveraged, ensuring consistency of access and in typical useage scenarios, a supported architecture.

This model also introduces a requirement for something to handle the replication of containers across both locations in a consistent fashion (more on this later).

Multiple SMB Locations with Multiple VHD Paths

Choosing to use VHDLocations rather than Cloud Cache does not mean that the ability to define multiple locations is lost.

FSLogix allows for multiple paths to be defined to allow for failover should one location be unavailable. The priority for which location will be used first is defined by the order that the paths are specified in the VHDLocations path.


It is important to note that this model does not provide seamless failover and is designed to help cover the complete loss of a single storage location. There is no seamless failover when defining VHDLocations and as such, a reboot or more likely a reset of the users’ session will be required if a VHDLocation loss occurs in an unplanned fashion.

This model is particularly relevant for Azure-based deployments using VHDLocation with Azure Files, as there is no current way to leverage an Azure Files based file share as a DFS-N endpoint.

As with any multi VHD location-based architecture, there is a requirement to replicate the containers.

FSLogix doesn’t change the game when using VHDLocations regarding Active-Active architectures for solutions such as Citrix Virtual Apps and Desktops, and the same rules apply that would to any profile solution, the key here is architecting around this limitation in a supported fashion – probably a dedicated write up by itself at some point.

Multiple or Single Location Blob Storage (Cloud Cache)

Cloud Cache allows for the consumption of Azure Blobs via Azure Storage Accounts. One or many (up to 4) blobs across multiple Storage Accounts, allowing for true cloud-based storage consumption to be achieved.

Storage as a Service is what the “Cloud” in Cloud Cache is referring to. The rest of the engine is all about the cache.


Blob storage was the first available option for Azure native storage consumption when leveraging FSLogix Cloud Cache, allowing for an individual blob to be created per user in an Azure Storage Account.

The benefit of this model, (along with the next) is that Cloud Cache removes the requirement for a replication tool to be in place and handles active-active profile locations natively. Cloud Cache also allows for the seamless failover between multiple locations.

There is a cost to this capability, and that is an impact on Logon and Logoff times for users due to the requirement to build a local cache on the endpoint. The impact will vary and you should test this against your deployment. Leveraging Service Endpoints on Azure vNets for Storage should help to reduce the impact.

Multiple or single SMB Location (Cloud Cache)

Cloud Cache is not limited to Blob Storage in Azure. It can be leveraged both On-Premises and with any Cloud platform that provides an SMB location to write data.

Cloud Cache can be utilised with any technology that VHDLocations can work with, allowing for active-active profiles across both on-premises and cloud-based locations.


The keen eye may note above that the diagram specifies an AccessNetworkAsComputerObject tag. The reason for this is Azure Files specific and detailed in the next section.

SMB Locations with Azure Considerations

When consuming containers with Azure files via either Cloud Cache or VHD locations. There are a couple of key concepts to be aware of:

  1. To consume and utilise traditional NTFS style Access Control Lists (ACLs) you will require Azure Active Directory Domain Services. Azure Active Directory Domain Services is similar to traditional Active Directory Domain Services offered as a Service in Azure and consumable only by Azure-based virtual machines
  2. To bypass the requirement of ADDS above, FSLogix can be configured to access the Network Location for storing containers as the computer object. This combined with a neat trick from James Rankin where he outlines mapping a network drive in the computer context at machine startup allows for FSLogix to access these storage locations without Azure ADDS
  3. Azure Service Endpoints should help provide faster access to Azure Storage, as well as enabling a higher level of security and protection when used in conjunction with the access controls on the Storage Account

Replication Tools and Options

As discussed in the deployment scenarios above, whenever VHD Locations are utilised, and there are multiple paths at play, some for of Replication Software is required to keep these locations in sync. There are native tools, and there are 3rd party tools that I have utilised in different scenarios, a couple of free options are noted below:

Distributed File System Replications (DFS-R)

DFS-R is inbuilt to the Distributed File System technology within Windows and offers a decent level of replication capability for keeping two locations in sync.

It is a file-based replication solution meaning that it suffers from the same challenges that all file-based replication engines do, and has a nasty history across many deployments. I have seen this work with success; however, it wouldn’t be my first go-to solution these days.

It is also important to note that should you be utilising REFS file system for your containers (which you definitely should where possible), then DFS-R will not be an option for you


The mighty robocopy is still a beast to this day and offers a fantastic free option for keeping your container data in sync. It is, however, once again, a file-based solution so will not be able to replicate mounted containers or locked files. This has been traditionally my preferred method of replication particularly when REFS is at play


I recently stumbled upon this little gem of a solution: BVCKUP2 developed by Alex Pankratov. This solution is unreal for enhancing and filling the shortcomings of Robocopy with an extremely thorough and well-designed user interface. The best part of this solution is that it can handle block-level replication meaning that replicating mounted containers is no issue. I have tested this thoroughly, and the tool is sensational as far as consistently replicating mounted containers in a fast and flexible fashion. I highly recommend this toolset for anyone looking to do multi-location replication of containers.



Yes it has a GUI, but it can also run as a Windows Service. The logging is sensational and I am struggling to fault the tool so far. I am going to be doing some in-depth testing with REFS and Azure Files based replication and see how it plays. I will post findings at a later date.

Final Considerations

A few final things to consider when you are designing your container solutions concerning all the scenarios discussed above:

Cloud Cache

Where it shines:

  • You require a seamless failover should the loss of a single storage location occur
  • You have active-active site requirements and prefer to keep containers close to workloads
  • You want to consume native cloud storage such as Azure Blob
  • You have latency struggles or concerns between the location of storage and location of workloads

Where it struggles:

  • There are obvious logon and logoff delays which impact the user experience. This delay is variable based on many factors such as the location of the container in relation to the location of workloads
  • It is a junior solution with a history of pain but a promise of great things
  • Impact on PVS and MCS IO capabilities may be considerable

VHD Locations

Where they shine:

  • You know what you are getting and how it works
  • Far less impact on write caches such as PVS and MCS IO capabilities

Where they struggle:

  • Manual replication requirements and an active-passive methodology only
  • Lack of seamless failover
  • Can only consume SMB locations. But this is becoming less an issue as Azure Files matures

As with any developing solution, these options will change, mature and differ over time. Furthermore, your mileage on the above may vary depending on your specific use cases and requirements.

Until next time…

35 thoughts on “Architecting for FSLogix Containers High Availability

Add yours

  1. Hi James, excellent overview of the options. How would you handle a Multi-Site design where you want user to be split across two datacenters but in the event of a failure at one site the users can still access upto date profiles in the other datacenter?


      1. James
        If a vhdx is attached, and the profile server reboots. Does the profiles flake? Or continue to work?

        Maybe you can give me some advice, I setup 1 profile server and using fslogix just fine. But I need ha. Any pointers on what appoarch I could take to spin this single point of failure in a ha solution? Just thinking on how to do it without impacting profiles. Some say cloud cache is amazing some say it’s slow. Some say DFS-R doesn’t repllciate locked files . I don’t know where to start.


      2. If a server dies then your connection to that disk is dead – there is no state awareness in multiple vhd locations, simply two locations available – first one in the list is attempted, if dead, go to next

        There are numerous windows technologies inclusive of S2D, SOFS, Continous availability with clustering etc that can help with server HA

        If you need two standalone servers kept in sync with VHDXs then bvckup2 is my choice for replication as it handles locked files due to being block level based – dfs-r or robocopy will fail you in a locked/mounted scenario

        Cloud cache is awesome but has some speed overheads


  2. Have you guys seen if you use the FSlogix compacting tool from here

    That after the use of it, it will destroy login speeds?
    Nice tool, but ever since we used it, logins are 150+seconds. I only tested it with 5 users, luckly.
    I can see in the logs that FSLogix VHDX is loaded. But the Windows Shell is delayed big time ( I use autoRuns to keep the Shell clean) Doesn’t happen on fresh profiles or once that the tools hasn’t been use done. Just curious if anybody has seen this?


  3. We are piloting the use of the Office Containers on VMWare VDI to try and off load the load OST file from the local VM. I am using Cloud Cache with 2 container locations but there is still a local OST file on the VM.

    Is ther a way to use Cloud Cache for HA\DR but also completely offload the OST from the local VM storage?


  4. Hi James — you mention that the Cloud Cache option: ‘Impact on PVS and MCS IO capabilities may be considerable’. Have you done any specific testing on this? I’m just curious what you found or what the specific issues are to be aware of.


  5. Thank you James for the great articles. I am having issues using Bvckup2 replicating the vhd files to another location. It looks like they are replicated fine, but if a fail over happens and those backup location become active the profiles are corrupt.
    The Bvckup disk attaches fine, but Outlook complains about corrupt ost files and needs to be deleted and rebuilt, Office 365 loses its token and needs to be activated again and any shortcuts or customization are broken. We run Bvckup as a service doing delta copies every 6 hours to keep the profiles as up to date as possible.

    Its too bad because we purchased this product specifically for this reason.


    1. i have not seen that behavior and i know of very large environments replicating using this tool at scale – maybe jump into the world of euc slack channel and post in there as you will likely get some real time guidance


    2. Hi Pete – Did you find a fix for this issue? I have the same issue when replicating profiles to a backup location using Bvckup2, the Outlook OST file is out of date and needs to be deleted and rebuilt. Thanks


    3. Wow – I don’t know how i missed this post. My apologies – I have not seen this, and bvckup2 is 100% my tool of choice for real time replication – I am not sure why this would be occurring in your environment


      1. Pete – were you using Office and Profile container? We currently have the OST file configured in the profile container, which may be our issue. Before we introduced the OST files, the bvckup2 software ran prefect every night and using the copied profiles was successful. thanks.


  6. Hi James,

    Why agent bothers looking into all locations defined in VHDLocations for a VHD when a user logs in? Anyhow, if the VHD is not available on the primary location, it will be created, doesn’t matter even if it is available on the secondary location by any mean of replication.


  7. G’day James. Thanks for the tip on BVCKUP2. I’ve just recommended it for a client who needs to move 7TB of profile disks to a new file cluster (they are using VHDLocations). Block copy delta replication is an awesome feature for such an inexpensive tool.


  8. Hi James !

    I hope you feel good ! Great post again ! you made the job 🙂

    One question about replication: your replication is one way direction ?
    Ex: You configure StorageA as first location in Cloud Cache and StorageB as second. You replicate StorageA to StorageB.
    When you failover to StorageB, how to be sure that replication will not override user’s change on StorageB ?

    I hope you understand what I mean 🙂

    See you


    1. Ello mate 🙂 I don’t use any form of replication technology when Cloud Cache is at play – for CC deployments, it’s just CC handling the data

      for normal deployments (VHD locations) then the expectation is set that one data source is always king. Users houses in Site A will have their data available if they land in Site B, but their data won’t be retained, Site A will always be authoritative

      Make sense?


      1. Hey.
        Yes make sense. I misunderstood the fact that replication only impact FSLogix without Cloud Cache.
        I hope everything is fine for you !
        Thanks again for your time to answer me.


  9. Hi James, I’ve implemented CloudCache specifically for high availability on a 6 node 2016 RDS farm and was quite pleased with how it’s working. I’d set up a separate disk on each server to house the cached containers as I thought these would quickly eat into C: drive space and cause the server issues. However, I’ve just noticed that the user’s profile container is not only cached onto our extra designated disk but is also cached under the C:\Programdata\FSLogix\Proxy folder. So basically FSLogix caches the profile container twice. I can’t believe that Microsoft would configure CC like this but is this the case and is there any way around this?


    1. This is a proxy only location, there is no data actually stored there, it’s just proxied. I believe in certain scenarios this proxy location can be moved, but i have never seen it done nor had the need, as long as your cache is relocated, you are set


  10. Thats what I thought but it’s not what I’m seeing. Within the Proxy folder there’s also a vhdx file – the same as which is also in the Cache folder. If you check the documentation it does state that the locations should not be the same as they use the same name: “CacheDirectory and ProxyDirectory MUST NOT be the same location as the Proxy File and the Cache File are the same name and will conflict.”


  11. I thought that when I first looked at it because if you look at the properties of the file it says “size on disk” = 0 bytes. But if I look in TreeSize.. it does say it’s using data so I wasn’t convinced.. but maybe you’re right


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 )

Google photo

You are commenting using your Google 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

Create a website or blog at

Up ↑

%d bloggers like this: