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.

, , ,

8 Responses to Should AppData be Redirected or Left in the User Profile?

  1. Billy Angers July 22, 2011 at 15:00 #

    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!


    • Helge July 22, 2011 at 15:09 #

      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.

  2. Alex February 17, 2014 at 10:53 #

    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).

  3. Hikmet February 4, 2015 at 18:59 #


    What should we do? Redirect or not?App data folder fills up 30 GB space….

    • Helge Klein February 4, 2015 at 21:29 #

      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.

  4. Steve Greenberg February 5, 2015 at 02:36 #

    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….

  5. Mike Brennan April 4, 2017 at 18:15 #


    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!!

    Mike Brennan

    • James Rankin December 7, 2017 at 10:27 #

      Hi Mike

      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

      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.

Leave a Reply