As Chapter 26 demonstrates, one of the wonders of Windows Server 2003 is the Distributed File System (DFS) namespace. A DFS is a good idea for a company of any size, and living without one is hard after you apply it to a distributed company with file servers in many cities or even across multiple campuses.
The main hub for the mcity.us organization also supports a site in another town that has a busy file server, so we decided to build a DFS file system that spans both sites and provides a single file-system namespace to our users. After the DFS is built, as shown in Chapter 26, you can map your user's directory to folders in the namespace without needing to create hundreds of shares on the actual file servers. If you have recently escaped from a NetWare/NDS network, this section should pique your interest.
No matter where your user logs on, as long as you create a domain DFS, that user can map to a home folder and other folders as needed.
To set up the DFS and map users to a home folder in it, follow these steps:
1. Create a DFS root. This is done by opening the Distributed File System console under Administrative Tools, as shown in Chapter 26, and right-clicking Distributed File System to launch the New Root Wizard. Your DFS root is at the start, or root, of the folder branch containing all your users' home directories. The New Root Wizard takes you to the screen shown in Figure 27-16. Before you create the root name, add a dollar sign ($), as shown, to the end of the name to hide it on browse lists. After you have created the DFS root, you are done working on shares. All you need to do is map users to their folders on the namespace.
2. Create a simple batch file to be processed as a logon script. You can go to town with VBScript or JScript stuff, but for logon scripts, a simple batch (*.bat) file works (and you thought that DOS was dead). Figure 27-17 provides an example of a logon script to map users to home folders. (Note that you are not limited to batch language, and on Windows Server 2003, you can script this in more than 20 languages.)
3. Place the script, or batch file, in a share that all client computers can access. SYSVOL or NETLOGON are usually the safest bets. Make sure that your client computers can see the volumes whenever they authenticate to the domain or the script is not processed. Run the NET USE command at a client workstation to see what the client workstations are using on the server. The Shares folder in the File Server Management console, however, provides you with the server-side information, as shown in Figure 27-18.
4. The next job is to enable Group Policy for the users. Create a Group Policy Object to affect the users in the organizational unit to control and then open the Group Policy Object Editor to edit the object, as shown in Figure 27-19. Expand the User Configuration node through Windows Settings and Scripts (Logon/Logoff). (This process is described in detail in Chapter 14.)
5. Double-click Logon in the right-hand pane and enter the path to the logon script on the server, as shown in Figure 27-20. Remember to use a UNC path or your clients may think that they need to process a script that's sitting on their own hard-disk drives.
6. Save the policy. Now, whenever users in the OU are under the influence of the policy logon, their J drives are automatically mapped to the folder on the remote share.
Was this article helpful?