This message was deleted.

Let's define "large profiles" first so we can get better answers. I'm curious to find out details.

Mine's 100GB and works fine

That's a hefty one @James Rankin!

Stick to profile size James!

100GB? That's a lot of p... stuff.

Jim Moyle's is even bigger

Do y'all find the go-euc research valid on the FSlogix profile size issue?

From what I‘ve seen in my deployment, size doesn’t matter 😂

No problems with large profiles..... it's all about the iops.....

No problems with large profiles

Sub-20 for a W10 VDA? Now I have more questions...

I can top out about 6 seconds for a Win10 VDA

You should write a blog on your image process, because I’d kill for that kind of logon performance. We’re running 25-30 seconds on a heavily optimized image.

Custom default profile, strip everything out of the image, run all optimisations, asynchronous GPO processing, super fast storage, FSLogix, all should help

I’m doing all but the first one (possibly the second unless you’re doing more than uninstalling all Store apps), so I’d definitely be interested to hear what you’re doing with the default profile.

@Nick Panaccio Using Server 2016, 8vcpu 1 socket, 32gb ram, Nvidia M10-4a profile on hyperconverged platform. Director says the profile load time is usually about .4 sec of the logon.

There is no impact with large profiles using container technology. The whole pitch of FSLogix should not be fast profile load times (like for like storage backend, a finely tuned UPM profile will load faster), the pitch should be consistent profile speeds no matter what shite lands in a profile - abuse the crap out of it, you will pay in storage, but you shouldn't pay in load times

Yeah, compare logins with 19000 files in an eclipse workspace between Upm and FSLogix.......UPM straight up fails. Then try adding scanning software like Cisco AMP........

🤮

yup - throw 38,000 files in that same workspace in a container solution and you should see no difference in log on speeds. Consistency is king