If your users travel from machine to machine on your network, you can have their personal settings follow them by implementing roaming profiles. Here's how you can configure roaming profiles using Windows Server 2003's Folder Redirection feature.
/One of the nice things about the Windows XP operating system (and some of the other previous Windows operating systems) is the way that it allows each user to maintain their own individual settings. If multiple users share a PC, each user can have their own wallpaper, screen saver, desktop, etc. without interfering with anything that other users might have set up. Windows accomplishes this feat be maintaining a separate profile for each user.
Although profiles do a great job of allowing each user to treat the PC as if it was their own, there is one major problem with them. By default, profiles do not follow users from one machine to another. This means that if a user goes to use a different machine, they will have a totally different experience from what they are used to. Profiles can help solve this problem, but they can be a nightmare when users jump from machine to machine. Here's how you can make them work using Windows Server 2003's Folder Redirection feature.
Why are roaming profiles a pain?
The reason why this is a problem is because a user's profile contains much more than just the user's cosmetic preferences. A profile also contains application configuration data. For example, Microsoft Outlook doesn't just automatically know where to find a user's mailbox, it must be configured. Since each user uses a different mailbox, there isn't one global configuration that can be applied to Outlook. Each user's individual configuration information for Outlook is therefore stored within the user's profile.
Obviously, this means that if a user decided to use a different PC, then Outlook won't work, and there will probably be a few other things missing such as icons, Start menu items, and Internet Explorer favorites. However, if you work in an office in which everyone has their own PC, this might not even be a concern because there is no reason for users to be using someone else's PC.
In a perfect world, that might be true, but keep in mind that PCs do occasionally malfunction. Imagine for a moment that a user is in the middle of a critical project and their PC malfunctions. They would probably end up having to borrow someone else's PC while you fix their PC. If the borrowed PC isn't set up for the user though, you may find yourself having to configure the PC for the user before you can even start trying to fix the malfunctioning computer. This means a lot of extra work for you.
Now, let's look at another reason why local profiles might be an issue for you. Suppose that a user's hard disk goes out. The user isn't working on anything important at the moment, so they can take the rest of the afternoon off while you replace the damaged hard drive. As you replace the drive, you think to yourself how easy this job is going to be. You can use your RIS server to reload the operating system and applications for you. Since the user's documents are all stored on the network, there is nothing for you to restore. However, the next day, the user comes back, logs on to their PC, and asks you "Where's all my stuff"? The computer is no longer displaying the user's custom desktop, and the user's shortcuts and Internet Explorer favorites are all missing.
The problem is that all of the files related to the things that are missing were stored locally. This means that those files were lost when the user's hard drive failed. Since most companies do not backup workstations, there is no way of getting the user's configuration back. It will be up to the user to recreate anything that was lost, and it will be up to you to reconfigure the user's applications. You've now got that job ahead of you and you've got an upset user on your hands.
All of these problems could be prevented if you took advantage of the roaming profiles and folder redirection features offered by Windows Server 2003. The basic idea behind this concept is that the user's profiles are stored on the server. This means that the user will have the same profile regardless of where they log on. It also means that you can backup all of the files that make up the user's profile.
It's actually very easy to implement roaming profiles. Before I show you how to set up roaming profiles though, there are some issues that you need to be aware of. If you just blindly enable roaming profiles, you can cause some serious performance and availability problems for your users. Just to make sure that we are all on the same page, I want to start out by talking about what exactly is contained within a user's profile.
How Windows handles profiles
Different versions of Windows handle profiles slightly differently, but in Windows XP Professional, user profiles are stored within the C:\Documents and Settings folder. The C:\Documents and Settings folder contains sub folders for every user who has ever logged into the machine. For example, on the workstation that I am using to write this article, there are folders named Administrator.Production, Administrator.Stewie, Brien, and All Users. There are also hidden folders named Default User, LocalService, and NetworkService. The three hidden folders are used by applications and services to interact with the operating system. They are beyond the scope of this article, but I wanted to at least mention their existence.
OK, so what about the visible folders? The All Users folder contains profile elements that apply to anyone who logs into this machine. The Brien folder contains the profile for my user account. There are two Administrator folders; Administrator.Production and Administrator.Stewie. Production is the name of the domain that the workstation is connected to and Stewie is the name of the local machine (named after one of the characters on the cartoon Family Guy).
Windows treats a local user and a domain user as two completely separate user accounts, even if they have the same name, and therefore maintains completely separate profiles for them. You will notice that the folder named Brien does not contain an extension. This folder contains a profile for a domain user named Brien, but no extension is necessary because there isn't a local user with the same name.
I should also point out that there are certain disaster recovery situations in which you may have to install a fresh copy of Windows. When this happens, Windows won't overwrite existing profiles, but it won't re-use them either. Instead, Windows will add yet another extension. For example, if the Administrator.Production folder already existed, but Windows had to be reloaded from scratch, then the next time that the Administrator from the Production domain logged on, Windows would create a profile folder named Administrator.Production.000. In a situation like this, you could actually restore the user's original profile by copying all of the files from Administrator.Production to Administrator.Production.000.
Now that you know how the naming conventions work for profile folders, let's talk about the folder's contents. Normally, a profile folder contains about a dozen sub-folders and at least three files. Most of the folders are pretty self explanatory. For example, the Cookies folder contains Internet Explorer cookies. The Application Data folder stores configuration information user specific information related to applications. However, the Local Settings folder also contains its own Application Data folder.
Aside from that, the most important folders within a profile folder are My Documents, Desktop, and Start Menu, which store the profile owner's documents, desktop settings, and Start menu configurations respectively. There are several other folders used by profiles, but they are fairly self explanatory, and you won't have to do anything with these folders as a part of any of the techniques that I will be showing you.
As you can see, there are a lot of different components that make up a user profile. Profiles include a user's application data, documents, cookies, desktop, favorites, recently opened document list, network neighborhood list, network printer list, send to option list, and templates. The reason why I am telling you this is because after you enable roaming profiles, all of these profile components will have to be copied to the network. It wouldn't be so bad if the information only had to be copied once, but usually, everything that I named has to be copied every time that a user logs in or out.
The first time that a user logs on after roaming profiles have been enabled, Windows has to copy the local profile to the designated spot on the network. After that, every time the user logs on, the entire profile is copied from the network server to the user's local hard disk. The user then works off of the local copy of the profile throughout the duration of their session. When the user logs off, the local profile (including any changes that have been made to it) is copied to the network. This might not sound so bad, but keep in mind that user's profiles can be huge. Just the My Documents folder alone can easily be several hundred megs in size. I have personally seen several instances in which a user's profile was so large that it took over an hour for the user to log on or off because so many files had to be copied.
The easiest way to get around this problem is to use folder redirection. The idea behind folder redirection is that you can tell Windows that certain parts of the user's profile should remain on the server rather than being copied each time that the user logs on or off. This drastically reduces the amount of time that it takes users with large profiles to log on or off.
Windows allows you to individually select which folders you want to redirect, but the folders that are most often redirected are My Documents, Application Data, Desktop, and Start Menu.
In a few moments I'll show you how to enable roaming profiles and folder redirections. Before I do though, there are a few caveats that I want to talk about. The first issue that you might encounter has to do with the user having limited functionality on a machine. Technically, a user should be able to log into any PC and have the exact same experience. However, I have seen a few situations in which the user's experience won't be quite right unless the user has been configured to be a power user on the machine. For example, the user's wallpaper might not display, or the user's screen saver might not work.
This behavior is the exception rather than the rule. If you do run into this type of behavior though, you can fix the problem by opening the Control Panel and clicking the User Accounts link. You can then add the user's domain account to Windows and make the user a member of the Power Users group.
Another issue that sometimes causes a roaming profile to not act quite right is when the profile references a local file that exists somewhere other than the profile directory. For example, if a user were to create a wallpaper file and then place the file into the C:\Windows folder, the profile would reference the wallpaper file, but would not actually include the wallpaper file. That means that if the user were to log onto a different machine, the profile would be unable to load the user's wallpaper because the wallpaper file does not exist on the local machine or within the user's profile.
One last issue that I want to discuss is availability. Earlier I explained that it was a good idea to store profiles on a server because it allows you to back the profiles up each night. However, if the server containing the profiles were to go down, it can cause some problems for the users.
If the server containing the profiles were to fail, the users would still be able to log in and in may even be able to use their own profile because Windows XP maintains a cached copy of the profile. This cached copy would be available for the user's use assuming that they had previously logged into the workstation. The users would just not be able to save changes to the profile since the profile server is down.
I have gotten around this particular issue by placing the user profiles and redirected folders onto a DFS root. The reason for this is that you can create multiple replicas of a DFS root. This means that you can have copies of profiles and redirected folders on multiple servers. When everything is functioning properly, the multiple replicas help to balance the workload. If a DFS server goes down though, the remaining replicas can pick up the slack. Having multiple DFS replicas also allows you to take a replica offline for maintenance without disrupting the users.
Configuring roaming profiles
The basic technique behind creating a roaming profile involves creating a shared folder on the server, creating the user a folder within the share, and then defining the user's profile location through the group policy.
Begin the process by creating a folder named PROFILES on one of your file servers. You must then share the folder. I recommend setting the share level permissions to grant Everyone Full Control. You should then grant everyone Read permissions to the folder at the NTFS level.
At this point, you will want to create a folder for each user. The folder name should match the user name. For example, if you have a user with a username of Brien, you'd create a folder named \PROFILES\Brien. Once you have created a user's folder, grant Full Control to the user who the folder will belong to and to the domain administrator. You must then block permissions from being inherited from the parent object. Otherwise, everyone will have read access to the folder. In most situations, this will take care of the necessary permissions. However, I have seen at least one network in which the backup software was unable to backup the user's profile directories until the backup program's service account was granted access to each user's folder. That is the exception rather than the rule though.
Once you have created the necessary folders and defined the
appropriate permissions, it's time to redirect the user's profile. To do so,
open the Active Directory Users and Computers console, right click on a user
account, and select the Properties command from the resulting shortcut menu.
When you do, you will see the user's properties sheet. Next, select the
properties sheet's Profile tab. Enter the user's profile path as:
For example, if you created a share named PROFILES on a server named Tazmania, then the path to Brien's profile should be \\Tazmania\PROFILES\Brien. Click OK and then the user's profile will be roaming starting with the next login.
After you enable roaming profiles, you will want to redirect the more heavily used folders. You will have to create a separate share on your file server to handle the redirected folders. On my server, I created a folder named USERS (and shared the folder as USERS), but you can call the folder anything that you want. Just make sure to assign Everyone Full Control at the share level.
Once you have created the necessary folder, open the Group Policy Editor and navigate to User Settings | Windows Settings | Folder Redirection. The group policy requires you to redirect each of the four folders separately, but the procedure for doing so is the same for each folder. Set the folder's Setting option to Basic—Redirect Everyone's Folder To The Same Location. Next, select the Create A Folder For Each User Under The Root Path option from the Target Folder Location drop down list. Finally, enter your root path in the place provided. For example, on my test server the root path is: \\TAZMANIA\USERS as the root path.
After you configure folder redirection, Windows will automatically create a folder for each user beneath the USERS folder. Windows will also assign the necessary permissions to each dynamically created folder.
As you can see, profiles are a handy way of storing data, but they can be problematic if users tend to move from machine to machine. With a little bit of work and some help from Windows Server 2003's Folder Redirection feature you can configure profiles to follow your users around the network as they switch from machine to machine.