Teams Windows client greatly increases roaming profile size (Appdata\Roaming\Microsoft\Teams)
On Windows, Teams is available as an end user self-install app. The app installs to AppData\Local, so not part of the roaming profile. However, it stores LOTS of content in AppData\Roaming\Microsoft\Teams.
Our organisation uses roaming profiles and profile size policy; users are beginning to exceed a [very generous!] limit, and Teams is a big cause of this.
Thank you for your feedback! This is our on backlog, we will share an update as soon as one is available.
Gabriel Bégin commented
BEHAVIOR NEEDS TO CHANGE
- Install in program files
- User data in the local profile
Stop installing it like a malware
Please Microsoft - you cant be promoting Teams on WVD and do this to clients with 20,000 total users..
error de teams
@Richard Goodwin: you can safely exclude the directory in Citrix UPM. Have a look at the following
Obviously the teams clients was designed by people that normally don't work in enterprise environments. This "feature" is only one of the many deficiencies that the clients has: Installation in the local user profile, storing cache data in the roaming part of the user profile, limited centralized management, etc. I hope that the client rewrite will fix those issues...
What about limiting the age of the data to be stored / cached as it can be done via GPO for Outlook using Exchange online?
Richard Goodwin commented
Teams is single-handedly killing our Citrix farm - my own roaming profile now has 1.6Gb in the \Microsoft\Teams\Service Worker\CacheStorage directory, which is utterly ridiculous given the fact that I have only ever sent 5 messages and participated in one meeting!!
Give us a setting to get this OUT OF ROAMING PROFILES NOW!!!
Jeff Bryant commented
Anyone using FSLogix user profile containers stored on a premium Azure file share is going pay an extra $1 (for the 4GB profile increase) for every user who logs into a WVD session desktop to use the Teams desktop client. If a customer has 1000 users logging into WVD, then that's $12K a year the customer has to pay for no reason at all! True, you can exclude the CacheStorage directory from the FSLogix user profile with redirections.xml, but the correct long term solution is to fix Teams. Customers should not have to implement a workaround in one product to save them money in Azure cause by another product!
Bill Moller commented
+1... this is ridiculous. Profile usage has skyrocketed.
Jamie Sandell commented
We redirect the appdata (roaming), this decreases performance massively when using Teams. We should be able to specify the cache folder to be the local appdata folder. Also the program should be installed to Program Files / (x86) not the user's profile.
Always noticed that programs that somehow do not need local admin/installation credentials dump everything in the roaming profile. Noticed this with dropbox and spotify to. I bet they did it this way so they could push teams to organisation without admins being able to stop them easily.
Anyway quick fix to solve the problems is to just exclude this directory. In the "Exclude directories in roaming profile" under system \ user profiles add "AppData\Roaming\Microsoft\Teams"
Please allow the location of the cache to be changed. We use VM's and our whole network has suddenly slowed down as 20+ teams data is written into appdata that is stored on just one drive on our network. We are now having to provision a completely new high speed array just to handle this data / traffic - just for appdata. very poor design.
I can not understand how/why the idea can come into a dev's mind to allow/permit installation into a user folder. I have seen other programs installing into AppData when the user cannot install into ProgramFiles, which is definitely another issue for admins... Here, it is even more not understandable as it is clearly a program for Pro and not Home, from Microsoft for Microsoft systems.
What about OneDrive?
The program loads a lot of data on hard disks, into memory, processes, CPU (per user, no optimization): my VM needs to be extended, my backup takes 100% more time to complete (and my backup windows cannot handle such increase).
Workarounds might be pain in the near future.
I might be mute when voting to the UserVoice, as you, because I found a lot of stream of people complaining since a while, a nothing. But when they have a lot more users, they push commercials on TV saying they have the best solution for us!
PLEASE REMOVE the storage from this place!. WHY does this scripts kids do not learn, the idea behind roaming profiles!!
That is a very important point. Small machines with SSD like a Surface are running out of Memory on disk.
George Murphy commented
Teams cache has single highhandedly added over 46 GB to our users roaming profiles. Why would Microsoft design a software package to keep over 2 GB of cache in the AppData\Roaming instead of the AppData\Local portion of the profile? Every single one of our users profiles now takes forever to load and we constantly have to delete this cache. Very poor design.
We use roaming profile, user are non admins.
We cannot backup user data because of Teams non-standard behaviour (data in userprofile, cache in user profile, etc ...
PLEASE MICROSOFT ENGINEERS, change Teams behaviour :
- Put it in "program files"
- store its data into local (or %TEMP%)
- store its settings in HKCU or roaming profiles
- Upgrade it via Microsoft Update
It's a nightmare for sysadmin!
Another workaround for roaming simply but not bad I hope is to exclude
Deploy the registry key with GPO like this one:
AppData\Local;AppData\LocalLow;$Recycle.Bin;OneDrive;Work Folders;AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage
You can also exclude the complete folder AppData\Roaming\Microsoft\Teams
but I see the CacheStorage is the most unlikely folder?
A day after the deployment you have to search on your profile server folder for "CacheStorage"
and delete all you find.
Another point is the VDI setup: https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi
we can install teams per machine but I'm not happy with this:
To update to the latest Teams version, start with the uninstall procedure followed by latest Teams version deployment.
To deploy the MSI with GPO is possible but uninstall the old one and deploy a new one on each update?
Lionel Worman commented
After some testing this is the "Solution", for my environment, I came up with until Microsoft makes a better one:
1. Log into the server hosting the roaming profiles with an Administrator account
2. Create the following folder "C:\Temp\TeamsCache"
3. Start a Command prompt as Administrator
4. Delete the existing <RoamingProfile>\AppData\Microsoft\Teams folder
5. Run the following command
mklink /d "\\<UNCPathtoRoamingProfile>\AppData\Microsoft\Teams" "C:\Temp\TeamsCache"
mklink /d "\\homeserver\home\JBob\profile\AppData\Microsoft\Teams" "C:\temp\TeamsCache"
On the desktop system:
1. Create the folder "C:\Temp\TeamsCache"
2. Make sure the users have Modify access at least to c:\temp\TeamsCache
Setup the following policy for Desktop systems either at the system, or preferred at the domain
GPO -> DesktopPolicy -> Computer config -> Administrative templates -> System -> File System
Selectively allow the evaluation of a symbolic link, enable, and check all the options
or alternately at each system run the following two commands:
fsutil behavior set SymlinkEvaluation R2L:1
fsutil behavior set SymlinkEvaluation R2R:1
Now when a user with a roaming profile signs on to the desktop system, their <RoamingProfile>\AppData\Microsoft\Teams folder is redirected to the local "C:\temp\teamscache" folder on the local system.
This works in my testing,but if the C:\temp\teamscache folder is deleted, Teams will not startup.
Also the "Allow my organization to manage my device" pops-up each time Teams is started.
But at least the Cache has been moved out of the Roaming Profile AppData folder
This was just how I managed to get it working in my environment, your setup might be slightly different, but I hope this gives you an idea. Until Microsoft fixes this as part of the program.
[Deleted User] commented
2 years later and STILL NOTHING, and in the middle of a Pandemic, seriously? goes to prove that MicroJunk doesn't even listen to its users needs.