Teams JavaScript Error

[MikeC3964]

Good morning,

Not sure if anyone’s run into this before, but here’s the situation. We installed the machine version of Teams on the reference image, and it works perfectly fine until we interduce (so far any AppStack), then Teams may or may not work. It’ll come up with a white screen. When I close and open the app, I get the following JavaScript error message(attached). Digging into the Teams logs, I found reference to the app.asar file, but when looking in the directory, I only found an “app.asar” folder (no file). When looking at a session with no AppStacks attached I see that there’s in fact an “app.asar” file. I tested deleting the “app.asar” folder and replacing it with the “app.asar” file and Teams opened without error!

Teams Logs

Sat Aug 08 2020 06:54:43 GMT-0400 (Eastern Daylight Time) <8496> -- event -- errorMessage: C:\Program Files (Microsoft\Teams\current\resources\electron.asar\renderer\init.js: line 177: Unable to load preload script: C:\Program Files (Microsoft\Teams\current\resources\app.asar\lib\renderer\preload.js, status: success, scenario: f71b3c52-842d-4257-86dc-fe40519ac0a1, scenarioName: desktop_web_console_error_log, name:

I then learned that if I log in without any AppStacks, and have Teams working fine then attach an AppStack immediately. Once I close Teams, I can see the file change attributes, become a folder with an updated timestamp, and Teams will fail to launch the next time I try, so I narrowed it down to something with AppVolumes.

In the AppVolume logs, I can see that something is triggering a Teams update, which I have a feeling is what is breaking the App, but right now, I don’t know what’s triggering it. Also, since this is the machine install, that directory is blank, so it’s no technically executing anything.

[2020-08-08 11:30:57.965 UTC] [svservice:P1728:T8552] RunKey: Failed to get file attributes "C:\Users\******\AppData\Local\Microsoft\Teams\Update.exe --processStart Teams.exe --process-start-args --system-initiated " – 3

We're on version 2.18.0.25 of AppVolumes, I'll be getting a ticket into VMware first thing Monday morning, and will update this post with whatever they give me. If anyone's come across this before, and has any information, that'll be great!

Thanks,

Mike

[vBritinUSA]

So trying to understand whats going on, you have Teams on base image and works okay if no AppStacks are attached to the pool. Once ANY Appstack is attached Teams doesn't work?

When you capture the Application(s) to create an AppStacks are you using a clean VM with no Apps installed, no Teams, no Horizon Agent etc?

[VDINinja311]

MikeC3964​

Do you use Writable Volumes?

We had a single instance of this exact same error so far in our implementation of MS Teams. The writable was capturing something (we didn't look that far into it and I assume its what you are seeing with the newly modified directory) and deleting the writable was the fix for the user. We only use the writable for hosting .OST, so its not too big of a deal.

[MikeC3964]

Hi vBritinUSA​,

That is correct. The issue only occurs when I have an AppStack attached. We typically clone our reference image, and remove the agents then capture the application, which was advised to us by VMware.

Thanks,

Mike

[MikeC3964]

Hi VDINinja311​

Thanks for the information, we're not using writable AppStacks in our environment.

Thank you,
Mike

[vBritinUSA]

So you are not doing anything wrong with the capture process. Have you tried to exclude that path in the snapvol.cfg for that template before you do the capture? it make no sense but its just a sure way to exclude it.

[Ray_handels]

If teams is indeed installed in the GI and also on the package machine my guess is that some parts of Teams will be captured within the appstacks that you are creating.

I would suggest, just as a reference test, to remove Teams entirely from the package machine or maybe just make sure that there are no running services for teams. Also make sure the machine is in an OU without any policies.

You could also try and attach one of those appstacks to a VM without the Appvolumes agent and check to see if you can find that file in that appstack within the svroot folder. Could be during provisioning all appstacks are contaminated with something from Teams.

[MikeC3964]

Hi all,

I created a ticket with VMware and apparently it's a known bug with AppVolumes 2.18 and should be resolved in 4.1 and 2.18.6. I'll continue to update this post as I learn more,

Thanks,
Mike

[MikeC3964]

I haven't tested the update yet, but support mentioned 2.18.6 has our fix which is listed in the release notes. We later learned that this issue only affects Admins, so as a work around we adjusted the permissions on the C:\Program Files (Microsoft\Teams\current\resources\ with worked well for us.

Thanks,

Mike

Resolved Issues

• A Javascript error occurs and Microsoft Teams fails to start when this application is installed in the base image of a Windows Server 2019 machine and an AppStack is assigned to the machine. [2571462]

[robsisk1972]

Hi MikeC3964​,

I know that Vmware has already packaged this in a release but am curious how you modified permissions as a work around?   My users have Read & Execute at the path you referenced.   Did you give them full control?

C:\Program Files (Microsoft\Teams\current\resources\

[MikeC3964]

Hi robsisk1972​,

We noticed it was only affecting administrators, so we adjusted permissions for the administers group to only be read & execute (removed the modify rights) on that folder. Before we set that, we added the local admin account to have full control so we can correct the permissions after we upgrade

Thanks,

Mike