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.