This message was deleted.

Yeah, it's been a MAJOR pain for the last 4 months for us. Our profile size exploded, user logon times became ridiculous, our intranet broke. It's been a mess. I wish you the best, and definitely am available if you have any questions (specifically, what NOT to do!) 😃

I would be curious to hear about those 'not to do' items. And any lessons learned or recommended settings you could pass along.

I've always had chrome in my gold image, IE is just a disaster, firefox is pretty nice, but seems chrome is the standard now, my biggest complaint with chrome at the moment is this folder saving thousands of file per week per user, there's no GPO to limit it or anything. it doesnt really affect logons or anything as i redirect the entire profile via UPM to the server - \AppData\Roaming\Google\Chrome\User Data\Default\Code Cache\js

enter @Aaron Parker pruning scripts here 🙂

Personally, I want to go the redirections.xml route with Chrome as opposed to pruning, if at all possible. We already limit what can be done in Chrome on our physical desktops (no autofill, no creds, etc.), so I don't think I'd be losing anything.

Yeah they work, I added those ones in - make sure you do the same for incoming chrome based edge etc (can't recall if we added them to the list or not)

@Tim Riegler: I'm definitely open to some tips on what not to do.

i took on the new edge months ago - rock solid, never looked back 🙂

I dunno, upgrading to the latest release within one month is pretty brave these days...

I meant the brave browser 🤪

Never heard of it.

Let me preface this by saying that we are currently on UPM, and moving to FSL. Everything below is to do with UPM. First thing - don't mess with roaming data / local cache locations. For some reason, we put ours in AppData/Local <- really really stupid decision. Made everything WAY more complicated than it should have been. Second - Get your exclusions correct. Our login times went from ~14s to ~35s, on average, across 1000 users. Definitely want to include the correct locations based on Dennis Span and @Matthias Schlimm's blogs. Code Cache is a huge one. This one bit us due to #1 above. Be careful with Matthias' blog - he redirects his Chrome to AppData\Local, so change all your paths accordingly. Third - Triple check that you are either ignoring or deleting excluded files / folders (not synchronizing!) Fourth - Set your local cache to something minimal and decent. In the GPO, it's configured in bytes, which is stupid. We have ours set at 100 MB, and that seems to work well. It shouldn't be cached into UPM on logoff, so this just affects PVS write cache. Fifth - As mentioned above, we are moving from UPM to FSL. One of the requirements is that users maintain their bookmarks. We are not migrating profiles, it's a clean cut from 2008 R2 to 2016. It is possible to script the saving of the bookmarks to a network share, then copy them into the user profile on login. This is working well for us. Again - the thing we struggled with was #1 above. I'm sure there's more around our specific config for Legacy Browser, plugins, etc., and this is all I can think of for now.

...?

Yeah - hit <enter> instead of <shift+enter> to start a new line 😑

😆 Thank you!

Figured I'd leave you on a cliffhanger for the weekend! 🤣

Sounds like you don't have Chrome gpo config'd to setupa profile.pb for the user with all of their stuff huh?

We do! The problem was that didn't bring over everything we wanted. We are grabbing that and actual bookmarks files from current environment to copy in the new FSL.

im confused, if you copy over the profile.pb from upm to fsl all of their bookmarks, passwords, etc, etc are in that file

We finally have a handle on it, just in time to move to FSL, of course.

We have no intention of using roaming stuff in Chrome, and honestly, the only thing we do want to save is the bookmarks file. So long as I can carry that in the profile, we should be good.

We tried that, and could not get everything to come over like we wanted. There were all sorts of oddities. This could definitely just be our environment, though, and might be worth a second look 😃

I'm not sold on FSL yet, my login times went up 4x and I still have this weird printer issue. They've finally agreed to a call as they can't see anything from all the logs I've sent. Back and forth for almost 3 weeks now.

ouch. I remember talking with you about that. We aren't having any problems with ours, so far. Only about 45 people testing it though. Most of problems stem from 2016, honestly. Our login times went down (once we used the smaller exclusions file from Aaron). The larger one caused our times to increase to over a minute.

I was having logons of 90 secs with empty profiles on subsequent logons after creation, i can understand the first time is slow, ok fine, but after 2 weeks and you're still at 90s with nothing shown in their logs to prove this, sounds sketchy to me

@Tim Riegler: Whose redirections.xml file are you using for Chrome? I can't find a link to Matthias's, but Aaron's doesn't redirect anything in AppData\Local.

My fault Nick - getting my streams crossed this morning. For UPM, we used Dennis and Matthias' blogs (Matthias' is here: https://eucweb.com/blog/1397). For FSL, we are using Aaron's scaled down version. His first (longer) version caused the login delays, and it's not specific to Chrome...I was just referencing it regarding login times.

I wrote a blog about this. We change the Chrome default user settings and cache and then exclude this stuff in the redirection.xml. Works like a charm in several production environments for months now. Read my blog post: https://www.sul.de/2019/04/05/fslogix-in-a-citrix-provisioning-environment/

@Dennis: So you're basically using GPO to change the user data directory from AppData\Local\Google\Chrome\User Data to AppData\Roaming\Google\Chrome\User Data? I see the cache directory being set, too, but it looks like it's in AppData\Local by default and in your policy.

@Dennis What are your login times for PVS when redirecting the Cloud Cache to local write cache disk? What does the disk IO locally look like? Are you hosting the write cache disk on flash? Are you doing profile and Outlook data in the VHDX, or just profile?

@Tim Riegler Login times are about 18-22 sec. Disk IO is low, there are about 15 users on each XenApp server. Write cache is on local storage (XenServer) with fast SSD drives. Cache disk size for each XenApp is 80 GB. Just profile data, no Office profile disks.

I'm going to run with that config to see how things work out. With us really preventing much of any customization or data saving, it might work out quite well.

Please report you experiences!

No worries, I certainly will. And if your redirections break something, I'll let you know that I'm shaking my fist at my monitor. 😉

😯 😂

Initial testing is going well. Using your Google-specific redirections for FSLogix, and the modified Google paths via GPO, my favorites and settings (browser size namely) are being saved nicely.

👍🏻

Nick - what's your login time with new settings?

I didn't compare that, but I'll do so today.