Proper MSI Installer for VDI
The recent MSI installer isn't really what people are asking for. It doesn't actually install to program files. It just puts an installer in program files which then installs to the users app data. This doesn't work for me at all.
In a non-persistent VDI environment the application has to install on every login (unless I roam appdata/local which I don't want to do). This isn't the end of the world as it's fairly quick but the problem comes when you also use Yammer. Yammer has the same weird install method and when both teams and yammer try to install they cause a process conflict so only one of them actually installs.
Can we have some proper deployment methods like the rest of Office please? Or at the very least a way of deploying Teams and Yammer together?
Rick
shared this idea
This has been completed. For more information please visit https://docs.microsoft.com/microsoftteams/teams-for-vdi.
44 comments
Comments are closed-
Karl Wester-Ebbinghaus @tweet_alqamar
commented
is anyone reading the comments before posting new myths?
you can control autorun via registry and Team CAN be installed on RDS or Citrix. See below. -
Alex
commented
Microsoft Teams in a virtualized environment supports chat and collaboration. And with the Windows Virtual Desktop, Citrix, and VMware platforms, calling and meeting functionality is also supported.
https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi
https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi#platforms-certified-for-teams -
Anonymous
commented
We have Teams running on several RDS 2016 servers with FsLogix profiles. Microsoft does not support this setup but it would be really helpful that they did.
I am not able to stop Teams from autolaunching on logon and I cannot find a way to exclude logs.txt file from copying over to the user profile. I am watching how much this logs file will grow... hopefully will not cause space issues with profiles.
Microsoft please provide support to Teams on RDS
-
Karl Wester-Ebbinghaus @tweet_alqamar
commented
Microsoft does not aim for RDS or similar but WVD. However the trick is easy.
Create a GPO with Computer based GPP Registry object to add this
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICAhttps://www.masterpackager.com/blog/mst-to-install-microsoft-teams-msi-vdi-to-regular-windows-10
I hope Microsoft will not prevent this workaround in future.
-
craig
commented
Same problem here across our RDS servers
-
Jasper
commented
Still not solved MS. I don't want applications installed in a local user profile on my RDS environment. I want it to install in Program Files, and personal settings in the roaming appdata folder for the user.
The ALLUSERS=1 setting does not help. It just puts the installer in the Program Files folder and then installs it for a user on logon. Why why why!
The ALLUSER=1 setting only works in a true VDI environment, not in a shared RDS environment, it detects that's it not a VDI and then aborts the installation.
Useless for RDS.Please MS fix this.
-
Surya
commented
Teams is not working as expected in RDS / Citrix environment like Skype for business. It is eating server resources like anything - Memory / CPU /Disk space. Also it is hanging in most of the user sessions. We need a better / faster solution for this.
-
Mike
commented
We use RDS with UPDs. We were able to get Teams working to a point by storing it in the UPD but some basic functionality like scheduling a meeting in Outlook is not possible. We have had to tell our users that application functionality will be limited until Microsoft releases a fix or supports Teams in an RDS environment. One other issue we have found is that the the time zone doesn't reflect the client, it reflects the time zone the server is in even though the session hosts reflects the user's time zone correctly.
-
Lloyd
commented
This request is very critical as we cannot have the application installed on each users AppData which sits in the roaming profile. Imagine the logon delay for the users every morning and the storage requirements. We use Microsoft RDS.
Please expedite this . Surprised why Microsoft is unable to get this sorted.
-
Bruce S
commented
the upgrade steps for VDI do not work. This msi command line always fails with a 1603 error. Why isn't there a simpler way to update this? https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi#install-teams-on-vdi and one of the uninstall choices is 'powershell' script - which there is none listed so thanks for nothing.
Wouldn't it be great if you guys used Windows update and WSUS like a normal Microsoft product?
-
Anonymous
commented
Download the .msi file for teams from microsoft and install with the following 1liner:
msiexec /i [pathtomsi] ALLUSERS=1
This will install to the programfiles directory
-
Mohammed Rauf
commented
There has been no updates or suggestions from Microsoft, but we have tested using MS FSLogix - Office 365 container over network share and have seen good results. You still need to provide additonal storage but the logon speed has improved. We have currently enabled RDS desktop with FSLogix for UAT and are awaiting results.
This still is a workaround (expected Teams to install in program files) but Microsoft should proactively suggest this for remote desktop users.
-
Rick
commented
Have now found that deployment of yammer and teams also fails when using Intune. Pretty silly really given it's meant to be the modern tool for this sort of thing. Same issue as previously mentioned, if they both try to install together it causes a conflict. If you do one at a time it works fine.
Using the MSI with all user flag also fails because it has some registry check in it that causes installation to fail if it doesn't detect the machine is a virtual desktop. So, I can't deploy to my laptops using intune.
-
kav
commented
Still working on it ?
we have the same issue, deploying both the apps to users. Only one installs and the other fails. -
Anonymous
commented
A large section of our business runs on RDS so this means we can't roll out Teams effectively until the issue is addressed
-
Sascha Friedl
commented
I use Windows Server 2016 Terminalserver with Citrix VDA 7.15CU5 (with MCS provisioned) and installed the TEAMS.msi Machine Wide Installer with the Swith "alluser". So erverything works fine for the first start. When the User closes the TEAMS Application via the Taskbar (Quit TEAMS) and launch the Application Again then comes a white Screen. When the user then LogOff and Logon again it comes altough a white Screen. So i figured out, that when I delete in APPDATA/Roaming the settings.json file it works well. So i excluded this in our Roaming Profile Solution.
But then cames a additional white Screen topic: After some hours of using TEAMS in the Terminal Server session, ther comes altough the white Screen Problem.
Is there any Idea for the Problem in general?
-
Rick
commented
Not sure why MS hasn't bothered to update here but there is now a MSI that can be installed to the program files when run with a flag. I still find it weird as this should just be the default setup but it works none the less...
https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi
-
Mohammed Rauf
commented
This request is very critical as we cannot have the application installed on each users AppData which sits in the roaming profile. Imagine the logon delay for the users every morning and the storage requirements. We use Microsoft RDS.
We have stalled our teams roll-out for over two years due to this inability. Please expedite this . Surprised why Microsoft is unable to get this sorted.
Your recent release as below does not help at all.
https://microsoftteams.uservoice.com/forums/555103-public/suggestions/17380159-improve-install-options-install-for-all-users-an -
David
commented
You've been "working on it" since May 1, 2019, and this topic was created in July of 2018. Get with it. Our users don't install apps, period - not in %appdata% or anywhere else. And having 50-100 copies of an executable running around in a VDI environment is mind-numbingly stupid. Admit that the already-supplied .msi "solution" is garbage and FIX IT CORRECTLY!
-
Scott Regan
commented
Still working on it? Is there any update on this?