MikeC3964
Enthusiast
Enthusiast

Teams JavaScript Error

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

10 Replies
vBritinUSA
Hot Shot
Hot Shot

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?

Please mark helpful or correct if my answer resolved your issue.
0 Kudos
VDINinja311
Enthusiast
Enthusiast

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.

0 Kudos
MikeC3964
Enthusiast
Enthusiast

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

0 Kudos
MikeC3964
Enthusiast
Enthusiast

Hi VDINinja311

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

Thank you,
Mike

0 Kudos
vBritinUSA
Hot Shot
Hot Shot

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.

Please mark helpful or correct if my answer resolved your issue.
0 Kudos
Ray_handels
Virtuoso
Virtuoso

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.

0 Kudos
MikeC3964
Enthusiast
Enthusiast

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

0 Kudos
MikeC3964
Enthusiast
Enthusiast

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]
0 Kudos
robsisk1972
Enthusiast
Enthusiast

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\

0 Kudos
MikeC3964
Enthusiast
Enthusiast

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 Smiley Happy

Thanks,

Mike