https://worldofeuc.com logo
Join Slack
Powered by
<@UM04QUUSJ> Do we still need an exclusion file un...
# citrix-app-layering
p
@Rob Zylowski Do we still need an exclusion file under Uniservice\UserExclusions for Edge with the latest elm?
r
Is that wiht user layer
p
No, regular layers. Old advice was put edge (and therfore webview2) in the OS layer, and have the exclusion list so layers built on top would not clash. But now the elm does "magic" so is that advice valid still?
r
yea i dont think you need it but let me ask
p
seeing oddness in new layer versions, hence question. new layer version lists older version of edge and webview than OS layer has.
Hmm. Maybe i'm reading that article wrong since the latest update. Maybe i stop reading now at the end of the App Layering 2409 section. Instructions unclear.. 😀
r
i just asked ill let you know
👍 1
o
keeping an eye on this. Thanks. Bout ready to go deep down this road again and been a minute. @Brian Forst
p
While we wait for Rob, I did pull the old exclusion list from our env and it resolved an issue we were experiencing with Oracle Smartview (that requires EdgeWebView2) Would be real nice if we didn't have to recreate every layer from scratch each time Citrix make fundamental design decisions like this.
r
why do you need to recreate your layers?
No one answered me on the exclusions let me ask again but i dont think anyone is in this week
p
Because the old exclusion list caused the registry in the prior version of layers to have info for the wrong version of webview2 under HKLM\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\Clients\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}
And even though the platform / OS layer had the correct info, the app layers overrode it.
r
OK im not sure i understand why the new approach wouldn't work we are taking the newest version of webview2 and keeping that but maybe there was more in that registry than just the webview2 install.
k
Yeah, I fixed the layer (PowerBI Desktop) that had .93 in it and the ELM logs show that it has picked .115 as the newest version in my latest test image. I still seem to have layers with older WebView2 folders in them (like 139.x.x.x and 143.x.x.x). Wish there was an easy way to tell what layers these are in without having to go through them all (there are 29 layers in our biggest image).
r
Yea thats why we tried to fix it. If you create sn image with all the layers you can use the apprule compare to find which layers have webview2. And we will fix our bug
k
Thanks, I'll give the apprule compare thing a try.
p
I'm still fighting with this and i do not understand why. The documented description does not line up with reality.
@Rob Zylowski you have an internal case # i can link to with my support ticket?
r
No. Im sure they are working on it now that they know
p
Kinda wish i opened a ticket 2 months ago, but ok.
I raised this issue in December, in here. Figured Citrix knew about it since Rob is on the thread, and so waited. That was a huge mistake, so i opened a ticket last month, referencing this conversation. Time passes. I get email this week saying there is a plan to fix it, but nothing yet available. Meanwhile here is a workaround you just have to open all your layers and re-finalize them. (spoiler, it doesn't fix anything) Given we have to patch monthly for compliance and that webview2 is like a damn virus in how it infiltrates every layer, this is a huge pain in the a$$. I can't believe this change shipped as is, and it's infuriating how little traction this issue has got internally.
3 Views
Open in Slack
PreviousNext
Powered by