I'm curious if anyone using UPM with the full containers has been using the feature to write the profile to multiple shares? I have a discussion about this coming up soon so I was curious for any real-world usage of the feature. Normally, I'd just use something to sync but this is a 24/7 operation with a fair amount of user accounts in play... and trying to segment the storage with a solution I helped come up with a long LONG time ago (AD attributes to determine a primary share location) would be difficult to implement here... especially with containers instead of files. So the theory is good enough but I've never done something like this with full containers. Anyone done it? How did it scale?

It worked great for us for about two thousand users, but we weren't doing containers, just file-based

Curious if you were using OST files and all that fun stuff as well? When I did a deployment like that we were still using a SMB share and pointing OSTs to it like newbs ;-)

No, we had the Outlook caches local to the machines and excluded from the profile. It was a trade-floor persistent RemotePC deployment and the two shares we were writing rudimentary copies of the profiles to were simply to allow us to get profiles back in case a new machine had to be provisioned. In that eventuality, the Office caches would simply recreate at first login.

ah - gotcha. New machine as in to replace the stolen ones if your experience matches mine in that scenario, lol.

Traders are psychopaths

The biggest issue with doing that is if you have a failure on one side and users logoff before its fixed then the next logon you get a full container synch which can take whole environment down. If your using a san based replication that wont happen but you also lose automatic failover.

You could use something like Resilio that supports profile containers, but it’s not cheap.

Cost saving is a big part of their motivation, using existing storage... but agreed. I am a little unclear on how how profile containers (vhdx) would need to resync all at once (I assume that's what you mean?) I thought this feature just wrote changes to multiple locations at logoff?

True as long as the container is attached on logout. But if it not then the container is resynced from the one that is whole. No matter how large. If that is 30 gb then 30 gb is synched.

What Rob said. Don't underestimate that impact regardless of the container tech used - different iterations of the same underlying problem. Way smarter these days I think to design HA for file services in each site, and let data replication tools handle the actual replication - too much hidden impact on outage scenarios in container deployments

...which was my original proposal, but since Citrix has this feature we wanted to explore. That's why I'm asking if anyone has actually done it.

Citrix should ideally put some staggered replication in case of failure. Check how many sync is going, define a threshold, if too high, do not sync. Saying that, the container replication happens at log off, right? So it's slightly staggered depending on the users habit.

No both containers sre written to at the same time. Fslogix has the same issue with cloud cache. Its just the way it works.

OK thanks Rob, maybe a feature request even if I get it, it's not trivial.

Works great, have a client using it with onedrive caches deployed to 2 shares.

It will depend on requirements if both shares are local its less of an issue or if containers are not very large could be fine. Just want to make sure everyone understands how it works

Also be mindful of what features are compatible with local caching along with the performance impact if you are looking at using that.

I stood up one last year that is currently scaling to approx 4k of users. Didn't note any huge log off penalties with two locations. We had to disable the VHD compact, as that was adding about 15-20 seconds to log off. You'd note the same if you ran disk compact / defrag via FSL scripts. I'll have a blog post on it soon, as there are some important event IDs you'll want to track to ensure that you're hitting the same filer on each logon. You've got 'access based performance' and 'configuration order' to select between your stores the related event IDs to ID which store is selected aren't properly documented. If you don't pay attention, you can have users hitting the wrong store, never happened for my customer, but important to note for your user docs/run books, i'll reply all when the blog post is done, or DM you @DJ Eshelman

Thought I'd chime in as well. Replicating profiles across datacenters is a big reason why we shy away from full profile containers. We're starting with Mirror Folder Acceleration since it's something we can control with exclusions. So far they run under 200 MB in size, and our third party replication product replicates them within a minute after logoff.

Good Convo here. Yeah we are using and working pretty good but it's nice as it is staggered just by nature of it at logoff for replication but mostly meant for intra Datacenter or Availability Zone replication whereas between datacenters separated by a bit of more latency/distance, other replication in place.. @richminichiello fyi

Yeah, we are not seeing the replication actually happen at logoff which is discouraging. I have been thinking about some kind of triggered external event or something from WEM or such to replicate differences between datacenters. These are fiber-linked so fortunately I don't have the usual constraints here... Or I just try harder to convince them to go to Liquidware's Profile Unity like I used to recommend like 10 years ago. This strategy for the most important stuff still seems solid combined with Containers or Profile Disk... the problem with a lot of folks is they want Citrix to cover everything, full stop (Let the eye rolling commence). But if the UPM replication is working for you, I'm very curious!