Designing and Deploying File Servers

Transcription

1 C H A P T E R 2 Designing and Deploying File Servers File servers rnning the Microsoft Windows Server 2003 operating system are ideal for providing access to files for sers in medim and large organizations. Windows Server 2003 offers a nmber of file server soltions, sch as Distribted File System (DFS), File Replication service (FRS), Windows server clsters, NTFS permissions, disk qotas, and shadow copies, for enhancing the manageability, scalability, availability, and secrity of file servers. In This Chapter Overview of Designing and Deploying File Servers Identifying File Services Goals Designing DFS Namespaces Planning File Server Availability Designing a Standard File Server Configration Planning File Server Secrity Deploying File Servers Additional Resorces Related Information For information abot installing and managing software applications by sing Grop Policy, see Deploying a Managed Software Environment in Designing a Managed Environment of this kit. For information abot managing ser desktops, settings, and data by storing data and settings on network servers, see Implementing User State Management in Designing a Managed Environment. For information abot server clsters, see Designing and Deploying Server Clsters in this book.

2 52 Chapter 2 Designing and Deploying File Servers Overview of Designing and Deploying File Servers File servers provide sers a way to access shared data within their department or organization. The simplest way to create a file server is to share a folder on a server. However, this soltion does not provide file server manageability, scalability, availability, or secrity. To achieve these goals, yo can deploy the following Windows Server 2003 soltions: Shadow copies If sers freqently reqire administrators to restore deleted or overwritten files from tape, shadow copies provide point-in-time copies of files in shared folders, allowing sers to recover files that were accidentally deleted or overwritten. DFS If sers need to access files on mltiple file servers withot having to keep track of all the server names, yo can se DFS to logically grop physical shared folders located on different servers by transparently connecting them to one or more hierarchical namespaces. DFS also provides falt-tolerance and load-sharing capabilities. FRS and Windows server clsters Windows Server 2003 provides two independent soltions, FRS and server clsters, to ensre that important bsiness data is always available, even if a server fails or is taken offline for maintenance. Disk qotas By sing the disk qotas featre in Windows Server 2003, yo can track files on a per-volme, per-ser basis to monitor disk space se and to prevent file servers from filling to capacity withot warning. NTFS permissions To prevent nathorized sers from accessing folders, yo can se NTFS file system permissions to specify the grops and sers whose access yo want to restrict or allow and then select the type of access. Yo can se the following information to design yor organization s file services. Or, if yor organization already has file servers rnning Microsoft Windows NT 4.0 or Microsoft Windows 2000 operating systems, yo can se the following information to improve the design of yor existing file services to take advantage of the new and enhanced featres in the Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition operating systems. File Server Design and Deployment Process Figre 2.1 otlines the general process of file server deployment. This process consists of a design phase and a deployment phase. A file services designer or design team performs the design process. The file services deployment team implements the design by deploying file servers rnning Windows Server 2003 and configring the file services soltions described in this chapter. Becase some featres of DFS and FRS reqire the Active Directory directory service, this process assmes that yor organization already has an existing Active Directory infrastrctre.

3 Overview of Designing and Deploying File Servers 53 Figre 2.1 Designing and Deploying a File Server File Services Design Team File Services Deployment Team Identify file services goals Design DFS namespaces Plan file server availability Design a standard file server configration Plan file server secrity Deploy file servers New and Enhanced File Server Featres in Windows Server 2003 The following sections smmarize the new and enhanced featres in Windows Server 2003 that are described in this chapter. Shadow copies The shadow copy featre provides point-in-time copies of files on a volme, allowing sers to view the contents of shared folders as they existed at points of time in the past. After yo enable this featre, sers can recover files that they accidentally delete or overwrite.

4 54 Chapter 2 Designing and Deploying File Servers DFS enhancements Windows Server 2003 incldes the following DFS enhancements: Yo can create mltiple DFS roots on servers rnning Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition. Yo can configre DFS to choose an alternate target based on the lowest connection cost if no same-site targets are available. Yo can se the Distribted File System snap-in to choose replication topologies that complement yor network infrastrctre. Yo can move a root target or a link target from one Active Directory site to another, and DFS will pdate the root or link information for the new site within 25 hors. To redce network traffic to the server acting as primary domain controller (PDC) emlator master, yo can configre DFS to get namespace pdates from the closest domain controller, instead of from the server acting as the PDC emlator master. This mode is known as root scalability mode. By sing the Offline Files featre, yo can make shared folders that correspond to DFS link targets available offline to clients rnning Microsoft Windows XP Professional and Windows Server (Yo cannot make DFS link targets available offline to clients rnning Windows 2000.) FRS enhancements Windows Server 2003 incldes the following FRS enhancements: FRS detects and sppresses excessive replication. FRS manages the staging directory to prevent it from becoming fll. FRS spports connection priorities, which allow yo to control the seqencing of the initial synchronization that occrs when yo add a new member to the replica set or when yo perform a nonathoritative restore, which is sed to bring a failed replica member back into synchronization with its partners. Secrity enhancements When yo share a folder, the defalt permission is the Read permission for the Everyone grop. This defalt is different from the defalt share permission in Windows 2000, which was the Fll Control permission for the Everyone grop. Server clster enhancements Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition inclde the following server clster enhancements: Yo can store encrypted files by sing Encrypting File System (EFS) on clster storage. Yo can create mltiple stand-alone DFS roots on a clstered file server, and the roots can reside on any of the nodes in the clster. Yo can enable client-side caching to cache files from a clster file share onto client compters. Clients can then access these files even when the client compter is disconnected from the network.

5 Identifying File Services Goals 55 Identifying File Services Goals Some of the major steps for designing and deploying file servers might not apply to yor organization. Therefore, the first step in the design process is to identify the goals that yo want to achieve by deploying file servers rnning Windows Server 2003, as shown in Figre 2.2. These goals determine the design and deployment steps that are necessary for yor organization. Figre 2.2 Identifying File Services Goals Identify file services goals Design DFS namespaces Plan file server availability Design a standard file server configration Plan file server secrity Deploy file servers The following sections describe common goals for file services. Use the information in these sections to identify the goals for yor organization and to find the relevant sections in this chapter or other sorces of information to help yo achieve those goals.

6 56 Chapter 2 Designing and Deploying File Servers Improving the way sers access files on file servers If yo want to improve how sers access files on file servers, yo might have the following goals: Providing an intitive way for sers to access mltiple file servers throghot the organization. Making data on mltiple file servers appear as thogh it were available on a single file server. Making data available in mltiple sites so that sers in each site se fast, inexpensive bandwidth to access the data. Redcing delays that occr when sers access heavily sed shared folders. Providing falt-tolerant access to shared folders. Consolidating file servers or migrating data withot affecting how sers locate data. For more information abot improving how sers access files on file servers, see Designing DFS Namespaces later in this chapter. Managing applications and ser data and settings If yo are managing applications, ser data, and settings, yo might have the following goals: Enabling sers to access files even when they are not connected to the network. Storing application files on file servers so that sers can install the applications from the network to their local workstations. Using Grop Policy based software management to deploy, pgrade, patch, and remove sers applications withot going to individal workstations. Allowing sers to rn applications from the file server. For more information abot managing applications and ser data and settings, see Implementing User State Management and Deploying a Managed Software Environment in Designing a Managed Environment of this kit. For more information abot hosting applications in a central location, see Hosting Applications with Terminal Server in this book. Adding storage to file servers If yo plan to add storage to file servers, yo might have the following goals: Transparently adding more storage to a file server. Making data on mltiple volmes or disks in a file server appear within a single volme or drive letter. Creating more than 26 volmes on a server withot being limited by the 26-drive letter limit. For more information abot adding storage to file servers, see Using NTFS monted drives in Help and Spport Center for Windows Server 2003.

7 Designing DFS Namespaces 57 Planning for file server availability and reliability If yo are planning for file server availability and reliability, yo might have the following goals: Choosing file server hardware for reliability and availability. Ensring data availability if a file server fails or is taken offline for maintenance. Making data available in mltiple sites to provide inexpensive access to sers within each site. For more information abot planning for file server availability and reliability, see Planning File Server Availability later in this chapter. Choosing file server hardware and settings If yo are choosing file server hardware and settings, yo might have the following goals: Choosing compatible file server hardware that meets yor performance and storage reqirements. Increasing file server performance. Consolidating file servers to redce management costs and increase storage allocation efficiency. Enabling sers to access previos versions of files on the file server. Monitoring and controlling disk space se. For more information abot choosing file server hardware and settings, see Designing a Standard File Server Configration later in this chapter. Planning for file server secrity If yo are planning for file server secrity, yo might have the following goals: Protecting file servers from virses. Preventing nathorized sers from accessing data on file servers. Allowing sers to store encrypted files on a file server. For more information abot planning for file server secrity, see Planning File Server Secrity later in this chapter. Designing DFS Namespaces Users might have difficlty finding information in shared folders that are located on nmeros file servers. Becase shared folders are sally associated with physical servers, the ser mst first determine which physical server is hosting the shared folder. For example, a ser might need to access prodct information on a server named \\Bilding 4\Marketing2\Prod_Info and on a server named \\Corporate\Floor 4\Sales\Prod_Info.

8 58 Chapter 2 Designing and Deploying File Servers Yo can se DFS to address this challenge by consolidating a large set of physical shared folders into one or more virtal namespaces. Yo do not need to modify the shared folders to add them to the namespace, and sers can navigate the namespace withot having to know the physical server names or shared folders hosting the data. Figre 2.3 otlines the general process of designing one or more DFS namespaces. For an Excel spreadsheet to assist yo in docmenting yor DFS namespace design decisions, see DFS Configration Worksheet (Sdcfsv_1.xls) on the Microsoft Windows Server 2003 Deployment Kit companion CD (or see DFS Configration Worksheet on the Web at Figre 2.3 Designing DFS Namespaces Identify file services goals Design DFS namespaces Plan file server availability Yes No Implement DFS? Choose the DFS namespace type Review DFS size recommendations End Design a standard file server configration Plan file server secrity Plan the nmber of DFS namespaces Develop root and link naming standards Deploy file servers Design a DFS namespace Increase the availability of DFS namespaces For more information abot DFS secrity, see Planning DFS and FRS Secrity later in this chapter. For in-depth technical and trobleshooting information abot DFS, see the Distribted Services Gide of the Microsoft Windows Server 2003 Resorce Kit (or see the Distribted Services Gide on the Web at

9 Designing DFS Namespaces 59 Deciding Whether to Implement DFS Organizations of any size, with any nmber of file servers, can benefit from implementing DFS. DFS is especially beneficial for organizations in which any of the following conditions exist: The organization plans to deploy additional file servers or consolidate existing file servers. The organization has data that is stored in mltiple file servers. The organization wants to replace physical servers or shared folders withot affecting how sers access the data. The organization has data located on servers in mltiple sites and wants clients to connect to the closest servers. Most sers reqire access to mltiple file servers. Users experience delays when accessing file servers dring peak sage periods. Users reqire ninterrpted access to file servers. Even if yo are bsy planning yor organization s migration to Windows Server 2003, yo can make plans to implement DFS withot immediately designing yor entire namespace. Yo do not need to deploy DFS all at one time; yo can choose to add as mch or as little of yor organization s physical storage as yo need to the DFS namespace, at a pace that works with yor overall migration schedle. When deciding whether to implement DFS, do the following: 1. Review DFS terminology. 2. Review the benefits of sing DFS. 3. Evalate clients and servers for compatibility. The following sections describe each of these steps. Reviewing DFS Terminology If yo are not familiar with DFS, review the following terms and definitions to nderstand the important elements of a DFS configration. For visal examples of these concepts, see Figre 2.4 throgh Figre 2.7 later in this section. DFS namespace A virtal view of shared folders on different servers as provided by DFS. A DFS namespace consists of a root and many links and targets. The namespace starts with a root that maps to one or more root targets. Below the root are links that map to their own targets. DFS root The starting point of the DFS namespace. The root is often sed to refer to the namespace as a whole. A root maps to one or more root targets, each of which corresponds to a shared folder on a separate server. The DFS root mst reside on an NTFS volme. A DFS root has one of the following formats: \\servername\rootname or \\domainname\rootname. Root target A physical server that hosts a DFS namespace. A domain-based DFS root can have mltiple root targets, whereas a stand-alone DFS root can only have one root target.

10 60 Chapter 2 Designing and Deploying File Servers Stand-alone DFS namespace A DFS namespace whose configration information is stored locally in the registry of the host server. The path to access the root or a link starts with the host server name. A stand-alone DFS root has only one root target. Stand-alone roots are not falt tolerant; when the root target is navailable, the entire DFS namespace is inaccessible. Yo can make stand-alone DFS roots falt tolerant by creating them on clstered file servers. Domain-based DFS namespace A DFS namespace that has configration information stored in Active Directory. The path to access the root or a link starts with the host domain name. A domain-based DFS root can have mltiple root targets, which offers falt tolerance and load sharing at the root level. DFS path Any Universal Naming Convention (UNC) path that starts with a DFS root. Link A component in a DFS path that lies below the root and maps to one or more link targets. Link target The mapping destination of a link. A link target can be any UNC path. For example, a link target cold be a shared folder or another DFS path. Figre 2.4 illstrates the elements of a stand-alone DFS namespace in the Distribted File System snap-in. These elements inclde a stand-alone DFS root, a single root target, and mltiple links. Figre 2.4 Elements of a Stand-Alone DFS Namespace Links Stand-alone DFS root Root target Figre 2.5 illstrates the elements of a domain-based DFS namespace in the Distribted File System snap-in. Notice that the \\Reskit.com\Pblic root has two root targets on different servers. Figre 2.5 Elements of a Domain-based DFS Namespace Links Domain-based DFS root Root targets

11 Designing DFS Namespaces 61 Figre 2.6 illstrates mltiple link targets for the Software link. Notice that the link targets exist on three different servers and that the administrator has disabled referrals to the link target on \\dfs-03. DFS will not refer clients to the link target on \\dfs-03 ntil the administrator enables referrals. Figre 2.6 Mltiple Link Targets Link targets The roots and links displayed in the Distribted File System snap-in also appear on each root server s local storage as follows: When yo create a DFS root, yo specify a shared folder to se as the root folder. If yo add mltiple root targets to a domain-based DFS root, yo specify a shared folder on each of those root targets. (The shared folder names shold always match the root name.) When yo add links to the root, DFS creates special folders nder each root folder. These folders, called link folders, are actally reparse points, and they display the following error message if yo try to access them on the local server: E:\Pblic\GropData is not accessible. The network location cannot be reached. Users who access the link folders from across the network are redirected to the appropriate link target. Figre 2.7 illstrates volme E:\ on the local storage of one of the root targets. The volme contains root and link folders for the \\Reskit.com\Pblic namespace. Figre 2.7 Root and Link Folders Link folders Root folder

12 62 Chapter 2 Designing and Deploying File Servers Reviewing the Benefits of Using DFS When yo evalate DFS for yor organization, it is helpfl to nderstand the benefits that yor organization can gain after designing and implementing a DFS namespace. The following list describes the benefits of sing DFS: Unified namespace A DFS namespace links together shared folders on different servers to create a hierarchical strctre that behaves like a single high-capacity hard disk. Users can navigate the logical namespace withot having to know the physical server names or shared folders hosting the data. Location transparency DFS simplifies migrating data from one file server to another. Becase sers do not need to know the name of each physical server or shared folder that contains the data, yo can physically move data to another server withot having to reconfigre applications and shortcts, and withot having to re-edcate sers abot where they can find their data. Storage scalability Yo can deploy additional or higher-performance file servers and present the storage on the new servers as new folders within an existing namespace. Namespace scalability Servers rnning Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition can host mltiple domain-based DFS roots and stand-alone DFS roots. This featre improves the scalability of DFS, enabling yo to bild many large namespaces withot having to add file servers to host the roots. Increased availability of file server data When mltiple servers rnning Windows Server 2003 host a domain-based DFS root, clients are redirected to the next available root server if any of these servers fail, providing falt-tolerant data access. To ensre the availability of stand-alone DFS namespaces, yo can create the root on a clstered file server. Alternate site selection based on cost By defalt, if a target in the same site as the sers fails, or if no same-site target exists, DFS refers clients to a random target. If yo configre the optional site costing featre, DFS can se the site information in Active Directory to locate an alternate target that has the lowest-cost network connection as defined by the administrator in the Active Directory Sites and Services snap-in. After site costing is enabled, clients can access data on DFS targets over the optimm network connection. Load sharing DFS provides a degree of load sharing by mapping a given logical name to shared folders on mltiple file servers. For example, sppose that \\Company\StockInfo is a heavily sed shared folder. By sing DFS, yo can associate this location with mltiple shared folders on different servers, even if the servers are located in different sites.

13 Designing DFS Namespaces 63 Intelligent client caching When a ser reqests access to a target that is a part of a DFS namespace, a referral containing the target s information is cached on the client. The next time the client reqires access to that portion of the namespace, the client ses the cached referral instead of obtaining a new referral, and connects directly to one of the target compters. For more information abot client caching in DFS, see the Distribted Services Gide of the Windows Server 2003 Resorce Kit (or see the Distribted Services Gide on the Web at Spport for offline folders If yor clients are rnning Microsoft Windows XP or Windows Server 2003, yo can make DFS link targets available offline by sing the Offline Files featre. Yo can also se this featre to atomatically cache programs so that sers can rn the programs locally instead of from the server. Using this featre for link targets that host applications can redce network traffic and improve server scalability. Simplified maintenance If a link has mltiple link targets, administrators can perform preventive maintenance, repairs, or pgrades on servers by disabling referrals to specific link targets. While the referral to the link target is disabled, DFS atomatically rotes new reqests to the remaining link targets that are online. Dynamic site discovery DFS now spports dynamic site discovery. In Windows 2000, DFS maintained static site information. After the site information for a particlar network resorce was known, DFS sed that information indefinitely, regardless of any changes in the site information of the resorce. In Windows Server 2003, when yo move a resorce from one site to another, the information sed by DFS converges to the new site information within 25 hors. Secrity integration Yo do not need to configre additional secrity for DFS namespaces, becase file and folder access is enforced by existing NTFS and share permissions on each link target. For example, a ser navigating a DFS namespace is permitted to access only the files or folders for which he or she has appropriate NTFS or share permissions. If yo se FRS to replicate content among mltiple targets, FRS also replicates access control lists (ACLs) for each file and folder. For more information abot DFS and FRS secrity, see Planning DFS and FRS Secrity later in this chapter. Evalating Client and Server Compatibility Before yo implement a DFS namespace, review the types of clients and servers in yor organization to make certain that the servers can host targets and that the clients can access targets in the DFS namespace. For example, if yo have UNIX clients, they cannot access the DFS namespace and mst instead access the files by sing the UNC path to the varios file servers. Table 2.1 smmarizes DFS interoperability.

14 64 Chapter 2 Designing and Deploying File Servers Table 2.1 DFS Interoperability Platform Act as DFS Clients? Host DFS Roots? Act as a Link Target? Microsoft Windows Server 2003, Web Edition Windows Server 2003, Standard Edition Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition Yes Yes Yes Yes. Can host one stand-alone DFS root or one domain-based DFS root per server. Yes. Can host one stand-alone DFS root or one domain-based DFS root per server. Yes. Can host mltiple stand-alone DFS roots and mltiple domainbased DFS roots per server. Windows XP Yes No Yes Windows Preinstallation Environment (WinPE) Microsoft Windows 2000 Server family * Microsoft Windows 2000 Professional Microsoft Windows NT Server 4.0 with Service Pack 6a Windows NT Workstation 4.0 with Service Pack 6a Yes No No Yes Yes, one stand-alone DFS root or domainbased DFS root per server. Yes Yes Yes Yes Yes No Yes Yes Yes, a single standalone DFS root per server. Yes Yes No Yes (contined)

15 Designing DFS Namespaces 65 Table 2.1 DFS Interoperability (contined) Platform Act as DFS Clients? Host DFS Roots? Act as a Link Target? Microsoft Windows Millenni m Edition (Me) Yes, client for stand-alone DFS inclded. Becase Windows Me is designed specifically for home se, no domain-based DFS client is provided. No Yes Microsoft Windows 98 Yes, client for stand-alone DFS inclded; install the Active Directory client extension for Microsoft Windows 95 or Microsoft Windows 98 to access domain-based DFS namespaces. No Yes * Applies to general-prpose servers and Windows Powered Network Attached Storage soltions rnning Windows Server Note The Active Directory client extension for Windows 95 or Windows 98 is available on the Windows 2000 operating system CD, or see the Active Directory Client Extensions link on the Web Resorces page at When evalating client compatibility, review the following important considerations: Clients mst be members of a domain before they can access a domain-based DFS namespace. Link targets can se other protocols, sch as NetWare Core Protocol (NCP) for NetWare and Network Filesystem (NFS) for UNIX, bt clients mst have the appropriate redirector installed to access those link targets. In organizations that have a large nmber of domains, clients might have difficlty accessing link targets in other domains or forests. In addition, clients rnning Windows 98 might not be able to access any domain-based DFS namespace and might also have difficlty accessing links that point to other DFS namespaces. For more information abot clients rnning Windows 98, see Designing a DFS Namespace later in this chapter. Choosing the DFS Namespace Type When creating a DFS namespace, yo create either a stand-alone DFS root or a domain-based DFS root. Table 2.2 describes the differences between domain-based DFS namespaces and standalone DFS namespaces.

16 66 Chapter 2 Designing and Deploying File Servers Table 2.2 How DFS Namespace Types Differ Characteristic Domain-based Stand-Alone Path to DFS namespace Grop memberships reqired to create and administer namespaces Where DFS root information is stored DFS namespace size restrictions Spported methods to ensre DFS root availability Spported methods to ensre link target availability \\domainname\rootname \\Netbiosdomainname\rootname \\DNSdomainname\rootname For DFS administrators who are not members of the Domain Admins grop, it is recommended that yo delegate permissions so that administrators can create new domain-based DFS namespaces. Administrators mst also be members of the local Administrators grop on each of the root targets to be able to add and delete links and add and remove the root targets. In Active Directory. DFS root information is replicated to all servers that host domain-based DFS roots. Large domain-based DFS namespaces might case significantly increased network traffic de to the size of the DFS Active Directory object. As a reslt, Microsoft recommends sing fewer than 5,000 links in domain-based DFS namespaces. Create mltiple DFS root targets in the same domain. Create mltiple link targets and replicate files by sing one of the following methods: Enabling FRS Copying files manally or by sing scripts Using a third-party replication tool \\servername\rootname DFS administrators mst be members of the local Administrators grop on the local server to create new stand-alone DFS roots and add or delete links. In the registry of the root server. The largest recommended namespace size for a stand-alone root is 50,000 links. Create a stand-alone DFS root on a clstered file server. Create mltiple link targets and replicate files by sing one of the following methods: Copying files manally or by sing scripts Using a third-party replication tool Note For information abot DFS namespace size restrictions, see Reviewing DFS Size Recommendations later in this chapter.

17 Designing DFS Namespaces 67 Use the following gidelines to choose a DFS namespace type. Choose stand-alone DFS namespaces if: Yor organization does not se Active Directory. Yo need to create a DFS namespace and are not part of the Domain Admins grop, or company policy prevents yo from delegating athority to manage a domain-based DFS namespace. Yo need to create a single namespace with more than 5,000 links. (If yo can divide yor links among two or more namespaces, domain-based DFS is an option.) Yo want to ensre the availability of the namespace by sing a clstered file server. Choose domain-based DFS namespaces if: Yo plan to se FRS to replicate data and yo want to se the Distribted File System snapin to configre and administer replication. Yo want to ensre the availability of the namespace by sing mltiple root targets. As described in Table 2.2, yo can increase the availability of roots and links in both types of DFS namespaces. For more information and specific gidelines abot increasing the availability of roots and links, see Increasing the Availability of DFS Namespaces later in this chapter. Reviewing DFS Size Recommendations As yo design yor DFS namespace, se the gidelines in Table 2.3 to avoid potential performance problems that can arise when size recommendations are exceeded. Table 2.3 DFS Size Recommendations Description Recommendation * Explanation Path limit Less than 260 characters Win32 application programming interfaces (APIs) have a maximm path limit of 260 characters, so applications will fail when trying to access a namespace that goes beyond that limit. If the path length of the DFS namespace exceeds the Win32 API limit of 260 characters, sers mst map part of the namespace to a drive letter and access the longer namespace throgh the mapped drive letter. Nmber of DFS roots per server rnning Windows Server 2003, Standard Edition One Windows Server 2003, Standard Edition is limited to one root per server. (contined)

18 68 Chapter 2 Designing and Deploying File Servers Table 2.3 DFS Size Recommendations (contined) Description Recommendation * Explanation Nmber of DFS roots per server rnning Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition Nmber of root targets per domain-based DFS root Nmber of links per DFS namespace Varies No fixed limit 5,000 for domainbased DFS 50,000 links for stand-alone DFS There is no limit to the nmber of DFS roots yo can create on a server rnning Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition. However, as yo increase the nmber of roots per server, the Distribted File System service takes longer to initialize and ses more memory. If yo do not enable root scalability mode, Microsoft recommends sing 16 or fewer root targets to limit traffic to the server acting as the primary domain controller (PDC) emlator master. When the nmber of links exceeds the recommended limit, yo might experience performance degradation when making changes to the DFS configration. For stand-alone DFS, namespace initialization after server startp might also be delayed. Size of each DFS Active Directory object (applies to domainbased DFS namespaces only) 5 megabytes (MB) The size of the DFS Active Directory object is determined by the nmber and path length of roots, links, comments, and targets in the namespace. Microsoft recommends sing no more than 5,000 links in a domain-based namespace to prevent the DFS Active Directory object from exceeding 5 MB. Limiting the size of the Active Directory object is important becase large domain-based DFS configrations can case significantly increased network traffic originating from pdates made to those roots, links, and targets. * The figres in this table are based on information gathered in a test environment. The nmbers in an operational DFS configration might exceed the nmbers described here and still provide acceptable performance. Note Yo can check the size of an existing DFS namespace by sing the following syntax in Dfstil.exe: dfstil /root:\\domainname\rootname /view (for domain-based DFS) dfstil /root:\\servername\rootname /view (for stand-alone DFS) The command otpt displays the nmber of links and, for domain-based DFS namespaces, the size of the DFS Active Directory object (described as blob size). If yor organization plans to create large namespaces, there are a nmber of strategies yo can implement to work within the size recommendations shown in Table 2.3.

19 Designing DFS Namespaces 69 Keep comments to a minimm When yo add a root target or link target in the Distribted File Systems snap-in, yo can enter comments that describe the target. If yo plan to create a large namespace, se minimal comments, if any, becase they can increase the overall size of the namespace. Note Comments are visible only within the DFS administration tools, and they are not visible to sers when they navigate the namespace. Create mltiple namespaces If yo need to create more than 5,000 links in a domain-based DFS namespace, yo can create mltiple DFS namespaces that meet the recommended sizes and then link them together. For more information abot creating mltiple namespaces, see Designing a DFS Namespace later in this chapter. Enable root scalability mode Yo enable root scalability mode by sing the /RootScalability parameter in Dfstil.exe, which yo can install from the \Spport\Tools folder on the Windows Server 2003 operating system CD. When root scalability mode is enabled, DFS root servers get pdates from the closest domain controller instead of the server acting as the PDC emlator master. As a reslt, root scalability mode redces network traffic to the PDC emlator master at the expense of faster pdates to all root servers. (When yo make changes to the namespace, the changes are still made on the PDC emlator master, bt the root servers no longer poll the PDC emlator master horly for those changes; instead, they poll the closest domain controller.) With this mode enabled, yo can have as many root targets as yo need, as long as the size of the DFS Active Directory object (for each root) is less than 5 MB. For more information abot the 5-MB limit, see the entry describing the size of the DFS Active Directory object in Table 2.3 earlier in this chapter. Do not se root scalability mode if any of the following conditions exist in yor organization: Yor namespace changes freqently, and sers cannot tolerate having inconsistent views of the namespace. Domain controller replication is slow. This increases the amont of time it takes for the PDC emlator master to replicate DFS changes to other domain controllers, which, in trn, replicate changes to the root servers. Until this replication completes, the namespace will be inconsistent on all root servers. Note After yo enable root scalability mode in a mixed domain, root servers rnning Windows Server 2003 can obtain pdates from the closest domain controller; however, root servers rnning Windows 2000 Server still obtain pdates from the PDC emlator master. For information abot installing Windows Spport Tools, see Install Windows Spport Tools in Help and Spport Center for Windows Server 2003.

20 70 Chapter 2 Designing and Deploying File Servers Migrate root servers rnning Windows 2000 Server to Windows Server 2003 Root servers rnning Windows Server 2003 do not add site information to the DFS Active Directory object. As a reslt, if all root servers rn Windows Server 2003, DFS can store more root and link information to the DFS Active Directory object before reaching the recommended 5-MB limit. For more information abot sing a mix of root servers rnning Windows 2000 Server and Windows Server 2003, see Designing a DFS Namespace later in this chapter. Planning the Nmber of DFS Namespaces Yor next step is to plan the nmber of namespaces yo want in yor domain. For an Excel spreadsheet to assist yo in docmenting yor namespace decisions, see DFS Configration Worksheet (Sdcfsv_1.xls) on the Windows Server 2003 Deployment Kit companion CD (or see DFS Configration Worksheet on the Web at Medim organizations might reqire only a single namespace, while large organizations might need mltiple DFS namespaces. Yo can determine the nmber of namespaces yo reqire by reviewing the following factors. Scope of yor domain If yor domain has a broad scope geographically, organizationally, or fnctionally yo shold plan for mltiple DFS namespaces so that administrators in the geographical, organizational, or fnctional departments can define their own namespaces. On the other hand, if the domain has a narrow scope geographically, organizationally, or fnctionally, yo might want to define a single DFS namespace. Size of yor DFS namespace If yor DFS namespace exceeds the recommended nmber of links per namespace, as discssed earlier in Reviewing DFS Size Recommendations create mltiple DFS namespaces, each of which does not exceed the recommended size. In this way, yo can provide a single namespace to sers by creating a single DFS namespace with links that point to other DFS namespaces. For more information abot linking from one namespace to another, see Designing a DFS Namespace later in this chapter.

21 Designing DFS Namespaces 71 Administrative bondaries How DFS namespaces are administered can also affect the nmber of DFS namespaces yor organization reqires. For example, yor organization might have the following administrative bondaries: Geographic. Geographically diverse sites can each have an administrator who creates and manages the DFS namespace located in that site. Departmental or grop ownership. Individal departments or grops can create and manage a DFS namespace that is sed by members of that department or grop. Political. Individal departments or grops can create and manage a DFS namespace that is sed by members of that department or grop. If grops in yor organization will create and manage their own DFS namespaces, yo can bild an extensive DFS namespace ot of smaller, more focsed DFS namespaces. One benefit of this method is that yo can present specific DFS roots to some sers as the tre top of the hierarchy and also present a set of those DFS roots to other sers as the only DFS links in a larger hierarchy. By sing a hierarchy of DFS roots, yo can scale the namespace as yor organization grows and tailor the namespace for distribted management. For more information abot linking from one namespace to another, see Designing a DFS Namespace later in this chapter. DFS namespace depth Limit the depth of DFS namespaces to 260 characters. The 260-character limit incldes the flly qalified domain name (FQDN) of the domain hosting the DFS root as well as the DFS root name. If yo exceed this limit, applications will fail when trying to access the namespace. To work arond this isse, sers mst map part of the namespace to a drive letter and then access the longer namespace throgh the mapped drive letter. Developing Root and Link Naming Standards When yo roll ot DFS, yo have the opportnity to implement consistent namespace designs. Developing naming standards first and ensring that yo adhere to the naming standards dring implementation makes it easier to se and manage any DFS namespace, both from a ser perspective and an administrative perspective. Even if yo do not expect to implement DFS ntil a later phase of yor Windows Server 2003 deployment, it is important to begin thinking abot namespace design early in the planning process. For an Excel spreadsheet to assist yo in docmenting yor DFS namespace design decisions, see DFS Configration Worksheet (Sdcfsv_1.xls) on the Windows Server 2003 Deployment Kit companion CD (or see DFS Configration Worksheet on the Web at

22 72 Chapter 2 Designing and Deploying File Servers Creating DFS Root Names A DFS root name, significant primarily to sers, is the point beyond the server name or domain name that is at the top of the hierarchy of the logical namespace. Standardized and meaningfl names at this level are very important, especially if yo have more than one DFS namespace in a domain, becase the DFS root name is where sers enter the namespace. The contents of a DFS namespace mst be as clear as possible to the sers so that they do not follow the wrong path, possibly across expensive WAN connections, and have to backtrack. When creating the DFS root names for servers that will contain mltiple roots, review the following restrictions: Each root reqires its own shared folder. When yo create a domain-based DFS root, the share name in the UNC path \\servername\sharename mst be the same name as the DFS root name in \\domainname\rootname. For example, if yo want to create a domain-based DFS root \\Reskit.com\Pblic on Server1, the UNC path to the shared folder mst be \\Server1\Pblic. A root cannot be nested within another root. For example, if C:\Root is a shared folder that ses the share name Pblic, and yo se this shared folder as a stand-alone DFS root (\\servername\pblic) or domain-based DFS root (\\domainname\pblic), yo cannot create another root in the folder C:\Root\Software. Similarly, if yo create a root by sing the root folder C:\, yo cannot create another root at C:\Root. On server clsters, do not create clstered DFS roots that have the same name as nonclstered DFS roots or shared folders. Shared folders on domain controllers mst not have the same name as any domain-based DFS roots in the domain. If they do, clients who try to access the shared folder on the domain controller are redirected to the domain-based DFS root. For example, if Reskit.com has a domain controller named DC1 that contains a shared folder named Tools (\\DC1\Tools), do not create a domain-based DFS namespace sing a root named Tools (\\Reskit.com\Tools). Otherwise, when sers attempt to access \\DC1\Tools, they are redirected to \\Reskit.com\Tools.

23 Designing DFS Namespaces 73 Creating DFS Link Names A DFS link is a component in a DFS namespace that lies below the root and maps to one or more link targets. Becase DFS link names are exposed to sers, it is important to develop standardized, meaningfl names for DFS links. Another important design goal is to develop a DFS namespace that provides intitive navigation within the hierarchy that the namespace represents. Keep in mind that comments entered in the Distribted File System snap-in are not visible to sers. For this reason, the namespace mst be as clear as possible at all levels. Designing a clear naming scheme is even more important for a DFS namespace than for a physical namespace, becase a ser might jmp to a shared folder on a different file server when he or she selects a link in the DFS namespace. As a reslt, a session has to be set p with that physical server (if one does not already exist), which might delay access. Therefore, yo want to minimize the nmber of times that sers traverse a wrong path. Clear and meaningfl naming standards can help. Try to keep links at the same level in the DFS namespace consistent in context. For example, yo probably wold not want to have links named New York, Seattle, and Milan mixed with other links named Sales, Marketing, and Conslting. To help yo create a consistent namespace, DFS spports adding one or more folder names to the link name so that yo can create a meaningfl hierarchy of link names. In the previos example, yo cold create links sch as the following: Branches\New York, Branches\Seattle, and Branches\Milan Departments\Sales, Departments\Marketing, and Departments\Conslting When sers browse this namespace, they will see a folder called Branches and another called Departments, which they can se to navigate to folders for branch offices (New York, Seattle, and Milan) and departments (Sales, Marketing, and Conslting). Note If yo want to encorage sers to access the DFS namespace instead of going to individal servers, yo can se a dollar sign ($) at the end of the shared folder name to hide it from casal browsers. The shared folder will still appear in the DFS namespace with the link name yo specify. Doing so prevents sers from accessing the shared folders by specifying individal server names. Instead, sers mst access the shared folders by sing the namespace, which enables DFS to load share reqests across mltiple link targets and allows clients to be directed to another link target if the previosly sed target is navailable. Designing a DFS Namespace As yo design one or more DFS namespaces for yor organization, yo need to make a nmber of decisions abot the strctre and capacity of the namespaces. For an Excel spreadsheet to assist yo in docmenting yor DFS namespace decisions, see DFS Configration Worksheet (Sdcfsv_1.xls) on the Windows Server 2003 Deployment Kit companion CD (or see DFS Configration Worksheet on the Web at

24 74 Chapter 2 Designing and Deploying File Servers Determining Who Can Manage the Namespace Yo can delegate administrative athority to individal sers so that they can manage a DFS namespace. Table 2.4 describes the permissions and grop memberships that yo mst delegate before sers can manage a namespace on a member server. Administering DFS namespaces on a domain controller or configring FRS replication reqires membership in the Domain Admins grop. Table 2.4 Permissions or Grop Memberships Reqired to Administer DFS Namespaces Task Creating or removing a domainbased DFS root on a member server. Adding or removing a root target from an existing domain-based DFS root on a member server. Creating or deleting a stand-alone DFS root on a member server. Adding a link to a domain-based DFS namespace or adding a target to an existing link on a member server. Removing a link from a domainbased DFS namespace or removing a target from an existing link on a member server. Changing root-related or linkrelated information, sch as comments, referral stats, and cache limits on a member server. Performing any of the tasks in this table on a domain controller. Enabling replication on links in a domain-based DFS namespace. Permissions or Grop Membership Reqired One of the following: Membership in the Domain Admins grop. Fll Control permission on the DFS-Configration container in Active Directory and membership in the local Administrators grop on the root server. One of the following: Membership in the Domain Admins grop. Fll Control permission on the DFS-Configration container in Active Directory and membership in the local Administrators grop on the root server. Membership in the local Administrators grop on the root server. Membership in the local Administrators grop on each of the root target servers. Membership in the local Administrators grop on each of the root target servers. Membership in the local Administrators grop on each of the root target servers. Membership in the Domain Admins grop. Membership in the Domain Admins grop.

25 Designing DFS Namespaces 75 Yo can also limit delegated athority to jst one domain-based DFS namespace on a member server by granting a ser or grop Fll Control permission on the DFS root object contained in the DFS-Configration container. Doing so allows the administrator to add or remove root targets from a specific namespace. For more information abot how to delegate permission to manage a DFS namespace, see Deploying DFS later in this chapter. Selecting Servers to Host Roots Table 2.5 describes the gidelines for servers hosting stand-alone DFS roots and domain-based DFS roots. Table 2.5 Gidelines for Servers That Host DFS Roots Server Hosting Stand-Alone DFS Roots Server Hosting Domain-based DFS Roots Mst contain an NTFS volme to host the root. Can be a member server or domain controller. Can be a general-prpose server or Windows Powered Network Attached Storage. Mst contain an NTFS volme to host the root. Mst be a member server or domain controller in the domain in which the DFS namespace is configred. (This reqirement applies to every root target for a given domain-based DFS namespace.) Can be a general-prpose server or Windows Powered Network Attached Storage. Can be a clstered file server. Cannot be a clstered file server nless yo host the domain-based DFS root on the local storage of a node in the server clster. The following sections provide other factors to consider when selecting root servers. Restrictions for servers rnning Windows Server 2003, Standard Edition If yo are sing servers rnning Windows Server 2003, Standard Edition, yo can create only one DFS root per server, which means that yo need one server for each root yo plan to host. Root servers that have the RestrictAnonymos registry vale Before yo create a DFS root on a server, verify that the RestrictAnonymos registry vale is not set on the server. This registry vale restricts anonymos access and cases DFS referral failres. For more information abot this registry vale, see Planning DFS and FRS Secrity later in this chapter.