This message was deleted.

Why would the container need to be reset?

Hi Mike

Hi @Aaron Parker Thinking that someone might want to reset the Office 365 Container or shrink it if an org insisted on a 1 or 2 year outlook cache and then needed to reduce it to say 6 months because of the total storage consumption (even though we would tend to recommend starting small at 3 months and growing from there when needed). Other reasons we're thinking of keeping the Office and Profile Containers separate are: 1. For different disks on a file server 2. Splitting containers between two or more file servers 3. Wanting to reset the Office COntainer to start over w/Outlook OST or OneDrive - both are caches of an online service whereas Profile data is not a cache Am I overthinking this? Also curious what everyone else is designing/implementing. Our use case is RDS 2016/2019 Profile Containers + Outlook OST + OneDrive for Business cache

All valid reasons here, I'd recommend you use a VHD shrink script though to help with reducing the size so they don't bloat. Outlook and OneDrive should self manage but.... if you VHD disk increases it wont automatically shrink hence the shrink script.

@Leee Jeffries Thank you for the info. I figured Profiles are going to be tougher to nail down an IOPS # for the reasons you mentioned and the variety of customer LOB apps. Trying to figure out a rough rule of thumb though to help our pre-sales engineers size accordingly. Yes some of those newer FSLogix VHD shrink scripts/tools are very useful. I will drop you an email.

No worries Mike, I may be unavailable after today until Tuesday but will get back to you, I always do.

Microsoft released this a while back, but the guidance seems very light https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d4a57f5b-0c24-4cb7-8efa-ea68b749a080/storage-recommendations-for-fslogix?forum=FSLogix

It's not bad advice, pretty reasonable considering all the variables.

Thank you - yeah from what I gathered from that MS guidance is they say 2 IOPS per Office 365 container vs. Leee's recommended 13. 🤔

I'd still go with the 13. I did split read and write out though right?

It was 44 from @Leee Jeffries for o365 and 12 for profile - sent a few cold shivers through storage admins

yes Leee you split out read and write, although I am sizing for Azure and Azure only provides a combined number https://azure.microsoft.com/en-us/pricing/details/managed-disks/

Cool. I used Azure too for those metrics but not managed disks. I used premium disks. It's a shame they don't split it. Seems a little silly. Reads are cheap, writes are expensive.

Ahh that makes more sense on why you split out the reads and writes

Mike: I've got a production environment with about 750 concurrent users, and my profile container IOPS peak at about 35,000, while O365 (separate server) peak at about 44,000. I can work to break this down by read / write a bit more later.

Man @Tim Riegler that's pretty high! Much higher than I got in load testing, that was only for Outlook caching and it does depend on retention and other usage also. I'd still not expect that high though. Would love to hear more about your use case with regards to apps and whats happening there.

Yeah, that was our fear with moving from UPM to FSL. My gut feeling is that it is Chrome. When I get some breathing space I'll take a look.

Should be able to take a lot of the chrome nastiness out of the container (redirections) and transfer that IO back to the local machine - keen to see how you go on this - sizing is a dark art

@Tim Riegler thank you for sharing this info, it helps a lot! I am planning on Azure managed disks so the read/write breakout is not required for my use case - although it would still be interesting to see what you find in your environment for read/write.

@James Kindon completely agree! We will need to do that sooner rather than later. @Mike Driest My apologies for not getting back earlier - been in Sev1 mode all day. Our ODFC server took a dump, and took the Citrix environment down with it.

@James Kindon if sizing is a dark art we are going to hell 😂

Yes. Moving to multiple. Think we hit a known (to the general, not to us) bug with VMware ESXi 6.5 and VMFS 6 data corruption with defrag in a Windows VM. Yay us!

Ouch! Very unlucky. Failover cluster and continuous availability for the win.

It's on our plate for this weekend. Any tips / tricks? Running it on VMs, so that should be fun...

That's all good. Primary consideration is backup IMO. VMWare will require raw device mappings so no hypervisor snapshot based backup. You can use software iSCSI at VM level but it's the same story. Follow best practice for clustering. Split out your cluster Comms to a private network. You'll be fine. My recommendation for backup would be to use a block based file copy tool to copy to a backup location. Requires for storage but I think it's worth it for the resilience.