Should AppData be Redirected or Left in the User Profile?
This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles.
Redirecting AppData from the user profile to a folder on the network may significantly improve logon speed. Is enabling AppData redirection a no-brainer, then? Not really, because it often comes at a price: performance.
Aaron Parker brought this topic to my attention when he tweeted: “I really wish ppl would stop redirecting AppData. It’s bad news”. As he added later, he was referring to performance.
Folder redirection certainly has its pros and cons. In order to decide if redirection is good for you, you need to evaluate each of them. Here is what I came up with.
Pro AppData Redirection
- Smaller profiles. That means faster logons since less data needs to be copied. Logoffs benefit to some extent, too, but not as much as logons, because with roaming profiles only changed files are copied back to the file server during logoff.
- Data sharing between sessions. Typically AppData is redirected to one folder per user, and the same folder is used from multiple sessions concurrently. That means if you run application X in session 1 and it stores a file in AppData, that file will immediately be visible to another instance of application X in session 2.
- Overall less storage required. In siloed environments or any network with multiple profiles per user, AppData exists only once per user instead of once per profile. This may save up to several dozen megabytes per user.
Con AppData Redirection
Performance on the file server. RDS sessions may hit the file server – hard. Most (if not all) developers assume they are storing data on a local disk if they read from or write to AppData. Since local disks are pretty tolerant performance-wise (at least compared to a network) a developer may not even notice that his application causes far more IOs than necessary. Some common mistakes include: reading/writing files in many small chunks, and reading/writing the same files over and over again.
In other words, applications from your RDS sessions will create significant additional load on your file servers. This is not a problem if the file servers have enough spare capacity, but it may overload them if already near capacity without AppData redirection.
- Performance on the client / terminal server. Perpetual network access slows applications down. Applications have to go and fetch each file from the network which is often a lot slower than getting data from a local disk. Not only do programs take longer to start up because of this, the network lag may also lead to noticeable pauses during application execution.
- Concurrency issues. Suppose you have an application that prevents multiple instances of itself from running because its developers knew it would not work, maybe because some file in AppData is locked exclusively by each instance. This works well on a single machine, but there is no way instance 1 on machine 1 can prevent instance 2 on machine 2 from starting. Both instances would then use the same data which might have unforeseen consequences, such as data loss.
- Multi-version issues. Suppose you have two versions of the same application in two different silos. Both versions use the same config file, but store data in a different (and incompatible) format. What happens if version 1 in silo 1 creates a file in AppData and version 2 in silo 2 later tries to open it, assuming it is a version 2 file? Anything might happen, up to data loss and application crash.
What Do You Think?
These are some pros and cons that came to my mind. I freely admit some of them are more relevant than others. But more importantly, what are your thoughts? Should AppData be redirected or not? Does it work well, or is it a major PITA? Please let us all know what you have learned.
I’m in the middle of thinking whether or not we’ll redirect AppData.
One major Con you could add to your list is “application incompatibility with AppData UNC path”. I’m referring to a widely used software: Adobe Reader/Acrobat. Most of the time it crash on launch! Some are pointing that Adobe X corrects the problem, others are telling that after an update (10.0.1) the problem is back. Moreover, we cannot afford to upgrade every Adobe Acrobat (7-8-9) licenses to X in one shot.
So, I’m pretty confused right now.
To redirect of to not redirect, that is the question!
Many (but not all!) experts from the Citrix community will recommend not to redirect AppData. I am more con than pro, too. And I agree with you that application compatibility, especially Adobe Reader, is a problem.
Too many (bad) apps put data in places other than %appdata%. Chrome puts data in %userprofile%\local\google\chrome (unless you reconfigure it with group policy). Java apps put data in the folder above Desktop (usually %userprofile% unless you desktop).
What should we do? Redirect or not?App data folder fills up 30 GB space….
You should identify the application that is storing all that data. Then find out if it can be configured differently or if a newer version is available that does things less stupidly. If that does not help try replacing the application. If that is not possible try to get the application developer to store data somewhere else. If all fails you are doomed and have to think about redirecting AppData.
I think you *should* re-direct AppData except when there are app compat and performance related issues which is pretty often!
Clearly “legacy” re-direction is problematic, but a very worthwhile effort would be to study this with modern OS’s having SMB3 on both client and server….
I’m a Junior Network Admin at Alpine Learning Group, a school for kids with Autism; a LOT of research goes on here. We have limited IT resources, as we are a non-profit. Although this is an old thread, I have found it highly enlightening and Thank You for posting it!!
Before we decided to enable Roaming Profiles, we made sure all our PCs are on Win10 Pro x64 v1607 AND MS-Office 2016 32-bit. This was to make sure Quicklaunch Shortcuts work as expected. So far – So Good! We were using “Generic” Sign-ins, for Teachers (about 50). When we “created” the Roaming Profiles, they all worked well. This helps us retire these “Generic” Profiles, which are not HIPAA-compliant.
My issue is making “Static” (“Local”?) profiles into Roaming Profiles. I noticed the Appdata folder was huge. Since we don’t have the Server-Resources, to redirect folders in general at all, my question is about the 3 folders in the Appdata folder: Local (huge) Local Low (small) and Roaming (small).
As their names imply, can we:
1) …assume that the …appdata\local folder does NOT roam?
2) …assume that the …appdata\local low folder does NOT roam?
3) …assume that the …appdata\roaming folder DOES roam?
Also, any new info relating to this topic would be greatly appreciated!! Thanks again!!
AppData\Local and LocalLow don’t roam in a roaming profile by default…..however you can “make” them roam by messing with a particular Registry key as shown in this video https://www.youtube.com/watch?v=R4R4QlExLsU&t=3s
Personally I wouldn’t risk this, and use a solution like Microsoft User Profile Disks or FSLogix Profile Containers to achieve what you want (roaming the entire profile). Microsoft UPD is free (although only supported for Windows 10 on VDI) but only can handle a single session at a time. FSLogix has a cost attached, but can work multi-session and on all Windows 10 versions, not just VDI.
Thanks for sharing Helge Klein!
SUMMARY: I AM A BIG FAN (AT LEAST IN PRINCIPLE)
I appreciate that this article presumes a work/professional environment and specific controls/practices (like ‘Folder Redirection’ and ‘Roaming Profiles’) and/or the impacts given specific setups like Citrix, etc – which is fine… While I can not talk to those specifically, I would say that I strongly endorse and recommend the general principle of (to avoid the use of any specific methods)… “synced appdata” — I configured this on my personal computer years ago and it was a complete game-changer!
WHAT I MEAN BY “SYNCED APPDATA”?
— In terms of general principles, I mean some or all of the sub-folders inside %AppData% [and possibly %LocalAppData% but will address that below] being synchronised with some kind of central system (i.e. a fileserver, cloud service such as OneDrive or Dropbox, etc).
— For me specifically, I use OneDrive as my synchronisation source and manually map selected sub-folders from their location in %AppData% to a OneDrive-synced folder using Junctions / Symbolic Links
— I use multiple machines and this effortlessly and seamlessly* synchronises my settings and app configurations across all my devices, so when I change the settings for an app on my PC, those new settings are also applied to that app on my laptop… [* as you rightly point out, there can be save conflicts / concurrency issues but in my experience they are very occasional, probably < 0.1% of the time]
— This also protects all my settings in case of device loss or drive failure… I have taken advantage of this repeatedly over the years, and again has made a HUGE improvement to (a) peace of mind, knowing that if my hard-drive dies tomorrow, everything is backed-up and (b) ability to completely format my machine (or use a new machine) and to have all my previous settings backed-up and ready to use, I just need to login to OneDrive, setup my junctions and I am back up and running
— In terms of "bloated appdata directories" and excessive loads on remote fileservers, I am able to (at least partly) mitigate this by *selectively* choosing which sub-folders to sync (redirect with a junction) on an app-by-app (folder-by-folder) basis.
— Finally, while this is a definite feature of OneDrive (your benefit with other tools may vary), having automatic file recovery (recycle bin) and roll-back (version history) for all my settings is also very handy, as there would've been times when work was lost or things would have to have been done all over again, but I was able to use the cloud recycle bin / version history to recover the previous settings and restore everything.
ITS NOT PERFECT
— "bloated appdata directories" can still be a nuisance, and although in my case they don't cause any noticeable performance issue, from time-to-time I will get surprised when I check a newly-installed app's AppData folder and find it has thousands (or every tens of thousands) of files in it — often for an app which on the surface seems relatively simple… It is possibly to redirect only a specific sub-folder within that folder (or even target specific files individually) but this has be done on a cost-benefit ratio for the time involved.
— Coming back to LocalAppData, again as you rightly pointed out Helge, many developers don't design their apps with any kind of roaming principles in mind… There are many apps which use AppData (meant for roaming or "syncable" data) to store temporary files and things that can easily be transferred from one machine to another, and conversely there are a few apps I use that store their settings in LocalAppData (meant to be for "unsyncable" data) that I have re-mapped with junctions and synced across multiple devices without any issues at all.
BENEFITS OUTWEIGH THE CONS (TO ME)
Having benefitted from this in my personal computing life for the past decade or so, I still finding it puzzling when I work for a new organisation and they have not implemented any kind of roaming profile or folder redirection… I know setting in a work setting, there would be more work involved, but given the above-mentioned advantages that I've experienced, personally I pretty much see this as a must!