We are looking to deploy a new file server cluster, one of the things of which to be stored on it, will be Server 2012 R2 remote desktop User Profile Disks (UPDs).

My question is, is it best practice to store these on a standard file server cluster, or on a scale out file server cluster (SOFS).

My understanding is, that SOFS is intended for Hyper-V vmdk files as they are constantly open and that is the intent of SOFS. It is not intended for standard files and folders that have a high number of metadata changes.

As user profile disks will be long opened files and not ones that are constantly opened and closed, I would have thought they would be best placed on a SOFS cluster.

Hoping someone can point me in the direction of best practices for user profiles disks on a file server cluster, and what type should be used.


SOFS isn't expected to work with anything except supported scenarios: Hyper-V VMs, and SQL Server databases. Reason is simple: SOFS uses CA (Continuously Available) File Shares and these "guys" aren't cached, so "general purpose" file access performance is going to be mediocre at best.



  • This is the exact reason I thought SOFS was better suited to host user profile disks, as they need to be opened once first thing in the morning, and need continuous availability throughout the day until a user logs off. On paper, SOFS sounds perfect for hosting UPDs, but I can't then find anyway to backup the data stored on the CSVFS. – James Edmonds Sep 12 '17 at 20:04
  • CA is tightly coupled with so-called Transparent Failover, from what I understand you don't need CA / TF for user profiles, so just a clustered SMB3 file share should work just fine! – BaronSamedi1958 Sep 13 '17 at 9:43
  • Would a failover on a normal cluster not break the connection between the VHD and the server it was mounted on? Or would the mounting be able to handle a brief disruption in network connectivity? We have seen in the past, if there is a significant disruption between file server and session host, the VHD connection is dropped and users' active sessions are left in limbo until they log out and back in. That is what I was hoping the CA feature of SOFS would prevent. I will try and test this on a standard cluster if I have time though. – James Edmonds Sep 13 '17 at 9:48
  • There will be slight delay in service for "normal" failover with non-CA SMB3 clustered file share. – BaronSamedi1958 Sep 13 '17 at 9:51
  • I'll have to test the VHD tolerance then, as I have the fear it won't handle it well enough to be transparent for the users. Thanks for your input thsufar. – James Edmonds Sep 13 '17 at 9:54

Yes, you can use SOFS, or Storage Spaces/Storage Spaces Direct. What do you mean by "a standard file server cluster"? Don't forget that the share must not go down when UPD are in use, and you must use a Windows Server-based share/cluster.


  • When you create a failover cluster, there are two roles, file server and scale out file server. You can add both roles independently a Nd they behave differently. Ensuring continuous access to the UPDs is why I thought I should use SOFS, but there doesn't seem to be any way to backup data on a CSVFS volume in a SOFS cluster – James Edmonds Sep 12 '17 at 20:03
  • "Yes, you can use SOFS, or Storage Spaces/Storage Spaces Direct." Well these are all very different technologies, and you can't use them interchangeably! SOFS deals with files, needs some shared block back end (where S2D plays just fine), Storage Spaces Direct need CSVFS bolt-on on top to expose some file mount points, while Storage Spaces is a local software RAID so has NOTHING to do with clustering unless you'll put some replication (Storage Replica? StarWind? IBM SVC?) on top. – BaronSamedi1958 Sep 13 '17 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.