Forum Discussion
New Teams Update Issues
- Create Ref-VM based on Win 10 Ent Multisession 22H2 from the Azure store
- Start, VM, Login as Local Admin, uninstall FSLogix version X
- Reboot Ref-VM
- Install FSLogix version 2.9.8784.63912
- Set registry keys:
HKLM\SOFTWARE\Microsoft\Teams
name: IsWVDEnvironment
type: DWORD
value: 1
HKLM\SOFTWARE\Microsoft\Teams
name: disableAutoUpdate
type: DWORD
value: 1 - Install New MS Teams Version Teamsbootstrapper.exe -p -o c:\install\MSTeams-x64.msix
- 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
I can confirm new teams works fine when omitting the /mode:vm. For here's MS explanation of /mode:VM: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep-command-line-options?view=windows-11#modevm
Does anyone have updates from their tickets with microsoft?
- 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 🙂
- This issue is listed under the known issues here:
https://learn.microsoft.com/en-us/microsoftteams/new-teams-vdi-requirements-deploy#features-currently-not-available-and-known-issues-in-vdi-with-the-new-teams
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.
- /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.
- I'm currently facing the same issue, thank you for sharing this.
Currently in the process of troubleshooting this with Microsoft support. 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.
