I've managed to get Firefox 55.x working, but it only wants to run on a virtual desktop. It crashes on physical PCs. Basically I gave up on it and advised to kick Firefox from portfolio and concentrate on Chrome. Also because VMware's statement that they'll only support up to 50.x effectively makes it a dead end. At least Chrome somewhat works and if it doesn't I can always bug VMware.
I also received a patched version of Thinapp which doesn't require ExternalDLLs=ucrtbase.dll, but it doesn't really solve much problems otherwise.
All in all I'm less than impressed with all of this and I'm investigating ways to remove Thinapp from the equation altogether.
What network and network location message? I don't have one. I run it as CommandLine=%ProgramFilesDir%\Google\Chrome\Application\chrome.exe --no-sandbox --test-type with the User Data Directory stuck on a network drive through GPO...
the --no-sandbox option causes a message on the right side of the screen (Warning: your Chrome settings are being saved on an network drive. This can cause crashes and data loss) as well. this message only appears once (when the sandbox is being saved). see the attachment-jpg.
profiles are on an a DFS redirected folder on the Homedir.
btw: thinapp rules!! way way better performance, more possibilities, etcetera than appv for example. only the Firefox thinapps suck.
chrome.jpg 236.3 K
Weird. I've seen the message before, but it doesn't come up anymore even after nuking the profile. I don't know what I did to get rid of it, to be honest. Profile gets redirected to a network drive here too, and I don't even save the sandbox (sandboxpath is %TEMP% and gets removed on startup and exit). There's no need for it. Needs investigating
VMware is whizzing by soon to tell us their vision on application delivery and hopefully something about the future of Thinapp. A roadmap would be nice. I know the current 5.2.2 is supported until somewhere in 2019, but we design and deploy our desktop environment with a 5 year horizon (haha, pun). Application delivery is part of the desktop concept, so I need something for the next 5 years or so.
So I googled a bit and found 84045 - Investigate profile/cache on a network hosted location - chromium - Monorail (hilarious thread to read through. BTW, it pretty much sums up what we as application packagers and enterprise admins get to deal with on a daily basis):
"Please do bare in mind that running concurrent browser sessions of different machines using the same profile is not supported and will inevitably lead to a crash. This is what the last open issue here will solve - prevent running concurrent sessions.
Also network issues can lead to data loss or corruption and therefore Chrome will warn you if you are running in such a configuration, but you can prevent it from showing this warning by using the --no-network-profile-warning flag."
It's old, but I've seen references to it in 2016 too. I haven't checked the current source, but it's worth a try.
[edit3]I knew there was a reason for using it, but --test-type nukes the --no-sandbox message. I haven't seen the network profile message in my testing, so it looks like there's something in my GPO which prevents that one from showing up. Might also be the drive letter I use as opposed to an UNC path. Maybe I'll go check the source code to see what triggers it. Either way, my current commandline:
CommandLine=%ProgramFilesDir%\Google\Chrome\Application\chrome.exe --no-sandbox --test-type --no-network-profile-warning --disk-cache-dir=%TEMP%\Google\Chrome
I also tuned the package a bit more and it now comes in at ~250MB (uncompressed).