Example: An Organization Designs a DFS Namespace

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

An organization with 35,000 users in one site designs a stand-alone DFS namespace to provide unified access to 1.4 terabytes (TB) of both business-critical and nonessential software. The team responsible for designing and deploying the namespace chooses a stand-alone DFS namespace for the following reasons:

  • The team is not a member of the Domain Admins group, and corporate security policy prevents them from becoming members of this group.

  • Corporate security policy also prohibits the team from creating a domain to host a domain-based DFS namespace.

When designing the namespace, the team needs to provide access to the following types of software:

  • Business-critical software and operating systems

  • Previous (archived) versions of software and operating systems

  • Multimedia software that runs from the network

  • Training courseware

To ensure the availability of the namespace, the team creates the stand-alone DFS root, \\software\public, on a two-node clustered file server. Each node has two Pentium III 1.26-gigahertz (GHz) CPUs and 256 MB of RAM. The root server does not provide any other services.

When evaluating users’ availability requirements for the different types of software, the team determines that the business-critical software and operating systems must be available at all times. In addition, because this is the most frequently accessed software, the team wants good response times. To provide the desired availability and performance, the team uses four servers as link targets. These servers each have two Pentium III 733-MHz CPUs and 256 MB of RAM.

Although the multimedia software is not business critical, the team uses two servers as link targets for this software to improve server response times, because the client portion of the multimedia software accesses files from the server. The team does not use redundant servers for the remaining software, because it is not business critical, and users can tolerate temporary downtime of those servers.

Figure 2.8 describes the DFS namespace for this example.

Figure 2.8   A Stand-Alone DFS Namespace Used for Software Installation

A Stand-Alone DFS Namespace for Software

When updating software on the \\archsvr, \\mmsoft, and \\trainsvr servers, the team adds new files directly to the servers. To update software on the business-critical \\software servers, the team copies the new files to a staging server, \\stagesvr. The team uses Robocopy scripts on \\stagesvr to copy the data to the \\software servers. By making changes only at the staging server, the team makes sure that no accidental changes are made on the \\software servers. The team also uses the staging server as the backup source, because it contains source files for a number of servers in addition to the \\software servers. The backup team backs up the other servers individually.

To prevent the staging server from becoming overloaded, the team does not make the staging server part of the namespace, so users do not directly access the server. The team also increases the hardware specifications of this server to meet the increased disk and CPU utilization required for copying files to the \\software servers and to support backups. The hardware configuration has four Pentium III Xeon 700-MHz processors and 1 gigabyte (GB) of RAM.

While deploying the namespace in the production environment, the team learned a number of valuable lessons that can help other organizations as they test and deploy their namespaces:

  • When setting permissions on the clustered root server, follow the guidelines in "Planning Cluster Security" later in this chapter. Test the clustered root server to verify that permissions work correctly after a failover occurs.

  • Be sure to change the Cluster service password as specified by your organization’s password policy. Windows Server 2003 does not send notification that the password is about to expire. If the password expires, problems can occur at failover. For more information about Cluster service passwords, see "Change the Cluster service account password" in Help and Support Center for Windows Server 2003.

  • Stagger new software announcements so that users do not overload the servers while trying to install new software. For example, send e-mail notification to a percentage of users each day.