As in any computing environment, home drives in MetaFrame XP environments provide a private location where users can store their personal files and data. In MetaFrame XP, home drives can be used in addition to user profiles for storage of application configuration information.
The golden rule for home drives in a MetaFrame XP environment is this: the more users store in their home drives, the less they are forced to store in their user profile. This is crucial, because a user's entire roaming profile must be copied on to the MetaFrame server when they log on, and off of the server when they log off.
Traditionally, users' home drives are network shares mapped to drive letters when the users log on.
In some MetaFrame environments, users won't need to save their own files, so you won't need to make use of explicit home drives for each user. However, users in these environments will still technically have a home drive location, even though they wouldn't have an explicit drive letter mapped to it. To understand this, let's take a look at how Windows home drives work.
How Windows Home Drives Work
Whenever a user logs on to a Terminal Server, the server designates one folder to be the user's home folder (home drive). You can specify the exact location of the folder that becomes a user's home drive via User Manager for Domains (for Terminal Server 4.0 environments) or via the Users and Computers MMC snap-in (for Windows 2000 environments).
Similar to a user's profile path, you can specify two home drive locations per user-one that is used when users log on to regular computers and one that is used when users log on to Terminal Servers. In either case, the home drive can be a local path on the computer where the user logs on or a drive letter that is mapped to a UNC share.
Configuring a user's home drive as a property of his user account is an easy way to give each user his own private storage space while ensuring that drive letters will be mapped properly and permissions will be set correctly. Other than that, there's really nothing special about home drives configured as part of the user's account-they simply provide a location for users to store personal files and data.
When a user logs on to a MetaFrame XP server, the server contacts a domain controller to retrieve the user's home drive location. It first checks for a Terminal Services home drive. If no home drive is specified, the server will then check for a regular home drive location. If no home drive is specified in either place, the server will create a home drive in the user's local profile. This process is outlined in Figure 5.7.
Figure 5.7: Home Drive Mapping Process
Whenever a user logs on, the server sets two system variables to indicate the path of the home drive: %homedrive% and %homepath%. These variables allow Windows applications to locate a user's home drive no matter where it's located. For example, let's assume that a user's home drive can be found in the following location: h:\home\.
In Terminal Server 4.0 environments, the %homedrive% variable would be set to "h:" and the %homepath% variable would be set to "\home\." In Windows 2000 environments, the %homedrive% variable would be set to "h:\home" and the %homepath% variable would be set to "\." The change in usage of these two variables between platforms has to do with the fact that Windows 2000 environments support "deep shares." A deep share allows you to map a drive to a path like \\server\share\subdir1\subdir2\ subdir3\. The root of the share would be anchored at "subdir3." In Windows NT 4.0 environments, drive mappings could only be anchored at the share level, meaning that the root of the above share would be anchored at "share."
In the real world, it's confusing to the user when he accesses his home drive letter and sees several subfolders, one for each user. This would cause the user to have to browse through the file structure to find his own home folder. More often, users' home drives are located at the root level of a drive mapping, such as "h:". In these environments, %homedrive% is set to "h:" and %homepath% is set to "\."
If you're not sure what the %homedrive% and %homepath% variables are in your environment, you can always check them from the command prompt by typing echo %homedrive% or echo %homepath%. Of course, you can also view all of the environment variables that are set by typing "set."
How are Home Drives Used?
Most people think that home drives are only used to store users' personal files. While this is a primary use for them in MetaFrame environments, home drives also serve a few other important purposes. In MetaFrame XP, home drives are used for:
- Windows system configuration information.
- Application data and configuration information.
- Personal files.
Windows and System Configuration Information
By default, the system creates two folders in each user's home drive: windows and windows\system. Any application looking for the server's windows or system directories to read or write .INI or configuration files is routed to the appropriate directory in the user's home drive. That way, each user can have his own configuration for applications.
These two folders are the only items automatically created in a user's home drive, and you should not remove them. Of course, most users will create many more folders on their own.
Application Data and Configuration Information
Many applications require configuration folders to store user settings and data. Often these folders are created in addition to the windows and system folders. By putting this data in the user's home drive, an application can ensure that its settings will be unique for each user.
Perhaps the most important use for home drives is to store users' personal files. In addition to the data files that users store directly in their home drives, many administrators configure a policy that redirects the user's "My Documents" and "Application Data" folders into their home drives. This procedure was discussed in the User Profiles section of this chapter.
By utilizing a user's home drive for personal data storage, you can leverage the advantages of roaming profiles without them growing too large, since all personal files would be located in the home drive, instead of the roaming profile.
Why should you care about Home Drives?
There are several factors impacted by the way the home drive system is designed in MetaFrame XP. Because home drives are used throughout users' sessions, it's important that they're designed to support the needs of the users. Areas that are specifically impacted include:
- Logon speed.
- File open/save speed.
- User data integrity.
If the home drive is part of the user's profile that must be copied down to the MetaFrame server every time the user logs on, logons will be slow. On the other hand, if the home drive is located on a separate network share, allowing the profile to be small, user logons will be fast.
File Access Speed
Many files will be read from and written to the user's home drive. If that home drive is located across a slow WAN link from the server running the user's MetaFrame XP server session, opening and saving files will be slow.
User Data Integrity
A well-designed home drive environment will protect the data and the files that users store on their home drives. If the home drive design is sloppy, or worse yet, if home drives are kept on MetaFrame XP servers, user data could be lost if problems occur.
What are the Home Drive Design Options?
Using home drives is fairly straightforward. There are a few options that you need to think about when deciding how home drives will be used in your MetaFrame environment. These options include:
- Home drive size.
- Home drive location.
- Number of home drives.
- Methods of specifying home drives.
Home Drive Size
Remember the golden rule to roaming profiles? (Hint: Keep them as small as possible.) Home drives make it possible to keep profiles small. After all, in order to shrink the size of a profile you need to have somewhere to put the data that you take out of the profiles. That "somewhere" is in users' home drives.
While roaming profiles should always be kept as small as possible, there is nothing wrong with a home drive that is several gigabytes or more. They're only limited by the amount of hard drive space you have on the server that stores the home drives. From the network bandwidth standpoint, large home drives do not pose a problem, because data is only copied across the network as it is needed.
So far, everything we've mentioned about home drives reduces to the idea that it's okay if they are large. However, there may be situations in which you actually need to limit the size of users' home drives. In Windows 2000 environments, it's possible to limit the size of home drives with disk quotas.
Disk quotas allow you to specify the maximum drive space that a user can use on an NTFS volume. Users are only charged for files and folders that they own. You can set two limits per user per disk volume. A "soft" limit produces an event log and a warning for the user that they are nearing their disk limit. A "hard" limit is the actual disk limit. When this limit is reached, the user receives an "out of disk space" error if they try to copy anything else to their home drive.
In many environments, politics prevents disk quotas from "officially" being used. Even so, you might want to set quotas anyway. Set really high, just in case a slick user decides to store his entire MP3 collection in his MetaFrame XP home drive.
Advantages of Disk Quotas
- Helps prevent servers from running out of space.
- Different users can have different quota sizes.
Disadvantages of Disk Quotas
- Users are charged per volume, not per directory.
- Requires Windows 2000.
- Hastily-configured quotas could prevent users from doing their jobs.
- Disk space is cheap, and quotas might be more trouble then they're worth.
Procedure for Implementing Disk Quotas
Disk quotas only work on NTFS volumes on Windows 2000 servers. They're managed through the "Computer Management" MMC plug-in (Administrative Tools | Computer Management | Storage | Disk Management | Right-click on Disk Volume | Properties | Quota Tab).
Configuring disk quotas is fairly easy. You can set both the limit and warning levels for new users. You can also click the "Quota Entries" button to configure a custom list for existing users. Interestingly, the drop down box for the quota limit starts at "KB" and goes all the way up to "EB," which is one billion Gigabytes, in case you have users that you want to "limit" to a certain number of EB's.
Location of Home Drives
In addition to home drive size, you also need to decide where your home drives will be located. Be careful when choosing the locations of home drives in relation to your network. While home drives must be located on a server that has the storage and processing capacity to support them, they should also be located in close proximity to the MetaFrame XP servers so users have quick access to their data from MetaFrame XP sessions.
When you specify the location of your users' home drives, it is important that you not put them inside your users' profiles. This does not mean home drive can't be on the same server as the profiles, it just means that home drives should not be part of the directory structure that is copied to and from the MetaFrame XP servers as part of a user's profile. If you put the home drives in the user profile, then all the work you do to minimize the size of the roaming profile is wasted.
When it comes down to the actual physical location of home drives, there are two choices:
- UNC share.
- Local drive on MetaFrame XP server.
Home Drives Accessed via UNC Shares
In most environments, the appropriate home drive location will be on a server that is available to all MetaFrame XP servers. The home drive is accessed through a UNC share name, and a drive letter is automatically mapped when the user begins his MetaFrame XP session.
Advantages of UNC Share-Based Home Drives
- The home drive server can be built with redundancy, including with RAID storage volumes.
- Individual MetaFrame XP servers can be taken offline without affecting the availability of user data.
Disadvantages of UNC Share-Based Home Drives
- An additional file server is required.
Procedure for Creating UNC Share-Based Home Drives
To create a home drive for a user, you simply specify the home drive in the user's profile configuration (via User Manager for Domains or the MMC). Choose the "connect to" drive letter and type the full UNC path to the home drive location. You may use the %username% variable. If you specify the home drive as "\\server\share\%username%," then the system will automatically create the home drive and set the appropriate permissions. (Be sure to double-check that the selected drive letter is not in use for that user. If it is, you will not receive any error messages, but the home drive will map to a local drive (see below), not the UNC path.)
Home Drives Stored on MetaFrame XP Servers
In some situations, you may choose to locate users' home drives on the MetaFrame XP server. This is usually done in small environments where the MetaFrame XP server is only one server.
Advantages of Storing Home Drives on MetaFrame XP Servers
- Cheap and easy.
Disadvantages of Storing Home Drives on MetaFrame XP Servers
- The contents of the user's home drive are not available when they log on to another server.
- A new home drive will be created on each server where the user logs on.
Procedure for Creating Home Drives on MetaFrame XP Servers
A local home drive is also configured in the user account properties in the "Local Path" section. The entry takes the form of "c:\path1\path2\ %username%." Again, using the %username% variable will cause the drive to be set up automatically the first time a user logs on.
Number of Home Drives
In most environments, each user will only have one home drive. However, there is no reason that each user needs to be restricted to only one home drive, or that multiple home drives for one user have to exist in the same physical location. Consider the following environment:
There are specific reasons that the user in Figure 5.8 must run his applications from MetaFrame XP servers in two different locations. This company will never have both applications installed on the same MetaFrame XP server because the databases are in two different locations. Because of this, there is no reason that the user's personal data for the application should be in one single location. The user can have one home drive at each location-each containing the user's files that are needed for that location.
Figure 5.8: Some users need data in multiple locations
Multiple home drives would make sense from a network standpoint, allowing the user to always have fast, local access to personal files from sessions on both MetaFrame XP servers. However, if you use multiple home drives you need to be careful. Don't try to make both home drives look the same to the user. You should probably not have both home drives mapped to the same drive letter (each in their own respective ICA sessions). While there is nothing technically wrong with doing so, it is confusing for the user to have a P: drive in two different ICA sessions that maps back to two different network locations. Users may switch back-and-forth between applications on different MetaFrame XP servers. They won't understand, for example, drive P: from Microsoft Word has one set of files and drive P: from the data warehouse application has another. Using multiple drive letters gives the user a clue that there are multiple network locations.
Advantages of Multiple Home Drives
- Local data access from sessions on remote MetaFrame XP servers.
Disadvantages of Multiple Home Drives
- Can be confusing if both drives have the same letter.
Instead of having multiple local home drives for each user throughout your enterprise, it's possible to configure directory replication so that the contents of one home drive are replicated to multiple servers throughout the environment.
Home drive replication is one of those things that sounds good on paper, but turns out to be a nightmare in real life. The data in home drives usually changes frequently, making it a bad candidate for replication. Also, the replication process takes time, so a user simultaneously using sessions on two MetaFrame XP servers that are far apart might have different versions of the same data, if the replication process has not completed.
Home drive data replication is mentioned here for the sake of thoroughness, because it has been used with limited success in some cases. In general, it is more trouble than it's worth.
Advantages of Replicating Home Drives
- The same user data is locally available to a user's MetaFrame XP session throughout the enterprise.
Disadvantages of Replication Home Drives
- User data can get out of sync.
- Replication times can be long.
- Bandwidth is wasted during the replication process.
- Additional management is required.
Methods of Specifying Home Drives
So far, we've focused on how home drives are configured as part of a user's domain account properties. While this is the main method of specifying home drives, there are other methods that have limited uses. In this section, we'll take a look at all the methods you can use to specify a home drive for a user, including:
- User account properties configured in the domain or Active Directory.
- Logon script.
- Folder redirection via an Active Directory group policy.
- Do nothing (let the system create a home drive automatically).
Method 1. User Account Home Directory Configuration
Before we look at some of the "alternative" methods of configuring home drives, let's look at the "official" way of doing it. In Active Directory or Windows NT 4.0 domains, domain users can be configured with a home drive that will be automatically mapped upon logon as part of their user account. Then, whenever that user logs on to a Terminal Server (any MetaFrame XP server), their home drive is mapped and set to the specified location without any extra configuration or scripting.
Advantages of Specifying Home Drives via User Account Properties
- Easy to do.
- The "homedrive" and "homepath" variables are automatically set.
- This is the "official" method of creating home drives.
- The home drive is created and permissions are set automatically.
- Easy way to specify different home directories for Terminal Servers and non-Terminal Servers.
Disadvantages of Specifying Home Drives via User Account Properties
- No flexibility.
Procedure for Specifying Home Drives via User Account Properties
In Windows NT 4.0 environments, you can only configure the Terminal Services home drive path with the version of User Manager for Domains that comes with a Terminal Server (User Manager for Domains from a Terminal Server | User Properties | Profile Tab | Terminal Server Home Directory | Connect X: to UNC or local path).
In Windows 2000 environments, you configure home drives with the MMC (MMC | User Properties | Profile Tab | Home Folder | Connect X: to UNC or local path).
You can use the following procedure to create home drives in Windows 2000 or Windows NT 4.0:
- Create a root folder to use for your home drives in the location of your choice.
- Give the "Everyone" group "Change" permissions on this folder.
- For each user, specify the home drives as "\\your folder\%username%."
In this case, you should literally type "%username%" in the box. This is a percent sign, the word "username," and another percent sign. Do not substitute the user's real user name for the %username% variable. If the username is "holli," then you would type %username% in the box, not %holli%.
When the user logs on for the first time, the system will automatically create the subdirectory for the username and give it the appropriate permissions. (Administrators get special access at the directory level only, the user maintains full control.) The windows and windows\system directories will also be automatically created, with administrators having full control.
Method 2. Logon Script Home Directory Configuration
Another way to specify a home drive is to use a logon script to map a drive to a network share and then to execute a command setting the home directory environment variable to point to that drive. (See the next section of this chapter for more information about logon scripts.)
Advantages of Specifying Home Drives via Logon Scripts
- Extremely flexible implementation of home drives.
Disadvantages of Specifying Home Drives via Logon Scripts
- Scripts must be manually configured.
- "Homedrive" and "homepath" variables must be manually set.
Procedure for Configuring Home Drives via Logon Scripts
Specifics of this method are addressed in the logon script portion of this chapter.
Method 3. Group Policy Folder Redirection
Active Directory group policies can be used to redirect local folders to network locations on computers running Windows 2000 and participating in Active Directory domains. For example, a user's "My Documents" folder can be redirected to a network share location that is centralized, so that no matter what computer the user logs on to, he would have access to the same data in his "My Documents" folder. Because this is a function of group policy, it can be applied only to the specific organizational units containing MetaFrame XP servers.
It should be pointed out that while redirecting the "My Documents" folder to a static network point can eliminate the storage of too much data in a user's profile, this is not technically a "real" home drive. In addition to a location for storing personal files, a home drive also contains certain system information, and a home drive is the target of the %homedrive% and %homepath% variables. That being said, if your users will only be using their "My Documents" folder for storage of personal files, you can probably get away with redirecting that folder and not worrying about the "official" home drive location.
Advantages of Specifying Home Drives via Group Policy
- Folder redirection can be used in addition to "official" home drives.
- Easy way to keep data out of profiles. (After all, isn't that the only reason we really care about home drives anyway?)
Disadvantages of Specifying Home Drives via Group Policy
- Not a "real" home drive.
- "Homedrive" and "homepath" variables will point to other locations.
- Applications that automatically write to the home drive will not write to a redirected "My Documents" folder (unless the home drive variables have been modified).
Procedure for Specifying Home Drives via Group Policy
Detailed information about folder redirection can be found in the previous User Profiles segment of this chapter.
Method 4. Do Nothing. Let the System Create a Home Drive
Finally, the "do nothing" approach is also a valid option with home drives. If no home drives are specified anywhere, the system will create a user's home drive in their local user profile (by creating a windows directory).
This solution can work for small environments where users will not store their personal files in the home drive. However, there can also be several problems with this method. If a MetaFrame XP server is configured to delete cached copies of roaming profiles at logoff, or if the local profile is overwritten by a roaming profile at logon, then the data in the home drive will be lost.
Advantages of Doing Nothing.
- Least amount of work.
- Might be sufficient in small, single-server environments.
Disadvantages of Doing Nothing.
- If local profiles are not cached, home drive data will be lost.
- If local profiles are overwritten by roaming profiles at logon, home drive data will be lost.
- The "doing nothing" approach will not work in multi-server environments.
Considerations when Designing Home Drives
Now that you know all of the options, answering the following two questions should get your home drive design started in the right direction:
- Does each user need to store personal files?
- Will users be logging on to multiple MetaFrame XP servers at different physical locations?
User File Storage
If your MetaFrame XP environment is used for specific applications only, it's possible your users will never need home drives during their MetaFrame sessions. Of course, if your users are running applications where they need to open and save files, or applications that rely heavily on personalized configuration (such as email), then it will be important to ensure that users have fast, reliable access to their home drives.
Single Users with Multiple Server Locations
If users will be connecting to MetaFrame XP servers in multiple physical locations requiring access to home directories, your design will need to reflect this. The result will be a much more complex design than if each of your users only connects to one MetaFrame XP server.
When placing home directories, you also need to consider whether users will be using them just from MetaFrame XP sessions or if users will need to access them from anywhere on the network.