Blog Trying to write an article concerning actual real world implementation of technologies like roaming profiles and folder redirection has proven surprisingly difficult.

At first blush it would appear to be a straightforward project: distil the research I have done on the subject over the past few weeks, combine it with several years of experience in the area and produce a 'how to'. Hopefully I can even throw in a bit of levity and a tone that makes the subject approachable by systems administrators who have only been ever so briefly introduced to the topic before it was on to the next chapter.

The reality of the situation has proven to be quite different.

Of all the things that have caused friction in my career, ensuring that user data is put in the right place so that it can be made redundant and backed up is the big one. It ties into other things, such as VPN versus VDI, network bandwidth and limits of local storage. There are liability concerns regarding the confidentiality of synchronised data, what should be locally cached, what shouldn’t. Most importantly perhaps, things like offline document availability are a huge concern for my travelling users. Since the topic is so vast and interconnected, I find it impossible to simply spit out raw information without context.

The problem is that when dealing with technologies designed to copy, redirect or in any way change the default storage behaviour of user data, the context is absolutely critical. Blindly implementing any of these technologies is one of the biggest (and sometimes last) mistakes that a systems administrator can make at any company.

So instead of an article that simply lists the click-by-click details of how to administrate these technologies, I am going to take the opportunity to have a frank discussion about the different scenarios you are likely to encounter. I leave it up to you to Google the actual implementation details.

The first scenario, and possibly the easiest, is one in which all your users are local or 'on net' all the time. Every single user you have is connected to the corporate network in one way or another, no exceptions. These could be folks on a VPN link, site-to-site links, RDPed into virtual machines, or even sitting in the same building as the servers themselves. Let’s dispense with the formalities and just outright say this folder redirection is the way to go here. Unless your users are hoteling (more on that later) roaming profiles is simply a bad plan. With folder redirection you don’t need to copy the whole profile over to the server every logon, you can simply redirect Application Data, Desktop, My Documents, and Start Menu to the server via group policy.

This is quite simply the quickest and most robust way to deal with this problem. The data is simply stored on the server, and since your users are required to be connected to the network at all times, then that data never has to be replicated anywhere. A VPN user (say teleworking from home) would not have a local copy of these folders, and would therefore have reduced liability exposure. The caveat of course is that you have to have wide enough network pipes between your users and your server, and the server itself needs to be fast enough to serve the data to users at something more than a glacial pace.

There are a couple of things to bear in mind about folder redirection. If you are implementing folder redirection for branch offices, you might consider plunking a file server in each branch, and using a combination of distributed file system (DFS) and distributed file system replication (DFSR) in tandem with folder redirection. DFS and DFSR can take care of replicating the data from the branch back to head office for you, and your users would have access to a higher-speed local copy of their data. All while still being stored on RAIDed and backed-up servers.

Also bear in mind that folder redirection is designed to work in tandem with offline files and folders. In order to store the user data on the server, but prevent long, tedious and unnecessary synchronization, make sure that offline files and folders is either disabled by group policy, or that the relevant folders are excluded individually on each machine.

Of course, even with all users being on net, there are still usage scenarios that can throw roaming profiles or folder redirection for a loop. In my previous article I mentioned users that log onto more than one machine (hoteling). If the user expects their 'user experience' to be the same on each PC, (ie their settings for various programs go with them from computer to computer) you may not be able to get away with just folder redirection.

Instead it can be a very good idea to consider the use of mandatory profiles. You can set up a profile for your user, get the settings just right, and then convert it to a mandatory profile. Mandatory profiles are read-only - the local copy is never replicated back to the server. If you combine a mandatory profile with folder redirection, you get a profile where the 'critical' folders (the ones where the user and most well behaved programs store the bulk of their data) exist only on the server but the user experience is pre-configured and identical across multiple machines.

If you have multiple users that hotel across computers, you might want to take a look at 'delprof' from the Windows Server Resource Kit. It is a neat tool provided by Microsoft that cleans out local copies of profiles older than a supplied date. Combine it either with Systems Management Server or logon/logoff scripts, and you have an effective way of providing a constant user experience to hoteling users, protecting their data, and ensuring their profile footprint on the computers they use doesn’t grow out of control.

As always, there are a couple of snags. The dividing line between Windows 2000/XP/2003 (NT5) and Vista/7 (NT6) is enforced here. Roaming profiles, whether mandatory or not, simple aren’t cross-compatible. If you create a profile for an NT5 user, then as soon as they long onto an NT6 system it will create a folder called %userprofile%.v2 in your profiles share on the server. Irritating as that might be, it is actually a perfectly manageable situation.

Create two mandatory profiles, (one for each NT5 and NT6,) and folder redirection will work across the profile boundary. The gotcha on this is that certain applications tend to have problems when hoteling and folder redirection are combined. Multiple instances of the same program on different computers trying to access the same file (the only copy being that which lives on the server) can and often do cause problems. Multiple simultaneous systems using folder redirection where some are NT5 and some are NT6 is right out. I feel the need to reinforce this issue very strongly: when using roaming profiles or folder redirection use different users for NT5 and NT6 wherever possible. Thorough lab testing is therefore crucial before rolling out anything like roaming profiles or folder redirection into production.

The next up on the list of scenarios are remote users requiring offline access to their files. The most important question to ask yourself is if you are using encryption. Any notebook or remote PC that will be outside the corporate firewall storing a local copy of corporate information absolutely must be encrypted. If you are not encrypting your remote devices, then stop reading right now and solve that problem first.

If you have dealt with the liability issues surrounding storing copies of data outside the corporate firewall, then Microsoft has in theory got you covered. As has been discussed in my previous article, roaming profiles copies nearly the entire profile from the local device to the server. More importantly, folder redirection by default uses offline files and folders - it’s designed with this sort of thing in mind.

If your user lives on their notebook, doesn’t hotel, and can tolerate a profile rebuild if the notebook is lost, then folder redirection is the order of the day. If the user would still expect rapid turnaround in the case of the loss of a notebook, then enable roaming profiles and be done with it. If that user had a notebook, but also a local system inside the corporate firewall, then combine roaming profiles with folder redirection. Disable offline files and folders on the system connected to the corporate network while leaving it active on their notebook.

Sadly, if you were under the impression that this wraps up user data issues in a neat little bow, you really should know better than that. As I mentioned in my previous article, users with notebooks almost never actually log off or reboot their systems. You can try to force them to - GPOs that shove Windows Updates down their throats are effective at this, though they meet with harsh end user resistance. You can set up GPOs to force a logoff at a particular time, but I guarantee that will be allowed to happen exactly once. Instead, if at all possible, stick solely to folder redirection. Most critically, use Windows 7 and Server 2008 R2’s folder redirection.

In case you were wondering what Windows 7’s 'killer feature' is, the new treatment of offline files and folders finally won an upgrade refusnik like me over. If you’ve ever had problems with offline files and folders in the past (which would include every single person who has ever had to use it), then I heartily recommend taking the new one for a spin. It isn’t perfect, but offline files and folders under 7/2008 R2 is far more advanced than that of NT5 or even Vista. There are fewer errors, less issues with locked files and you can schedule synchronization.

More importantly, you can trigger synchronisation from scripts, which can themselves be triggered by any of a vast array of things in the new and very improved task scheduler. Scheduling and scripting can really help mitigate the issues that exist with notebook users not being connected to the corporate network when (or if) they log off. My canonical example would be a notebook scripted to wake itself from hibernation at 4am every night, only if not running on batteries. It would then connect up the VPN, synchronise offline files and folders, and then go back into hibernation. Even if the user never logs that notebook off, the data is still synchronised off to the server every night.

As mentioned earlier, there simply isn’t room in a single article to cover everything related to a topic this vast. While I’ve gone over the most common scenarios here, there are still more tools to look at that help us deal with the special cases that always occur to deviate from the norm. My next article will explore the 'slow link' group policy settings and how they can be one of the most useful tools in dealing with roaming profiles and folder redirection. I’ll also talk about super mandatory profiles and why resultant set of policy (rsop.msc) is your friend. ®