Improve Install options - Install for all users and install location
I would like to be able to install for all users of a PC via and MSI, the current installer installs into the users Appdata which means each user has to install manually.
I would like to see a "proper" installer than loads it to Program Files for all users
Good news, this feature request has been completed.
You can find details on MSI installation instructions at: https://docs.microsoft.com/en-us/microsoftteams/msi-deployment
You can find details on SCCM instructions at: https://docs.microsoft.com/en-us/sccm/core/understand/introduction
Thank you all for the feedback and support.
181 commentsComments are closed
Patrick Gutbrod commented
Please install to Program Files to fix App Locker compatibility. I cannot believe we have to ask for this!
Another ICT Admin here requiring that this installer has the ability to be deployed to C:\Program Files. Completely unusable on our Education Network installing to appdata\local
Dan Hayward commented
@Suphatra Any update at all on this? We have many, many users on a DaaS/PaaS platform that could easily make use of teams but it doesn't work as it installs to appdata\local. All we need is an installer to c:\program files\ so that it's machine based, not profile based, preferably via MSI so that we can install via GPO or SCCM.
There are many reasons from the many comments to do this from VDI, RDS or Citrix farms to Applocker and more. This really needs some attention, ASAP.
Sounds like the install will still be to the user's profile. Is there any plan to allow for an install to program files. Our organization does not allow software installations in the user profile.
R H commented
Echoing the comments of others here. PLEASE allow us to install this to C:\Program Files\. Unusable until it works on RDS.
Agree with the other posts here, an MSI is ideal but not to "smartly install for new users", store the exe at a machine level (not in appdata for individual users). Also have the install work in shared environments such as Citrix and RDS. The current install method seems to be very enterprise unfriendly, which is Microsoft's core client base.
Lee Smith commented
Just to echo others, working on an MSI is great, but stop storing this in the user profile.
We don't want it to configure on each users log in, we want to be able to install it like any other piece of software where it is stored in Program Files and accessible instantly.
Matt Grimley commented
As voiced by others, "smartly install for new users upon first login" is not a workable solution. Please do not deploy this to users profile.
There is no justifyable reason to avoid a station install. Install via MSI to program files. It needs to be "ready to go" when students login to random computers accross the campus, not "ready to install".
Please talk to any single one of your education users. Any one of them. Any person in charge of a school network. You shouldn't be winging this. Teams has been around for too long now without a working deployment solution.
Appreciate the update, but it doesn't seem to address the problem at hand.
Warren/Microsoft: To clarify, having a MSI to deploy is one piece of the puzzle. The other challenge is that this software currently installs into each user's profile. This makes updating it harder, and also for organization's that use Application Whitelisting, it becomes harder to allow.
Regarding Application Whitelisting, some of the EXE/DLLs files are signed with no product of file name and therefore the only way to whitelist Microsoft Teams is to whitelist the entire Microsoft Publisher certificate, which then allows things like psexec and other Microsoft software that organizations may want the user to avoid running.
1. Offer the ability to install MS Teams into a single location like Program Files.
2. Or at a minimum, sign the EXE, MSI and DLL files to include a Microsoft Teams specific signature, i.e. add a Product name while signing it.
David Lee commented
Regarding the planned MSI installer, will this be an RDS supported install? We need an install for non-persistent shared desktops, so not in the user's AppData.
On a managed system, users have an expectation that the tools they need for their job are preinstalled. The inability to install the app to the system and thus available to all users is a critical flaw. If I wanted my users to go get the app, I would expect it to be available in the Microsoft Store allowing me to use the mechanics via the Business Store for assignment.
Evan Overby commented
We are a heavy VMWare shop, and deploy a VDI environment as well. In order to deploy an app we cannot have it in the appdata folder. We need to be able to use AppVolumes to push the apps out to virtual machines spun off a template. While the user can install manually, I've had issues when a user has folder redirection or a roaming profile enabled. The program essentially installs, but will not launch properly.
just wondering if you are aware of two other Microsoft products that have been around a little while, System Center Configuration Manager, and Intune?
also, have you heard of a thing called Remote Desktop Services, or Virtual Desktop Infrastructure (I appreciate the OneDrive team didn't seem to have heard of these either) where lots of people use the same system, so copying/installing 90+Mb file on every logon isn't so practical where dozens or more users may be using the same 'system'. Also, persistent or cleared down profiles for security and practicality (reduced bloat) reasons? all generally 'bread and butter' things since, say, the mid 90's?
But i can totally see how such things would be overlooked, because, obviously its such an obscure request or functionality.
From an admin point of view, it is critical to deploy applications to systems, not users, this is efficient, it is controlled, it allows escalation of install without compromising system security.
The 'local app data' approach is effectively utilising an exploit in windows security to allow application installation, running head first into this flat out not being viable in secure environments.
to directly answer your feedback request:
1. Do you want install privileges so that you can load the program for all users? - install for system, yes, i'm not sure this is actually what you mean by your question though.
2. Or do you want a central repository which all users can access and deploy programs? - SCCM/Intune deployed capability, why is this an 'OR' option? but again, control is key here, this can be advertised to users, but we arent talking dumping the installer on some shared central repository, maybe someone from the SCCM team can elaborate or do a workshop for the teams client development team to bring them up to speed?
3. Do you want the access given to specific users only for the installer to deploy programs? - if the above is done, this is native, if we arent circumventing security to install and run the app, then this is natively catered for in the OS
Andreas engkvist commented
+1. I want to be able to deploy teams with intune or sccm. It is not possible to integrate teams in an enterprise enviroment with the tools that are avaliable from microsoft, neighter online or onprem.
+1 to this comment. We need better mass deployment options (an MSI would be excellent), ability to install to machine instead of to user, and ability to deploy to roaming profiles instead of local ones.
What are the silent
command switches for teams?
Denis Markwell commented
Agree with other comments, needs to be a MSI installer and/or part of Office Click to Run
Daniel Streefkerk commented
Teams is a nightmare to get working securely with AppLocker.
Stuart Bailie commented
The last time that Suphatra responded to this ticket was back in July. Has there been any progress on this?
I think the answer that Suphatra was looking for was: Do this the same way as other major software packages. Provide an MSI for deployment via group policy to either per user or per computer, based on install options, so the application can be properly managed.
I just downloaded this today because of a client request and to find that it was an .exe with a PowerShell v4 hack to get this installed domain wide made me think this was Installer 1.0. To find that people have been having these issues since January makes me think that Microsoft isn't support this product any more. This entire approach goes counter to all things that Microsoft says you should do, voiced many times in this thread already.
Sylvain Delisle commented
Defenitely msi package for all users, (Would be nice for Remote Desktop servers)
Also the ability to communicate with none office365 members, as guests