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?
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?
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.
Still working on it ?
we have the same issue, deploying both the apps to users. Only one installs and the other fails.
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?
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...
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?
Long time Edu Admin, and cannot believe this has not been sorted sooner. The first uservoice asking for this was force close way too early. Onedrive has now finally gone /allusers but is still putting configuration in appdata\local which does not work with non-persistent cached profiles.
Please think of the admin installs as well as the consumer ones, we may be fewer in number, but we spend more with MS, and have vastly higher install rates.
Joe Robinson commented
As an administrator, it frustrates me that Microsoft standardizes the installation process for windows, then goes rogue with their own installers. A proper installation would not only benefit VDI, but also companies that follow Microsoft's own security advice...
Who in their right mind lets any random user run an executable out of their profile, regardless of how it got there!
Tom Stack commented
The bigger issue I have is if the stupid user account based install gets borked its much more difficult to fix since you cant really uninstall/reinstall Give us a standard install to program files installer thanks.
Application in profiles is ******* non presisent vdi machine. Please make per machine teams install
Obviously this is one of the reasons why you bought FSLogix, but it doesn't mean you shouldn't fix this hideous deployment method for teams.
Johan Lysén commented
Why not As part of Office ?
Chris Smith commented
Will this be addressed with Teams being deployed alongside the Office 365 ProPlus package?
Just Do it. Ridiculous that you have closed the first user voice and implemented such a ****** solution.
Adam Fowler commented
The previous user voice being closed is definitely wrong - we want an end result of the program being in Program Files, not the user's profile. OneDrive for Business is finally moving towards this way, and Teams needs to be there too.
There's even gaps where we can't deploy a firewall rule, and Teams will alert on this https://docs.microsoft.com/en-us/microsoftteams/get-clients
current (4.4.2019 x64) MSi installe is a joke. I just copies the same user based executable to program files and sets windows to autolaunch it for every user - still installing in user profile space. Not wort time to experiment with it.
Whats wrong with You?
It is still not usable in enterprise and in Terminal and not in roaming profile .
Until we have this, we will not deploy teams and hang on to "legacy" Skype for as long as possible (should apply to OS X too). We have 8,500 devices. 4500 of these are shared by 17,000 users who get a fresh profile every time they login! There needs to be a device based installation!
Ideally it installs to C:\Program Files\Microsoft Teams and installs an updater service and keeps its user-specific stuff in %appdata% like the rest of windows.
Windows Defender and Office O365 seem to have no trouble at all updating themselves and interacting with Users or other non-admin accounts.
As the previous MSI uservoice is closed without addressing the main feature request (per machine basis installer) I support continuing in this uservoice.