This message was deleted.

I actually worked with a client using single file servers for VHDs one for profiles, one for odfc. Performance was very poor with FSLogix. Nothing was sized right. I sized the storage and implemented SOFS and it flew. I wrote a whitepaper for FSLogix on sizing odfc containers with regards to outlook caching and search indexing.

That was going to be my next question, guidelines for server sizing for these new VMs handling SOFS. The client you referenced could very well be us, since that's basically how we're currently configured. 2 vCPU/6GB RAM file servers, both containers on the same share, etc.

Just search for FSLogix on my blog and you'll find a copy. Add an IOP or two if your doing more. The client that had all the issues..... There was some stuff on there too.

I've definitely read your blog in the past, this looks familiar. And yeah, I agree. The 'official' FSLogix storage recommendations mention 8-16 vCPU and 32-64GB RAM per FS, and at this point, I see no reason to argue with it. I think I'll have a harder time getting the group that handles our file servers to use SOFS.

SOFS isn't really necessary. If it's the same backend storage anyway then you're better off with a cluster and continuous availability. It'll allow you to utilise cluster aware patching without having any downtime for your users. Ease of maintenance and (as long as the storage is okay) performance should be fine.

Yeah, I just saw David mention it in the channel. Sounds like clustering with CA and separate shares on the same storage is the way to go.

Ha ha, never assume. It's hard to troubleshoot with VHDX files as the attach will take a while if it's UPD. Reviewing the FSLogix logs and timestamps should do the job for that though.

UPD? Either I'm blanking on that acronym, or it's a new one to me

That's it chap.

I certainly appreciate the guidance, so thank you!

No problems.