New Teams Update Issues

[KevHal]

Hi,

Just getting to grips with the new Teams in AVD.

Can see in the client that there is an update, select Update and Restart, it closes. Then it re-opens and shows that it still requires an update.

I then looked at the event log and can see that it has indeed errored, anyone come across this?

Thanks.

[#2]

@KevHal 

Can try fully uninstall?

https://support.microsoft.com/en-us/topic/fix-problems-that-block-programs-from-being-installed-or-r...

[#3]

Hi,
Thanks for this, I did indeed just re-install again, but had only just installed it for the first time the day before. I'm finding all sorts of issues with deploying this in AVD.
Have just done one now where its fine on the image using the bootstrapper install, sysprepped, deployed, the users then found the new teams icon greyed out and an error stating it needs re-installing. Not too mention the Outlook addin not always staying installed.
Things have got to improve.

[#4]

@Kidd_Ip Just to add what I said before. This seems to be the issue. So I install the new Teams using the bootstrapper on the image. All looks fine. I then Sysprep and deploy. This is all the user gets.

New Teams is greyed out:

When you click it you get the following error:

We have the latest FSlogix hotfix 3 installed. Even logged in with a local account outside of FSLogix, same issue. Patched to March.

If I were to deploy this to 30 session hosts I can't be logging into each one of them to manually fix. Also when it comes to redeploy again i'll be in the same boat.

Followed the instruction to the letter, including installing bootstrapper -p -o and using the msix file.

New Teams opens fine before Sysprep. Any ideas what could be wrong?

Thanks.

[#5]

I've raised this to Microsoft Support. Done it at several clients now where the New Teams is disabled/broken after sysprep.

[#6]

@KevHalThanks for posting this. Seeing the exact same issue. Have also opened a case but let us know if you hear anything.

[#7]

@KevHal 

Hello everyone,

we have experienced the identical behavior:

Here our test steps: 

1. Create Ref-VM based on Win 10 Ent Multisession 22H2 from the Azure store
2. Start, VM, Login as Local Admin, uninstall FSLogix version X
3. Reboot Ref-VM
4. Install FSLogix version 2.9.8784.63912
5. Set registry keys: 
   HKLM\SOFTWARE\Microsoft\Teams
   name: IsWVDEnvironment
   type: DWORD
   value: 1
   
   HKLM\SOFTWARE\Microsoft\Teams
   name: disableAutoUpdate
   type: DWORD
   value: 1
   
   
6. Install New MS Teams Version Teamsbootstrapper.exe -p -o c:\install\MSTeams-x64.msix
7. check MS Teams status with:    PS>Get-AppxPackage -Name msteams*

8. run Sysprep.exe /generalize /oobe /quiet /shutdown /mode:vm

9. capture the image -> Azure Compute Gallery

10. create Test-VM from new Gallery Image

11. login with local admin

12. check MS Teams status with:    PS>Get-AppxPackage -Name msteams*

Icon in the start menu -> greyed out...

Teams doesn't start......

Conclusion:

Once we change the sysprep command from:
Sysprep.exe /generalize /oobe /quiet /shutdown /mode:vm
to ...

Sysprep.exe /generalize /oobe /quiet /shutdown

the problem seems to be solved... but the provisioning process for new vm's needs more time

Question:

What is the exact funtion of the sysprep switch mode:vm?

Regards, Patrick

[#8]

For a Multi-Session Environment, are people disabling the update of Teams 2.1 by setting the registry key? I see that Teams 2.1 is pretty much updated on a daily bases at the moment.
If we leave it to self update, are we going to run into issues say one session host is on an older version compared to another one. Or are you just disabling Teams updates altogether by setting the registry key, what issues could that bring down the line.  What happens with the Teams Addin if we allow it to self update but per-user MSI is blocked (Which is best practice).
Just weighing up best practice options for multi-session environments.

[#9]

I'm currently facing the same issue, thank you for sharing this.

Currently in the process of troubleshooting this with Microsoft support.

[#10]

/mode:vm does something relating to drivers. So /mode:vm will skip drivers because its hypervisor so no drivers. that's why it takes longer without it. thank you though for posting this, i'm gonna sysprep without /modeVM and run with it. i of course waited till the last minute to test this before deploying my new image overnight tonight.

[#11]

@Patrick_Kunz 

I can confirm new teams works fine when omitting the /mode:vm. For here's MS explanation of /mode:VM: Sysprep Command-Line Options | Microsoft Learn

Does anyone have updates from their tickets with microsoft?

[#12]

I also confirmed this with Microsoft Support. I have collected logs and the support agent is currently reviewing these logs. I'll post an update when there's something new to report 🙂

[#13]

This issue is listed under the known issues here:
https://learn.microsoft.com/en-us/microsoftteams/new-teams-vdi-requirements-deploy#features-currentl...

New Teams fails to launch for users logging into non-persistent virtual desktops, or the app is not visible in the Start Menu.
Admins don't experience this issue - after installing new Teams on the golden image they can launch it successfully.
After sealing the golden image and deploying it at scale (with provisioning tools like Citrix MCS/PVS or VMware Instant-Clones), users log into the virtual machines and click on the new Teams icon, but aren't able to launch the app. The issue is caused by a failed registration of the MSIX package at the user level with different profile management software (FSLogix, Citrix CPM, Ivanti UEM, and so on), even though the staging of the package was successful (the OS stored the package’s contents on the disk in the %ProgramFiles%\WindowsApps directory). This issue can be confirmed by running Get-AppxPackage -name MsTeams for the affected users. Running this code will return an empty output.

NOTE
Microsoft is working on a solution and plan to remove these limitations soon.

[#14]

FSLOGIX 2210 hotfix4 coming soon. Check out the long list of teams fixes.

https://techcommunity.microsoft.com/t5/fslogix-blog/announcing-release-date-for-fslogix-2210-hotfix-...

New Teams Changes
Update: Added functionality to repair missing Teams AppX folders in ODFC containers during the container creation process. (new container or container reset).
Update: Added a workaround where in some cases new Teams would fail to on-demand register during sign-in.
Update: Added roaming support for the new Teams meeting add-in when using the ODFC container.
Fix: Resolved an issue where FSLogix was unable to query provisioned AppX packages on Windows Server 2019.
Fix: Modified the sign-out process to solely erase the contents of "non-roamable" folders located in %LocalAppData%\Packages\* while preserving the parent folders. (all packages).
Fix: Resolved an issue where name cache entries in FltMgr (Filter Manager) would become polluted with non-normalized names.
Fix: Resolved an issue where New Teams may not have registered correctly when used with ODFC.
Fix: Resolved an issue where New Teams would fail to start, or the application would crash.

[#15]

@KevHal 

After a lot of troubleshooting with Microsoft Support and Engineering teams, the issue has been solved! I was told that it had something to do with a known bug in sysprep when using the /mode:vm switch causing issues with preregistering Teams.

I'm not sure if the bug itself has been fixed, but for Teams the issue has been resolved after installing the June preview update (KB5039299)

[#16]

@KevHal 

Please install KB5039299 for Windows 10 to fix this issue.

https://www.catalog.update.microsoft.com/Search.aspx?q=KB5039299