This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles.
One of the problems inherent to roaming user profiles is that they are copied to the local computer during logon. That takes time. Hence the motivation to limit the size of user profiles. One way of doing that is to put a quota on them, another one is folder redirection. Although widely used, redirection has its problems; problems so grave that Shawn Bass started to campaign against using folder redirection altogether. In this article I describe why Shawn despises redirection, which alternatives are available now what we can hope for in the future.
User profiles tend to grow over time. Growth is caused by users putting files in their Documents or similar folder and by applications storing settings in the roaming AppData directory. Growth by itself is natural and totally OK. It gets problematic, though, when we introduce another variable: stateless systems.
Terminal servers and many virtual desktops are stateless. They store user data only temporarily and are reset to a pristine state as soon as the last user session ends. As a consequence, the device cannot be used to store data permanently. Everything must reside on file servers and either be accessed over the network or be copied temporarily to the local hard disk. Home directories are an example for the former, user profiles an example for the latter.
Copying user profiles to the local hard disk slows logons, potentially dramatically (since the logon process is halted until the copy is finished). Slow logons on a PC that is booted up in the morning and shut down in the evening are not so bad, but published terminal server applications are used much more dynamically than that. Session setup happens every time a user starts an application, and the user profile is loaded into each session. Delays are much more critical here. Thus the motivation to keep user profiles small.
One way to do that is folder redirection. It allows administrators to move certain parts of the profile to a different location, typically the home directory. Since less data is stored in the profile, it stays small and logons are fast. By redirecting from the local hard disk to the network we gain logon speed, but we lose – reliability. Files are not fetched from the local hard disk any more (a simple and pretty reliable operation). They travel over the network instead, a much more complex process. For it to happen smoothly, both the network and the file server need to be in tip-top shape and not too heavily loaded. Any “hiccups” may cause frozen desktops and applications. As Shawn Bass put it, IO delays may cause application denial of service.
To understand the gravity of the problem, one needs to know why applications do not handle network delays gracefully. It really is simple: because applications do not know that they are fetching data from the network. Folder redirection is transparent to applications. When a developer writes code that accesses a file in the user profile, he assumes the file is stored on the local hard disk and does not plan for significant delays like he would if he were accessing a file on the network. As a result, the GUI thread is blocked until the IO has completed. And a blocked GUI thread means a frozen application.
Many people think that PCs are pretty much independent of the backend infrastructure – with folder redirection they are not! When there are problems in the backend, the users cannot work any more.
The Solution (as it Exists Today)
So what do we do? If I have not scared you enough, if you have great networks and file servers or if you just do not care, you continue to use folder redirection. In all other cases, you should at least consider alternatives. Unfortunately I am only aware of one, and it is not perfect yet either: profile streaming.
If you do not wait for the copying, session setup is fast and folder redirection is not necessary. Profile streaming does just that: it moves the copying from the foreground to the background. Asynchronous instead of synchronous. The logon process can continue while the user profile is being copied from the file server. That sounds too good to be true, and it is (partially). You should be aware of the following downsides:
- Profile streaming is available from few vendors only. I am aware of AppSense, Citrix, RES and VMware.
- It adds complexity. There is more that can go wrong.
- It does not reduce the load on the file server during peak logon times.
- Profile size still matters, since the entire profile needs to be copied to the machine. Very big profiles may overload the file server during peak logon times (see previous point).
The Solution (as it Should Be)
Profile streaming needs to evolve and solve the last two remaining technical problems, too: profile size and file server load during logon. The way to do that is to identify when files were used last. If that information is available for each file, then a policy can be implemented to only copy the files that have been used in the last six months, for example. Everything else would be streamed on demand. This way dependency on the network is limited to files that are unlikely to be accessed and responsiveness of the applications that are used regularly is guaranteed.
Implementing what might be called profile streaming 2.0 should not be too hard. I really hope to see this in a product some day. As an added benefit, it would remove the need to use profile quotas (something I am not too happy with).
User profiles are difficult. There is no perfect solution. Be aware of potential problems and use what works best for you.