This message was deleted.

Thanks Leee. I really like the idea of disaggregating the name of the share from the underlying storage name, that way if I want to upgrade / migrate my underlying storage / share / cluster and the naming changes, I don't have to modify my clients (they are still pointed to the DFS-N).

I would posit that with a MSFOC you are also abstracting the name of the 'file server' from everything else too. The name of the 'pretend file server' is configured on the cluster role, you can move that from the cluster role, to a different cluster role, or to a different cluster, or to a stand-alone server, or to whatever. You can migrate your storage behind the cluster, you can replace cluster nodes with completely different machines or upgraded OS etc.. Horses for courses i guess. Both kind of achieve the same goal. Maybe DFS-N is less hassle in the long run and at larger scale.

Or maybe it's just "the way I've always done it" and I need to learn a new way! simple smile

Same here! 😊

Also what if you don't want to use MSFOC / SOFS / CAFS in the future - if DFS-N was used now, later it could front end a CIFS/SMB share on a storage array

Now there's a thought...

With DFS-N in front, if one of the DNS namespace servers fails over I know there's a blip in 2012 R2 (maybe still in 2016/2019 not sure) - especially if the failover occurs during a user logon with UPM I've seen it cause long delays or hang the UPM logon forever. Being that FSLogix will retry hopefully the DFS-N failover won't cause problems

I'd personally go with a cluster and continuous availability. It's very reliable and pretty simple to maintain. As David stated, it's also flexible in the long run and can move with OS upgrades etc..... DFS-N doesn't really give you more options but.... The main consideration is how the storage is served from the storage layer, SMB share, iSCSI, NFS etc... and then if each option has resilience through the stack.

Thanks @Leee Jeffries. Quick question - CA on MSFOC requires shared disk backend between all nodes, correct? And that is where SoFS is different - it is non-shared backend? If MSFOC requires shared disk(s), how do you handle that in a VM environment? iSCSI in the guest? Or RDMs? Something else?

Sure? Depends on your hypervisor.

If on vSphere check this for support statement. Gotchas are 'cluster-in-a-box' vs 'cluster-across-boxes', vRDM vs pRDM. We use guest-based ISCSI, keeps it simple but pros/cons. https://kb.vmware.com/s/article/2147661

Snapshots are the main gotcha which then potentially impacts backup methods.