Microsoft Windows Server File Services

The Planning and Design Series Approach

This guide is one in a series of planning and design guides that clarify and streamline the planning and design process for Microsoft® infrastructure technologies.

Each guide in the series addresses a unique infrastructure technology or scenario. These guides include the following topics:

  • Defining the technical decision flow (flow chart) through the planning process.
  • Describing the decisions to be made and the commonly available options to consider in making the decisions.
  • Relating the decisions and options to the business in terms of cost, complexity, and other characteristics.
  • Framing the decision in terms of additional questions to the business to ensure a comprehensive understanding of the appropriate business landscape.

The guides in this series are intended to complement and augment the product documentation. It is assumed that the reader has a basic understanding of the technologies discussed in these guides. It is the intent of these guides to define business requirements, then align those business requirements to product capabilities, and design the appropriate infrastructure.

Benefits of Using This Guide

Using this guide will help an organization to plan the best architecture for the business and to deliver the most cost-effective Windows Server® 2008 File Services technology.

Benefits for Business Stakeholders/Decision Makers:

  • Most cost-effective design solution for an implementation. IPD eliminates over-architecting and over-spending by precisely matching the technology solution to the business needs.
  • Alignment between the business and IT from the beginning of the design process to the end.

Benefits for Infrastructure Stakeholders/Decision Makers:

  • Authoritative guidance. Microsoft is the best source for guidance about the design of Microsoft products.
  • Business validation questions to ensure the solution meets the requirements of both business and infrastructure stakeholders.
  • High integrity design criteria that includes product limitations.
  • Fault tolerant infrastructure, where necessary.
  • Proportionate system and network availability to meet business requirements.
  • Infrastructure that is sized appropriately to meet business requirements.

Benefits for Consultants or Partners:

  • Rapid readiness for consulting engagements.
  • Planning and design template to standardize design and peer reviews.
  • A "leave-behind" for pre- and post-sales visits to customer sites.
  • General classroom instruction/preparation.

Benefits for the Entire Organization:

Using this guide should result in a design that will be sized, configured, and appropriately placed to deliver a solution for stated business requirements, while considering the performance, capacity, manageability, and fault tolerance of the system.

Introduction to the Windows Server 2008 File Services Guide

Well-designed file services infrastructures form the basis for productive computing in many organizations, providing fast, reliable, and secure access to file resources while protecting important data in the event of a disaster. File services is a critical infrastructure component in enabling and increasing the productivity of both business and IT workers.

A Windows Server 2008 File Services infrastructure can consist of one or more of the following:

  • File servers
    • BranchCache® (optional)
  • File replication (optional)
  • A file services namespace such as the Distributed File System (DFS) (optional)

    This guide leads the reader through the process of determining the business requirements for file access and storage and surveying the current file serving infrastructure. The results are then used to create a design providing file access and storage that is consistent with, and optimized for, the business requirements.

    The guide can be used to develop the file services infrastructure design for multiple projects by repeating the steps for each type of project, for example, location, business groups, or department.

    What's New in Windows Server 2008 R2

    This guide's design process is valid for both Windows Server 2008 and Windows Server 2008 R2 environments.

    Windows Server 2008 R2 introduces new functionality and enhancements to Windows® file services that provide improved performance, increased reliability, and greater flexibility for users, including the following:

    • BranchCache
    • Support for Distributed File System Replication in failover clusters
    • Read-only DFS Replication replicas
    • File Classification Infrastructure (FCI)

    For more details on the changes, see http://technet.microsoft.com/en-us/library/dd391932(WS.10).aspx.

    Assumptions

    This guide assumes that file services are in use in the target organization since it is rare that some level of file services is not already implemented. The guide considers areas that must be addressed during the design process in order to accommodate existing data. This guide also assumes that services such as namespace and replication are not already in use and must be planned.

    All tasks and decisions covered in this guide assume that Windows Server 2008 (or Windows Server 2003, at a minimum) is installed and providing File Services for the organization. In addition, Active Directory® directory service, Group Policy, Domain Name System (DNS), and Dynamic Host Configuration Protocol (DHCP) are all implemented and operating normally. For additional information on proper design and planning of these services, please refer to the appropriate guide in the Infrastructure Planning and Design Series.

    Windows Server 2008 File Services Design Process

    The goal of this guide is to present common scenarios, decisions, and practices for implementing a Windows Server File Services infrastructure. File Services is a mature technology and is often underemphasized in infrastructure planning. As a result, file infrastructures often grow in piecemeal fashion, never really receiving the benefit of a holistic, bottom-up approach to planning. This can result in issues with data protection and disaster recovery, a lack of storage optimization, and even a significant business impact due to data loss.

    Using this guide, IT professionals can plan, design, and implement a File Services infrastructure that ensures that critical phases of the plan are not left out and that a good foundation is established for future expansion.

    This guide addresses the following decisions and/or activities that need to occur in preparing for a Windows Server 2008 File Services implementation. The six steps below represent the most critical design elements required for achieving a well-planned Windows Server 2008 File Services design:

    • Step 1: Determine the Scope of the File Services Project
    • Step 2: Determine the Files, Servers, and Clients That Will Be Included
    • Step 3: Assess the Need for Replication or Caching
    • Step 4: Design the BranchCache Infrastructure
    • Step 5: Design the DFS Replication Infrastructure
    • Step 6: Design the File Services Infrastructure
    • Step 7: Determine Whether Namespace Services Will Be Required

    Some of these items represent decisions that must be made. Where this is the case, a corresponding list of common response options will be presented.

    Other items in this list represent tasks that must be carried out. These types of items are addressed because their presence is significant in order to complete the infrastructure design.

    Figure 1 provides a graphical overview of the steps in designing a Windows Server 2008 File Services infrastructure.

    Figure 1. The Windows Server 2008 File Services infrastructure decision flow

    Applicable Scenarios

    This guide addresses considerations that are related to planning and designing the necessary components for a successful Windows Server 2008 File Services infrastructure:

    • Implementation of new compliance requirements.
    • Redesigning all or part of the infrastructure for better efficiency.
    • Consolidating the file systems of an acquisition after a merger.
    • Consolidating duplicate and near-duplicate file systems.
    • Newly isolated file systems, set up because of regulatory requirements.

    Out of Scope

    The following list of file sharing systems and services is out of scope for this discussion of Windows Server 2008 File Services:

    • Supporting flat file or relational databases in Windows Server File Services.
    • Microsoft Office Groove® 2007 and Microsoft Office Groove Server 2007 file sharing services.
    • Microsoft Office SharePoint® Server 2007.
    • File sharing through use of HTTP servers such as Microsoft Internet Information Services (IIS).
    • File sharing through use of File Transfer Protocol (FTP) services.
    • Support for UNIX Network File System (NFS) clients through Services for NFS.
    • Any other peer-to-peer or hardware-based file sharing technology.
    • Rights Management Services (RMS) design for File Classification Infrastructure. (For more information, see www.microsoft.com/windowsserver2008/en/us/fci.aspx.)

    Step 1: Determine the Scope of the File Services Project

    The focus of this step is to understand and clearly define the goals of the project so that these can be applied to the design to ensure its applicability and success. This is the opportunity to align business needs with the infrastructure design.

    Following are some goals, or business drivers, that might result in a File Services redesign:

    • New corporate security requirements. Changing security requirements can lead to a need to reorganize data in file systems and to a new security design.
    • New compliance requirements (Health Insurance Portability and Accountability Act (HIPAA), Sarbanes–Oxley (SOX), and so on). Security and encryption will be important in a project to address privacy or security requirements.
    • Performance issues. Poorly performing File Services can drive a redesign. Pay particular attention to server sizing and performance.
    • Corporate merger or acquisition. Take into account potential storage and server sizing requirements brought about by a need to consolidate File Services resources as part of a merger.

    By clearly understanding the motivation behind the File Services project, appropriate priorities can be established for the planning steps.

    Although all of the principles used in this guide are applicable to a new infrastructure, the guide has been created with the assumption that some existing file services infrastructure is already in place.

    The output from this step will be used in Step 2 to define which files, servers, and clients will be included in the project, and in Step 6 to design the new file services infrastructure.

    Task 1: Determine the Scope of the Project

    Understanding the full extent of the work to be performed enables the designer to begin visualizing the tasks and roles that will be needed to successfully implement the infrastructure plan.

    Record information that defines the overall scope of the project in Table A-1 in Appendix A: "Job Aids":

    • Which parts of the organization will be participating.
    • Which geographic areas will be included.

    Validating with the Business

    To confirm the project scope, the requirements of the business need to be thoroughly understood. Work with business stakeholders to answer the following questions:

    • Have all the regulatory requirements been recognized and included in the project scope? Compliance with government regulations (for example, HIPAA, SOX, and so on) often includes requirements for encryption or more stringent security.
    • What are the commitments to uptime and metrics for performance and recovery that have been agreed to by business and IT stakeholders? Many organizations use service level agreements (SLAs) and operational level agreements (OLAs) to define services one department provides to another.

    Before launching the planning phase of the project, share the scope information with business stakeholders. Verify that the proposed project scope is acceptable to the business and that business stakeholders are agreeable to the timelines and to their own responsibilities, if any.

    Step Summary

    In this step the goals of the project were defined and recorded in Table A-1 in Appendix A: "Job Aids" so that they can be applied to the design in the following steps. By clearly understanding the motivation behind the File Services project, appropriate priorities can be established in those steps.

    The output from this step will be used in Step 2 to define which files, servers, and clients will be included in the project, and in Step 6 to design the new File Services infrastructure.

    Step 2: Determine the Files, Servers, and Clients That Will Be Included

    Now that the business drivers and scope of the project have been determined, they can be used to assess the current infrastructure and to define the scope of any redesign that might be required to accomplish the goals of the File Services project. Evaluating the current File Services infrastructure will usually lead to insights into what works well and what can be improved. This will also ensure that no relevant details are left out and will avoid unnecessary work later.

    The goal of this step is to identify, within the scope of the project that was determined in Step 1:

    • The location, size, and type of files in the existing File Services infrastructure.
    • The servers that currently host these file resources.
    • Any special needs that may affect the design, such as file encryption.

    Once completed, this information should be shared with business stakeholders to validate their special needs and to help prioritize business requirements for the File Services infrastructure.

    The inventory collected in this step will be used in Step 6 to design the file services infrastructure.

    Task 1: Collect an Inventory of File Server Resources

    To ensure that all factors are taken into account, it is important to collect information about the current file storage environment, including locations where files are stored and the total storage used in each location. This will help the planner to optimize server placement, select between storage technologies, and design the network for appropriate throughput.

    Collect the following information for each server in each location and record it in Table A-2 in Appendix A:

    • Server storage capacity (used and free). This will be used in Step 6 to determine whether additional capacity may be required.
    • Any use of encryption. File encryption creates additional processing overhead, so this will be compared with encryption requirements in Step 1 to determine whether any existing encryption could be disabled in order to free server resources. It will also be used to check that the current level of encryption is sufficient to meet business requirements.
    • Whether any of the files on the server are currently being replicated. This will be used in the design of file replication in Step 5.
    • Whether Distributed File System namespaces are in use. This will be used in the design of the DFS namespace in Step 7.
    • Presence of shadow copies. Shadow copies allow users to restore files that they have deleted.
    • Implementation of fault tolerance, such as file server clustering. In Step 6, this will be compared with the requirements for fault tolerance and be used to design fault tolerance into the file serving infrastructure, if necessary.
    • Number of clients to which files are being served at any given time. In Step 6, this will be compared with the population of concurrent clients that will be assigned to each server in order to determine whether any of the clients should be reassigned to different server resources.
    • Locations of clients accessing the files. A comprehensive list of where the users are that access each file would be cumbersome to build, but if there are general grouping of files, like a departmental share of files that are accessed by users in particular locations, record the locations of the users in the department that access the share.
    • Other workloads running on the file server, and how much of the server resources they consume. This can be used in the redesign to determine whether some of those workloads should be transferred to other resources in order to avoid impact on the file serving workload.

    Step Summary

    The current File Services infrastructure was assessed in this step in order to define the scope of any redesign that might be required to accomplish the goals of the project. The following infrastructure components were identified and recorded in Table A-2 in Appendix A: "Job Aids":

    • The location, size, and type of files in the existing File Services infrastructure.
    • The servers that currently host these file resources and locations of the users.
    • Any special needs that may affect the design, such as file encryption.

    This information was then shared with business stakeholders to validate their special needs and to help prioritize business requirements. It will be used in Step 6 to design the File Services infrastructure.

    Step 3: Assess the Need for Replication or Caching

    In the previous step, the current File Services infrastructure was assessed in order to define the scope of any redesign that might be required, and to help prioritize business requirements. Infrastructure data such as location, size, and types of files were identified and recorded.

    In this step, inventory collected in Step 2 will be examined to determine whether replication or caching may be needed. This process will need to be iterated for each group of files accessed by each location.

    In large organizations that have branch offices located around the world, users in one branch office often need access to shared folders and files stored at another branch, hub office, or data center. Replication and caching can facilitate local, high-speed access to files for clients in locations where they would otherwise have to access the files over a slower, wide area network (WAN) link. Both methods have different advantages and disadvantages that will be discussed in this step.

    DFS Replication replicates a folder scope defined by the replicated folder path. The set of computers participating in replication is defined by a configured topology of connections and is called a replication group. Multiple replicated folders can be included in a replication group, with memberships selectively enabling or disabling specific replicated folders.

    Replication offers the following benefits:

    • Ensures the availability of files during WAN outages or server failures.
    • WAN usage for synchronization can be scheduled and throttled.
    • Works with non-Windows 7 clients.

    Replication has the following limitations:

    • Requires a local server with sufficient disk space to store the entire replica.
    • Involves more configuration than caching, as the replication topology will need to be designed.

    With DFS Replication, all files will be available in the targeted locations. Maintaining replicas of data increases costs because of the additional storage infrastructure that must be deployed to hold them and the additional network bandwidth required to maintain synchronization between the replicas. It is important to work with the business to understand the value of replication so that it can be measured against the costs.

    Another method that administrators can use to reduce WAN utilization and enhance responsiveness is a new feature in Windows Server 2008 R2 called BranchCache. When BranchCache is enabled, a copy of the content that is retrieved from the file server is cached within the branch office. If another client in the branch requests the same content, the client is authenticated and authorized by the content server, which delivers a metadata hash of the file. The client then downloads the content directly from the local branch network cache, reducing the WAN bandwidth utilization. The size of the BranchCache metadata is approximately 2,000 times smaller than the size of the original data. The minimum size of content that BranchCache would cache is 64 kilobytes (KB). When content is less than 64 KB, data is directly retrieved from the content server by using the WAN.

    BranchCache offers the following benefits:

    • Simpler to configure than DFS Replication, as the BranchCache role is added to the content server, the properties of the share set to allow caching, and then the cache space defined on the local server or clients (which can be done via Group Policy).
    • Disk space usage for the cache can be limited to a percentage of the disk space.

    BranchCache has the following potential drawbacks:

    • Requires Windows Server 2008 R2 and Windows 7 clients.
    • There is a delay in the first and/or second request (depending on the content type) for the clients at a branch.
    • If the WAN line is down, the clients will be unable to authenticate to the original content server, and will receive an error when requesting the file, even if the file is cached locally.

    It is important to keep in mind as the tasks are completed in this step that a combination of DFS Replication and BranchCache may be the optimal solution for an organization. For example, if replication is used, synchronize files between a headquarters and branch office. The results would be that a satellite office would have a BranchCache implementation to facilitate quicker access to recently used files, without the storage requirements of a full replica.

    Task 1: Determine Whether Replication Is Required

    In replication, copies of each file are kept on multiple servers. Replication may be necessary for:

    • Fault Tolerance. As copies of each file exist on more than one server, there is a level of protection against an outage from a specific server or the WAN link going down. However, it is important to note that if a user inadvertently deletes a file, this deletion action will be repeated automatically on the replica members.
    • Increased performance. Local replicas of files can enhance file access responsiveness to users.
    • Bandwidth optimization. As users are able to access local copies of files, the bandwidth utilization of the WAN may be decreased. However, during replication network traffic might be higher.

    If low latency and data availability during WAN outages is worth the tradeoff of network traffic and disk space used in the branch office, administrators can use DFS Replication to replicate files between branch servers, providing users fast access to files in their respective branches.

    For each group of files accessed by users at each branch, determine whether replication is required, and record the answer in Table A-2 in Appendix A: "Job Aids."

    Task 2: Decide Whether to Use BranchCache

    BranchCache may be desirable to implement to:

    • Increase performance in certain cases. Requests for the same file will be faster for subsequent requests as the file can be returned from the local cache, making the file access for responsive for users.
    • Optimize bandwidth in certain cases. As some requests may be able to be served from the local cache bandwidth, utilization may be decreased.

    However, BranchCache does not guarantee file access during outages and requires the WAN line to be operational, even if requesting a previously cached file.

    Review the inventory of files collected in Table A-2 in Appendix A and determine if there are clients in remote locations that are valid candidates for the caching provided by BranchCache. Record the answer in Table A-2 in Appendix A.

    Step Summary

    In this step, the file system inventory was assessed for grouping of files and locations that might require replication for fault tolerance, performance, or bandwidth optimization. It was then determined whether there were locations that would benefit from using BranchCache, a feature of Windows 7 and Windows Server 2008 R2.

    In the next steps, the infrastructure for BranchCache and DFS Replication will be designed.

    Additional Reading

    • File Services: http://technet.microsoft.com/en-us/library/cc771548(WS.10).aspx
    • "An Overview of Windows Clustering Technologies: Server Clusters and Network Load Balancing": http://technet.microsoft.com/en-us/library/cc739634(WS.10).aspx

    Step 4: Design the BranchCache Infrastructure

    In the previous step, it was determined whether replication or caching will be needed. If it was decided that BranchCache will be used to facilitate file access for remote users, this step will determine the appropriate mode of BranchCache for each branch and the design of the infrastructure.

    BranchCache reduces the network utilization on WAN segments that connect branch offices by locally caching frequently used files in the branch office. The cache can be distributed across client computers (distributed cache mode) or can be housed on a server (hosted cache mode).

    With BranchCache, only files that have been previously requested by a client in the branch office will have the file returned from the BranchCache. The initial request will return the file from the content server over the WAN link, and then subsequent requests for the same file from clients at the branch will be returned from the locally cached copy. The locally cached copy is read-only, but changes to the file will be saved back across the WAN link on the original source server.

    Windows Server 2008 R2 and Windows 7 clients are required for BranchCache.

    Task 1: Select BranchCache Mode

    In this task, choose the appropriate BranchCache mode. Depending on where the cache is located, BranchCache can operate in one of two modes:

    • Hosted. In hosted cache mode, cached content is maintained on a computer that is running Windows Server 2008 R2 as a host on the remote office network. Clients are configured with the fully qualified domain name of the host computer so that they can retrieve content from the Hosted Cache, when available. If the content is not available in the Hosted Cache, it is retrieved from the original content server by using the WAN and then offered to the hosted Cache so that subsequent clients can benefit. The BranchCache role can be enabled on a server that is also running other workloads, on either a physical or virtualized server.

      BranchCache is compatible with virtual private network (VPN) software that supports split tunneling.

    • Distributed. In distributed mode, local Windows 7 clients keep a copy of the content and make it available to other authorized clients that request the same data. This eliminates the need to have a server in the branch office. However, unlike Hosted Cache mode, this configuration works across a single subnet only (that is, the content has to be retrieved once per subnet in the branch office by using the WAN). In addition, clients that hibernate or otherwise disconnect from the network are not able to provide content to requesting clients. Distributed Cache mode is best suited for branch offices with fewer than 50 users. No infrastructure or services are required in the branch office beyond client computers running Windows 7.

    Note that a client computer can be configured to use only a single caching mode at a time.

    The decision relative to which mode to implement BranchCache in may depend on what infrastructure is already in place at the branch. If a Windows Server 2008 R2 server is already present at the branch, and has unused drive space to support a cache, then enabling BranchCache on the server may be appropriate. Otherwise, other client computers in the branch may be used for the cached content.

    For each remote office location, record the BranchCache mode chosen in Table A-3 in Appendix A: "Job Aids."

    Task 2: Determine Placement of the Cache

    In this task, determine the placement of the cache. If it was decided that hosted mode will be used, determine which server will be hosting the cache. If it is an existing server, complete Task 3 to allocate the disk space to the cache. If it is a new server, use Step 6 to design the BranchCache file server.

    If it was decided that distributed mode will be used, determine the Windows 7 computers that will be hosting the cache. Other clients on the subnet use the Web Services Discovery multicast protocol to locate a cached copy of the file within the branch.

    Record this information in Table A-3 in Appendix A: "Job Aids."

    Task 3: Determine Size of the Cache

    By default, 5 percent of the hard disk drive size will be allocated to the cache, but can be set to any size.

    For each branch location, determine the size of the cache that will be allocated to BranchCache and record this information in Table A-3 in Appendix A: "Job Aids."

    Step Summary

    In this step, it was determined whether BranchCache will be deployed in Hosted Mode or Distributed Mode, the placement of the cache was determined, and the cache size was determined for each location. The BranchCache information collected in this step was recorded in Table A-3 in Appendix A.

    Additional Reading

    BranchCache: http://technet.microsoft.com/en-us/network/dd425028.aspx

    Step 5: Design the DFS Replication Infrastructure

    If it was determined in Step 3 that replication is required to provide access to files for users in branches, this step will design the DFS Replication infrastructure.

    Task 1: Design Replication Groups

    Replication occurs between folders stored on members of replication groups. To facilitate administration, replication groups can be created based on relationships between member systems, such as department or business group within the organization, and type of data being replicated.

    Prior to replication, the primary member inventories all files in its replicated directories (replica tree) in an effort to populate the IDTABLE (a listing of all files and directories in a replica tree). This "IDTABLE scan" must complete before the primary member can send change orders or build staging files to downstream partners as a part of the replication process. The distinction of a primary member ceases to exist once DFS Replication has completed initial synchronization for that replicated folder. Record the primary member server name in Table A-7 in Appendix A: "Job Aids."

    Using the data from Step 2, design groups of servers that meet a common need for a business group or that support the same type of resource. Apply the limits that are documented in Appendix B: "Capacity and Scaling" to the design. Record the replication group information in Table A-7 in Appendix A.

    Task 2: Design the Replication Topology

    The replication topology defines how replication connections are created between members of a replication group. The product group does not recommend that customers set up full mesh connections for infrastructures with many servers. Setting up a full mesh means that synchronization metadata may travel over WAN links multiple times and therefore, this is not the most optimum connection topology. Record the replication topology chosen in Table A-7 in Appendix A.

    Task 3: Choose Folder Replication Option

    DFS replication offers flexibility in replicating folders among servers. For example, if there are three folders to replicate, it is possible to:

    • Create one replication group and one replicated folder, and then put the three folders to be replicated into the replicated folder.
    • Create one replication group and three replicated folders that correspond to each of the folders to be replicated.
    • Create three replication groups, each with a single replicated folder that corresponds to one of the folders to be replicated.

    To choose between these options, balance the following issues:

    • On a LAN network, create a single replicated folder with multiple subfolders instead of creating a replicated folder for each folder to be replicated.
    • There can be performance benefits to spreading the replicated folders across multiple volumes. This requires the use of multiple replicated folders, not a single replicated folder.
    • Create multiple replication groups when a different connection topology is desired for a particular replicated folder.

    Record the folder replication option chosen in Table A-7 in Appendix A.

    Step Summary

    Many organizations need to provide copies, or replicas, of certain files in multiple locations. Replication can provide local, high-speed access to files for clients in locations where they would otherwise have to access the files over a slower WAN link. This step determined whether replication is needed and the data collected was recorded in Table A-7 in Appendix A.

    Additional Reading

    • DFS Step-by-Step Guide for Windows Server 2008: http://technet2.microsoft.com/windowsserver2008/en/library/cf810bb7-51ed-4535-ab0d-86a7cd862e601033.mspx
    • DFS Replication scalability guidelines: http://technet.microsoft.com/en-us/library/cc779936(WS.10).aspx
    • "DFS Replication: What's new in Windows Server 2008": https://blogs.technet.com/filecab/archive/2007/12/26/what-s-new-in-windows-server-2008.aspx

    Step 6: Design the File Services Infrastructure

    In the previous steps, the project scope was determined and the current file services infrastructure was inventoried. Additionally, the decision was made about whether files need to be available in multiple locations, and if so, the mechanism for doing so designed. Now the File Services infrastructure can be designed.

    Take into account any additional roles that the server will be supporting. Often, File Services and Print Services are combined on one system. If this is the case, use the requirements of both roles when designing the server. See the Infrastructure Planning and Design Guide for Windows Server 2008 and Windows Server 2008 R2 Print Services for guidance on designing Print Services for Windows Server 2008.

    The first task is to determine how many servers will be needed then the hardware for each will be. Finally, fault tolerance for the servers will be designed, if required.

    Task 1: Determine File Server Placement

    In order to provide the best experience, each client should have access to one or more file servers over high-speed links. Locations that are separated from the main File Services infrastructure by slow network links may benefit from the addition of a local file server. This is frequently seen in a branch office scenario. Determine whether to plan for additional servers in the remote locations, or consider whether it may be more effective and economical to upgrade the existing network infrastructure. It may also be that the organization decides the users will have to tolerate some latency if the costs of placing a server in a location are more than the organization desires to bear.

    Place a sufficient number of servers to support expected client demand for each area and to ensure adequate growth in storage over the expected life of the server.

    Document server location in Table A-4 in Appendix A: "Job Aids." Then perform the following tasks for each location.

    Task 2: Determine How Many File Servers Will Be Needed

    Start the design with a single server at each designated location, and then add more servers if any of the following requirements apply.

    Requirements for Scale Beyond Windows Server Design Limits

    The environment may exceed scale limits in Windows Server:

    • Design limits of Windows Server 2008. Very large File Services infrastructures may be constrained by design limitations in Windows Server 2008. For example, the maximum size of an NTFS volume is 16 terabytes, and the maximum number of files that can be held on an NTFS volume is 4,294,967,295 files. These limitations are listed in Appendix B: "Capacity and Scaling." Compare the design limitations with the requirements for the infrastructure to determine whether to add more servers.
    • Virtual machines. If file servers will be hosted in virtual machines, the scale limitation will be the host operating system.

    Requirements for Separation

    There may be business requirements that require separation of File Services onto more than one server:

    • Regulatory. Corporate policies or government regulations may require separate storage for certain types of data or for certain parts of the organization. Add the servers necessary to comply with these requirements.
    • Support for external users. Some organizations must provide file sharing resources to support contractors or to support remediation activity using Network Access Protection for systems that have not passed network access requirements. Add servers for this purpose if required by the organization.
    • Organizational requirements. In organizations with multiple business units, some of those units may choose to maintain their own File Services infrastructure. Add servers to support this division of responsibility if required by the business.

    Use Table A-4 in Appendix A to record the server locations and server names that will be used.

    Task 3: Determine Content Servers for BranchCache

    In Step 3, it was determined whether BranchCache will be implemented, and if so, which branches will be served and by which mode of BranchCache. Next, the relevant file shares hosting the original content need to be identified. This may slightly decrease the number of users accessing the original content share because some requests will be served from the local cache. Depending on the complexity of the pairings of original content servers and cache, it may be useful to map this out on paper or in Visio to verify that all shares are covered.

    Review each file share and determine whether it will have users from BranchCache-enabled locations accessing the file share. If so, indicate this in Table A-3 in Appendix A: "Job Aids."

    Task 4: Design Server Hardware

    The goal of this task is to determine the most appropriate hardware on which to deploy the file servers. The hardware specifics that will be discussed include:

    • Processor architecture (32-bit versus 64-bit)
    • Number of CPUs and their speed
    • Amount of memory installed
    • Disk storage capacity
    • Disk subsystem design
    • Number of network card ports configured

    The server hardware will be decided at a high level based on the organization's strategy to either scale up or scale out. Fewer servers with large memory and high performance CPUs can be easier to manage and more cost-efficient for some infrastructures but may be a single point of failure. Using smaller commodity servers with lower capacity can involve a smaller capital investment but often requires additional management effort. Determine whether the organization has a strategy guiding the selection of one model over another, then proceed to determine the server sizing.

    Sizing the Servers

    Start with the prerequisites for Windows Server 2008 (documented at http://download.microsoft.com/download/e/6/3/e63cf2f6-7f71-450b-8e4a-dace88e99456/readme.htm) as a minimum requirement, and then build up the file server configuration to handle the expected workload.

    Performance Tuning Guidelines for Windows Server 2008 (located at http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Perf-tun-srv.docx) includes hardware form factor guidance for Windows Server 2008 in general, and introduces the NetBench performance testing workload for file servers.

    NetBench 7.02 is an eTesting Labs workload that measures the performance of file servers as they handle network file requests from clients. It can be used to determine the load under which a given form factor reaches a utilization threshold.

    The effort required to set up and run benchmarks with NetBench can be significant, and this must be balanced against the requirement for precision in determining the most appropriate CPU and memory form factor for the server. It may be cheaper to simply spend the extra money on the bigger form factor than to run a suite of NetBench tests.

    CPU

    The objective here is to select the number of processors and cores per processor. For most workloads, this may be a straightforward decision. Use the installation's standard server hardware or, if there is concern that this may not be sufficient, specify the next step up. If a dual processor, dual core machine is the standard, and if there is concern about the risk of underperformance, specify a quad processor, dual core machine. The cost difference may be less than the cost of determining the precise CPU requirement.

    If more precision is required, use the most CPU-intensive operations in NetBench (file opens and file creates) to apply a realistic client load on the file server. Define a user profile mix (light/medium/heavy) that matches the observed existing demand on file servers in the organization. Then add users with this profile to the NetBench load test one by one, until the server CPU utilization reaches the peak value that the organization is willing to accept in steady state operations. Record this as the number of users in Table A-4 in Appendix A: "Job Aids."

    Number of users is the number of users that can be supported by a single file server of the starting server hardware. Divide this number into the total number of file server clients to determine the number of servers that must be designed if the starting server hardware is used.

    Memory

    Using adequate RAM in the file server ensures that it can temporarily cache files in memory, reducing the need to retrieve them from disk to satisfy client requests.

    The objective here is to select the amount of memory that will be installed in the machine. For most workloads, this may be a straightforward decision. Use the installation's standard memory form factor or, if there is concern that this may not be sufficient, specify the next step up. The additional cost of specifying the additional memory may be less than the cost of determining the memory requirement with precision.

    If more precision is required, determine the amount of RAM required to support the file server workload. To accomplish this, first compare the number of files that are expected to be open at any one time with the Windows Server 2008 limit for remote concurrent file handles, which is approximately 100,000 files. If users are likely to have more than 100,000 files open, plan to split the users across two or more servers.

    Next, review how additional RAM affects the total size of files, or file set size, that can be held in memory at any one time. On a file server with 1 gigabyte (GB) of RAM, about 500 megabytes (MB) will be used to provide non-paged pool and other operating system functions, leaving 500 MB available for files and NTFS metadata. For RAM that is added beyond that, the entire content is available to hold files. For example, 3 GB of RAM can hold 2.5 GB of file content.

    When file set size exceeds the available memory, files are paged to disk. This paging can result in disk bottlenecks, although a high-speed disk subsystem can relieve that problem.

    To determine how much RAM to design, examine the extent to which the same files are repeatedly accessed. If users repeatedly access the same files, invest in additional memory so that user requests for these files score hits in memory.

    If users access random files, it may be better to invest in faster disks because the files that are being opened will not already be in memory, and the response time will be limited by disk latency.

    Disk Capacity

    The file storage capacity requirements were determined by the inventory collected in Step 2. Select a disk subsystem that meets these requirements and provides sufficient room for growth. Add a safety factor to determine the total capacity that should be designed.

    If the server will also be used to host a BranchCache, by default, 5 percent of the total hard drive space will be allocated to the cache, but this number may be changed depending on the needs of the organization.

    Note   Windows Server 2008 R2 introduces a new feature called File Classification Infrastructure (FCI), which can help reduce file storage sprawl by automatically moving infrequently accessed files to less costly storage systems. See www.microsoft.com/windowsserver2008/en/us/fci.aspx.

    Disk Subsystem

    Performance Tuning Guidelines for Windows Server 2008 (located at http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Perf-tun-srv.docx) provides guidance on choosing a storage array for Windows Server 2008 file servers.

    The maximum peak and sustained bandwidths at which storage can be accessed is determined by the number of physical disks in the array, the speed of controllers, the type of disk (such as SCSI or Fibre Channel), the hardware, a redundant array of independent disks (RAID), and the adapters that are used to connect the storage array to the system.

    To determine the number of physical disks that should be included in RAID 0, RAID 5, and RAID 0+1 virtual disks, consider the following information:

    • Bandwidth (and often response time) improves as disks are added. Plan for a disk array that delivers sufficient IOs Per Second (IOPS) for the workload.
    • Reliability, in terms of mean time to failure for the array, decreases as disks are added.
    • Usable storage capacity increases as disks are added, but so does cost.

    Review Design Before Finalizing

    Now that the server hardware has been selected, verify that the decisions made in Task 1 for file server placement and Task 2 for the number of file servers needed are still correct. It may be that, based on the hardware selections, more or less servers may need to be allocated. Record the final hardware choices in Table A-4 in Appendix A: "Job Aids."

    Task 5: Design Server Fault Tolerance

    Evaluate each collection of files to determine whether fault tolerance is required. Where fault tolerance is required, it can be implemented by providing redundancy in each of the layers of the file server infrastructure:

    • Failover clustering. Failover clustering provides fault tolerance when one server in a cluster is lost. It requires server hardware that supports clustering, which must be marked as "Certified for Windows Server 2008." This can also be validated using the method described at http://technet.microsoft.com/en-us/library/cc732035.aspx.
    • Geo clustering. A failover cluster is still vulnerable as there is no protection from location disasters like fires, floods, or malicious damage. For important data, a geographically dispersed (or multisite) cluster should be used. In this configuration, the cluster nodes are separated geographically, and disks are synchronously mirrored between sites. The cluster is unaware of the geographic distance between its nodes so this must be implemented at the network and storage levels within the infrastructure architecture.

    Determine if additional fault tolerance should be added to the design for each server in the File Services infrastructure. This determination should come from knowledge of the business value of the particular server and requirements such as SLAs that might be in place for the resources on the server. Record fault tolerance selections in Table A-4 in Appendix A: "Job Aids."

    Step Summary

    The File Services infrastructure was designed in this step. The file servers were placed and the server infrastructure for each of the locations was designed. All data collected for this step was recorded in Table A-4 in Appendix A: "Job Aids."

    Additional Reading

    • File Services: http://technet.microsoft.com/en-us/library/cc771548(WS.10).aspx
    • "An Overview of Windows Clustering Technologies: Server Clusters and Network Load Balancing": http://technet.microsoft.com/en-us/library/cc739634(WS.10).aspx

    Step 7: Determine Whether Namespace Services Will Be Required

    Many organizations use DFS Namespace to simplify the process of accessing files on multiple servers. By creating what appears to be a tree of folders, organized by topic, department, or type of information, users don't have to learn the universal naming convention (UNC) path to each folder in the File Services infrastructure.

    A DFS Namespace consists of logical folders (Folders) that are connected to physical folders (Folder Targets). These logical folders are all arranged into a hierarchical infrastructure within a DFS Namespace.

    In this step, a decision whether to implement a DFS Namespace in the organization will be made. Choosing to implement a DFS Namespace will depend on whether the benefits justify the cost in terms of configuration and administration of the namespace root, folders, and folder targets.

    This step assumes that domain-based DFS Namespace is to be used in the infrastructure design. If stand-alone DFS Namespace is being considered, the topics in this section are not substantially affected. For more information on types of DFS Namespace, see Choosing the DFS Namespace Type at http://technet.microsoft.com/en-us/library/cc780773(WS.10).aspx.

    Task 1: Determine Whether DFS Namespace Will Be Implemented

    With a DFS Namespace in place, users do not have to remember UNC paths or map multiple drives to make sense of the File Services infrastructure. Instead, they are presented with a single hierarchical folder structure.

    DFS Namespace can be implemented independently of DFS Replication. DFS Namespace, when used with DFS Replication, also offers fault tolerance for the File Services infrastructure by mapping clients to alternate servers when a server is offline.

    Use the following sequence to determine if the organization can benefit by adding DFS Namespace services to the Windows Server 2008 File Services infrastructure:

  1. Examine the inventory of the existing infrastructure that was collected in Step 2 and determine if namespace is already in use. If DFS Namespace is currently used, it may also need to be designed in the new infrastructure. If existing namespaces are no longer required, they can be deleted from the design.
  2. Determine if namespace is necessary for ease of use. End users often complain of the complexity of dealing with files and folders in a network infrastructure. Consult with business stakeholders to determine if DFS Namespace can be used to simplify the users' view of the file infrastructure.

If DFS Namespace is required, proceed to the next task to design the namespace.

Task 2: Determine the Number of Namespaces

DFS Namespace can be created to allow organizations to design separate folders organized by region, business group, or administrative group. Review the business requirements that were collected in Step 1 to determine whether more than one namespace is required for organizational reasons.

There are also limits to DFS Namespace scalability. When adding folders to namespaces, keep the following recommendations in mind:

  • For stand-alone namespaces, Microsoft recommends a maximum of 50,000 folders with targets. This recommendation is made in order to manage startup times for the DFS Namespace service. If scale beyond this limit is required, be sure to test the startup time to ensure that it is acceptable.
  • For domain-based namespaces, Microsoft recommends limiting the namespace object in Active Directory to 5 MB or less (equivalent to about 5,000 folders with targets). This recommendation is aimed at reducing the time and bandwidth required to replicate the namespace object using Active Directory replication each time the namespace changes. If the domain and servers are Windows Server 2008, and the forest is Windows Server 2003 or greater, Windows Server 2008 mode domain namespaces should be used.

Note   Folders without folder targets do not count against these limits.

Document each namespace that will be designed in Table A-8 in Appendix A: "Job Aids."

The remaining tasks in this step must be completed for each namespace.

Task 3: Determine the Namespace Modes

When creating a namespace, choose one of the following namespace types:

  • A stand-alone namespace
  • A domain-based namespace

Stand-alone namespace

Choose a stand-alone namespace if any of the following conditions apply to the organization's environment:

  • The organization does not use Active Directory Domain Services (AD DS).
  • There is a need to create a single namespace with more than 5,000 DFS Namespace folders in a domain that does not meet the requirements for a domain-based namespace (Windows Server 2008 mode).
  • There is a need to increase the availability of the namespace by using a failover cluster.

Domain-based namespace

Choose a domain-based namespace if any of the following conditions apply to the organization's environment:

  • There is a need to ensure the availability of the namespace by using multiple namespace servers.
  • The organization wants to hide the name of the namespace server from users. Choosing a domain-based namespace makes it easier to replace the namespace server or migrate the namespace to another server.

In addition, if domain-based namespace is chosen, one of the following namespace modes must be chosen:

  • Windows 2000 Server mode
  • Windows Server 2008 mode

The Windows Server 2008 mode includes support for access-based enumeration and increased scalability. The domain-based namespace introduced in Windows 2000 Server is now referred to as "domain-based namespace (Windows 2000 Server mode)."

To use the Windows Server 2008 mode, the domain and namespace must meet the following minimum requirements:

  • The domain uses the Windows Server 2008 domain functional level.
  • All namespace servers are running Windows Server 2008.
  • The forest must be in Windows Server 2003 mode or later.

If the organization's environment supports it, choose the Windows Server 2008 mode when creating new domain-based namespaces. This mode provides additional features and scalability, and also eliminates the possible need to migrate a namespace from the Windows 2000 Server mode.

If the organization's environment does not support domain-based namespaces in Windows Server 2008 mode, use the existing Windows 2000 Server mode for the namespace.

Namespace size recommendations:

  • Stand-alone namespace. The namespace can contain more than 5,000 folders with targets.
  • Domain-based namespace (Windows 2000 Server Mode). The size of the namespace object in AD DS should be less than 5 MB to maintain compatibility with domain controllers that are not running Windows Server 2008. This means no more than approximately 5,000 folders with targets.
  • Domain-based namespace (Windows Server 2008 Mode). The namespace can contain more than 5,000 folders with targets.

Record the data collected in this task in Table A-8 in Appendix A: "Job Aids."

Task 4: Design the DFS Namespace Roots

The DFS Namespace Root is the logical "root" or top folder of the namespace tree. It is a logical folder created on a DFS Namespace host server. Each root can have multiple "root targets" to provide fault tolerance. In an organization that has geographic centers separated by lower speed WAN links, designing additional root targets for each geographical location can improve performance and reduce WAN traffic.

Refer to the organization's requirements for fault tolerance and performance that were to determine whether more than one root target should be designed. Then complete the design for each root target.

Select the servers that will host the namespace root targets by applying the following requirements:

  • A DFS Namespace root host server must have an NTFS volume to host the root.
  • The server must be a member server or domain controller in the domain in which the DFS Namespace is configured. (This requirement applies to every server that will host a root target for a given domain-based DFS Namespace.)
  • The server cannot be a clustered file server unless it is configured to host the domain-based DFS Namespace root on the local storage of a node in the server cluster.

Document these decisions in Table A-8 in Appendix A: "Job Aids."

Task 5: Design Folder Targets

DFS folder targets are the actual physical resources that are connected to the DFS namespace by DFS folders. Folder targets are configured by adding their UNC paths to DFS (logical) folders. Folder targets link the logical folder to a physical location defined by a UNC path. Each folder can be connected to one or more folder targets.

Review the organization's requirements to determine whether to add folder targets in order to increase the fault tolerance of the folder by connecting users to alternate physical folders when one folder is offline. In that case, use DFS Replication to keep the folders synchronized so that users will have a consistent experience when accessing folders through the folder target.

Validating with the Business

  • Does the DFS namespace design meet the business's requirements?
  • Will it be readily understood by business users?

Step Summary

In this step, a decision was made about implementing a DFS namespace in the organization and the data collected for this step was recorded in Table A-8 in Appendix A: "Job Aids." The choice of whether to implement a DFS namespace depends on whether the benefits justify the cost in terms of configuration and administration of the namespace root, folders, and folder targets.

Additional Reading

  • "Developing Root and Link Naming Standards": http://technet.microsoft.com/en-us/library/cc776841(WS.10).aspx
  • DFS Step-by-Step Guide for Windows Server 2008:http://technet.microsoft.com/en-us/library/cc732863.aspx.

Conclusion

This guide followed a step-by-step approach to design a Windows Server 2008 File Services infrastructure. The steps in this guide led the reader through the following activities:

  • Defining the goals and scope of the project.
  • Assessing the current File Services infrastructure.
  • Determining whether file replication and/or caching are required and, if so, designing those services for the File Services infrastructure.
  • Designing a new File Services infrastructure.
  • Determining if namespace services are required and, if so, designing those services.

By following this guidance, an organization can make informed design decisions to create a robust, fault-tolerant File Services infrastructure. This can lead to enhanced productivity through easier discovery of resources, and reduced downtime and lower costs through more effective administration and infrastructure management.

Appendix A: Job Aids

Use the job aids in this appendix to enhance the success of the File Services planning and design process.

Table A-1. Project Scope

Which parts of the organization will participate?

 

Which geographic areas will be included?

 

Use this job aid to record file server statistics for use in the File Services Planning and design process.

Table A-2. File Server Inventory

Location

Server name

Storage (used/free)

Encryption enabled?*

Replication enabled?

Shadow copies?

Phoenix, AZ

Phoenix-DC1

43 GB/57 GB

N

N

Y

           
           
           
           
           

*Note that DFS Replication does not support Enhanced File System (EFS) encrypted files.

Table A-2. File Server Inventory (continued)

Fault tolerance implemented?

Number of active clients

Server resources consumed by other workload

Y

50

12 GB

     
     
     
     
     

Use this job aid to record all relevant data regarding files stored in the File Services infrastructure.

Table A-3. File Information

Location

Total storage

File types1

Client types2

Location of clients accessing files

HR (HQ)

43 GB

D,M

W,M

 

Finance (HQ)

22 GB

D

P

 
         
         
         
         

1 Document (D), Media (M), Other (O)

2 Windows (W), Macintosh (M), UNIX/Linux/NFS (U)

Table A-3. File Information (continued)

Replication

Fault tolerance needed?

BranchCache mode (if applicable)

Servers or clients that will be hosting the cache

N

Y

H

 

Y

Y

D

 
       
       
       
       

Use this job aid to record file server configuration and placement.

Table A-4. File Server Design

Location

Server name

Configuration

Storage(type/capacity)

Fault tolerance

Phoenix, AZ

Phoenix-DC1

1U, Dual-Xeon, 2 GB of RAM

DAS/1 TB

RAID 1

         
         
         
         

Table A-4. File Server Design (continued)

Encryption enabled?

Replication enabled?

Number of users

BranchCache content server?

BranchCache cache host?

N

N

200

Phoenix-DC1

 
         
         
         

Use this job aid to record file system design decisions.

Table A-5. File System Design

Server

Folder

ACLs(by group)

Estimated size

Phoenix-DC1

Finance

Admin(FC)

Finance(M)

230 GB

       
       
       
       

Table A-5. File System Design (continued)

Encryption enabled?

Replication target?

BranchCache target?

N

Y

Y

     
     
     
     

Use this job aid to record shared folder decisions.

Table A-6. Shared Folder Information

Server

Share

Permissions

(by group)

Estimated size

Phoenix-DC1

HR Policy

HR(C)

Finance(R)

23 GB

       
       
       
       

Table A-6. Shared Folder Information (continued)

Non-Windows access

Namespace link?

Replication target?

Replication source

UNIX-NFS

UNIX-CIFS

N

Y

\\CORP-DC1\HR Policy

       
       
       
       

Use this job aid to list replication groups for the DFS Replication infrastructure and their members.

Table A-7. Replication Topology

Replication

group

Replication group members

Replication

topology

Primary member

Multiple replication groups, folders, or multiple folders

HR

Phoenix-DC1

Denver-DC1

Atlanta-FS127

Dresden-FS1

Full Mesh

Phoenix-DC1

Multiple Replication Folders

         
         
         

Use this job aid to list plans for the DFS namespace infrastructure.

Table A-8. DFS Namespace Infrastructure

Namespace

Namespace root

Namespace root targets

Initial folders

Add folder targets?

HR

Corp-FS01

Phoenix-DC1

Dresden-FS1

Policy

Education

Governance

Y

         
         
         

Appendix B: Capacity and Scaling

Windows Server is bound by certain inherent limitations such as maximum NTFS files per volume and maximum volumes per instance. Use this section to determine if a server configuration is nearing any of these limits.

Table B-1. Server Design Limitations

Description

Limit

Maximum number of volumes on a server

Approximately 2,000 volumes.

Up to 1,000 of these volumes can be dynamic volumes; the rest are basic volumes. Boot times increase as the number of volumes increase. In addition, mounted drives must be used to access volumes when all drive letters on a server have been used.

Maximum size of an NTFS volume

232 clusters minus 1 cluster.

Using a 64-kilobyte (KB) cluster (the maximum NTFS cluster size), the maximum size of an NTFS volume is 256 terabytes minus 64 KB.

Using a 4-KB cluster (the default NTFS cluster size), the maximum size of an NTFS volume is 16 terabytes minus 4 KB.

Maximum number of files on an NTFS volume

4,294,967,295 (232 minus 1 file).

There is no limit to the number of files that can be stored in a folder.

Maximum file size on an NTFS volume

16 terabytes (244 bytes) minus 64 KB.

Maximum number of clusters on an NTFS volume

4,294,967,296 (232).

Maximum size of a dynamic volume

2 terabytes for simple and mirrored (RAID-1) volumes.

Up to 64 terabytes for spanned and striped (RAID-0) volumes. (2 terabytes per disk with a maximum of 32 disks per volume.)

Up to 62 terabytes for RAID-5 volumes. (2 terabytes per disk with a maximum of 32 disks per volume and 2 terabytes used for parity.)

Maximum number of dynamic volumes per disk group

1,000.

A disk group is a collection of dynamic disks. Windows Server 2008 supports one disk group per server.

Maximum size of a basic volume

2 terabytes.

Distributed File System Replication Scale Limits

The following list provides a set of scalability guidelines that have been tested by Microsoft:

  • A volume can contain up to 8 million replicated files, and a server can contain up to 1 terabyte of replicated files.

Note   This limit applies to each individual server, not to DFS Replication as a whole.

Note   For more details, see "DFS Replication: What's new in Windows Server 2008" at http://blogs.technet.com/filecab/archive/2007/12/26/what-s-new-in-windows-server-2008.aspx

DFS Namespace Limits

When adding folders to namespaces, keep the following recommendations in mind:

  • For stand-alone namespaces, Microsoft recommends a maximum of 50,000 folders with targets.
  • For domain-based namespaces, Microsoft recommends limiting the namespace object in Active Directory to 5 megabytes (MB) or less (equivalent to about 5,000 folders with targets).

When creating a namespace, choose one of the following namespace types:

  • A stand-alone namespace
  • A domain-based namespace

Choose a stand-alone namespace if any of the following conditions apply to the organization's environment:

  • The organization does not use Active Directory Domain Services (AD DS).
  • There is a need to create a single namespace with more than 5,000 DFS folders in a domain that does not meet the requirements for a domain-based namespace (Windows Server 2008 mode).
  • There is a need to increase the availability of the namespace by using a failover cluster.

Note   Folders without folder targets do not count against these limits.

Appendix C: IPD in Microsoft Operations Framework 4.0

Microsoft Operations Framework (MOF) 4.0 offers integrated best practices, principles, and activities to assist an organization in achieving reliable solutions and services. MOF provides guidance to help individuals and organizations create, operate, and support technology services, while helping to ensure the investment in technology delivers expected business value at an acceptable level of risk. MOF's question-based guidance helps to determine what is needed for an organization now, as well as providing activities that will keep the organization running efficiently and effectively in the future.

Use MOF with IPD guides to ensure that people and process considerations are addressed when changes to an organization's technology services are being planned.

  • Use the Plan Phase to maintain focus on meeting business needs, consider business requirements and constraints, and align business strategy with the technology strategy. IPD helps to define an architecture that delivers the right solution as determined in the Plan Phase.
  • Use the Deliver Phase to build solutions and deploy updated technology. In this phase, IPD helps IT pros design their technology infrastructures.
  • Use the Operate Phase to plan for operations, service monitoring and control, as well as troubleshooting. The appropriate infrastructure, built with the help of IPD guides, can increase the efficiency and effectiveness of operating activities.
  • Use the Manage Layer to work effectively and efficiently to make decisions that are in compliance with management objectives. The full value of sound architectural practices embodied in IPD will help deliver value to the top levels of a business.

Figure C-1. The architecture of Microsoft Operations Framework (MOF) 4.0

Appendix D: Windows Server 2008 File Services in Microsoft Infrastructure Optimization

The Infrastructure Optimization (IO) Model at Microsoft groups IT processes and technologies across a continuum of organizational maturity. (For more information, see http://www.microsoft.com/infrastructure.) The model was developed by industry analysts, the Massachusetts Institute of Technology (MIT) Center for Information Systems Research (CISR), and Microsoft's own experiences with its enterprise customers. A key goal for Microsoft in creating the IO Model was to develop a simple way to use a maturity framework that is flexible and can easily be applied as the benchmark for technical capability and business value.

IO is structured around three information technology models: Core Infrastructure Optimization, Application Platform Optimization, and Business Productivity Infrastructure Optimization. According to the IO Model, migrating File Services to Windows Server 2003 or later can move an organization from a Basic to a Dynamic maturity level. By implementing fault tolerance, data protection and redundancy, and namespace management, an organization can move significantly further into the Dynamic level.

Figure D-1. Mapping of Windows Server 2008 File Services technology into the Core Infrastructure Optimization Model

Version History

Version

Description

Date

2.1

Minor template/formatting updates.

November 2011

2.0

Added "What's New in Windows Server 2008 R2" section. Minor updates to this guide to reflect current IPD template.

Step 2, Task 1: Requires additional information to be recorded when collecting inventory of file servicer resources.

Step 3, Task 1: Additional considerations added relative to determining file server placement.

Step 4, Task 1: Additional considerations added relative to determining the need for file replication. A document relative to BranchCache was added to the "Additional Reading" section in Step 4 as well.

Step 5, Task 1: Added new option for Application Routing Request.

Step 6, Task 3: Added new task to determine Content Servers for BranchCache.

Appendix A: Additional information was collected in job aids "File Info Job Aid" and "File Server Inventory Job Aid."

July 2009

1.1

Step 4, Task 1: Scalability details that apply only to Windows Server 2003 were deleted.

Step 4, Task 2: Background on the role of the primary member was added.

Step 4, Task 3: An explanation of why the product group does not recommend using Full Mesh was added.

Step 4, Task 4: An incorrect statement related to performance was removed. A statement related to connection groups was removed.

Step 4, Summary: Added link to Windows Server 2008 File Services information.

Step 5, Task 2: Sizing information updated for Windows Server 2008.

Step 5, Task 3: New task added, to determine the namespace mode.

Step 5, "Additional Reading": Links updated for Windows 2008 materials.

Appendix B: Sections on scale limits updated for Windows Server 2008.

May 2009

1.0

First release.

June 2008