Install in Program Files directory
We simply can't fathom the idea that Microsoft allows for an Enterprise-level application like Teams to be installed on the user's AppData folder. As IT admins, we need the ability to install this in the Program Files directory. You recently released an MSI package, but that still copies the executable over to the user's %localappdata% directory. This is not secure!
Anonymous
shared this idea
13 comments
-
Mark Hardisty
commented
Concur with every opinion on this thread.
-
Anonymous
commented
The opening of Teams alone generates around 800 files in% appdata%. We use roaming profiles with folder redirection to a NAS. We have been using this type of configuration for 15 years and it has never given us problems except with the use of Teams. We have had to choose Teams on the Web due to the impossibility of opening the desktop version without errors. After several open cases and so much log that it generates and is useless. The only solution I have found has been to install FSLogix to contain% appdata% on the NAS. Please optimize and redesign.
Thank you.
-
Simon Jackson
commented
Patching MS Office properly deploys the 'machine wide installer'.
Group Policy Software restriction policy prevents MSI files installing under %userprofile% - this includes %appdata% and %localappdata...
So then randomly microsoft installer extracts to %programdata%\%Username%\ and installs Teams there instead...WHY ??? Why not the good old %ProgramFiles% folder like every other MS Office Product?
It's a nightmare trying to script cleaning up old user installs, patching exes, keeping HDDs nice and clean etc.
The install command for teams installer has a switch for 'all users' but still installs in %programdata%\%username%... errr thats not right!
-
Christopher Holmes
commented
I can not wrap my head around this insanity. I just spent 12 hours trying to make my security product work with your product for this various reason.
Lets put this simply. Where do users get virus and spyware? One Guess... Right next to your install of Teams! So when a nefarious actor targets your software and all the users profiles, you are going to wish you had a better security posture.
Oh btw, I can not break security profile per cyber to install Teams. We have a process that blocks all .exe from running within the user profile... Including the craziness on how you update, then launch the product.
-
A Consultant left Alone
commented
Sorry for my english..
Apart that you are obviously a stupid team, but how can you pretend to have instructed people for more than 20y to use roaming, to redirect data, to keep profiles light as possible, bla bla bla... and now, you spread out a unbelivable abomination piece of software that, targeted to enterprise, is everithing except respectfull for all your own guidelines...Morons! it's time to work for enterprise not for your own lazyness!!!
-
C0rmang
commented
Another reason Teams should follow standards... https://social.technet.microsoft.com/Forums/en-US/1414d5a6-1ce8-4cf4-aaa5-a7d3172d5c36/microsoft-teams-excessive-bandwidth-usage-on-shared-computers?forum=msteams&prof=required
-
Jack
commented
Still ignoring this.
-
Chris
commented
This is the most stupid excuse for software I have seen in ages!
If you install it in program files using an MSI installer, that should be it, it shouldn't copy it to %appdata%!?
Our users have a 1GB quota for their redirected folders, which includes AppData. We can't give them Teams because it would mean that 350MB+ would go into their AppData, for every user! What are we supposed to do when we have 650 users all wasting 350MB on duplicate Teams installers!? -
Sylvester
commented
We also have the same problem. There is no way to control the application from company-wide policy perspective when installed in the AppData folder, so it is not secure and deviating from Microsoft best practices! The lack of installing it in a enterprise controlled folder is not helping the user adoption as on an IT level we already get tons of resistance (and with good reason) on deploying the application in the first place..
-
Anonymous
commented
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!
-
CAT-hs
commented
Frankly whoever at Microsoft thought installing software in the user's profile was a good idea should be fired and banned from using Windows for life.
I've seen the response from the feature team that it is not installed in Program Files to ensure users get the newest features and fixes quickly and ensure all users are getting the best experience possible from MS Teams, and that they feel that their updates and features are being released too quickly to provide a god experience if admin credentials are required to install and update. This is lazy, short-sighted, and unfriendly to (what seems to be) the primary audience for the Teams application (enterprise).
Many applications exist that are installed in the proper location (program files) and still automatically update themselves without additional administrator prompts, and there are many methods to do this. For example, you can publish updates as frequently as you want to Microsoft Store or Windows update (granted the later will still update most users weekly at best with default config). There are also options like the Google Chrome for enterprise MSI model with an updater installed and configured during the initial install so that admin rights are not needed after the first install.
This design choice is driving my company away from Office 365 and towards Slack. Yes, they are basing the decision to go to subscription model for office vs keeping stand alone install and internally managed servers heavily on the the collaboration tool they decide on, and they figure that if either tool will be difficult to control properly (compared to normal office apps) then they might as well NOT pay the huge user subscription fee.
-
Andrzej Demski
commented
This is the first time when someone used security as a level of insanity :)
Program files copied to program files folder solve the issue, but wont be supported by MS.
I am optimistic, there are worse ways to make fun of users. -
Aaron
commented
Security aside, access rules are created by management and IT admins for a reason and should not be undermined by the company that developed the access rules. Also, this has big ramifications for RDS rollouts. Every user who installs will have the same program placed in their profile. I am demoing and that's ~350MB in my profile. So, using that for a benchmark, for every 3 users who install the program, that's over a gig of completely redundant files.