Windows 7 / Getting Started

---

Manage Folder Availability

Though they are fully supported, mapped drives are no longer an orientation in Windows Server 2008. It is the UNC that is the favored method of rendering shared folder access. This method is based on a \\Servername\sharename naming structure. But there are features of mapped drives that cannot be rendered by a simple UNC name. For example, since a mapped drive is usually created through a logon script, it is easy for administrators to change the address or target of the mapped drive overnight, an operation that is completely transparent to users. As long as they are concerned, the K: drive remains the K: drive no matter where it connects.

Because of this, mapped drives support operational tasks, such as replacing servers and moving shared folders. They are not without problems, though. For example, ever since version 97, Microsoft Office tracks the UNC behind the mapped drive, making it difficult to use conventional drive mappings. If you change this UNC, then Office complains.

And with the advent of Windows Installer-compatible software, the UNC is becoming more and more important. For self-healing purposes, Windows Installer must remember the original installation source of a program. It prefers a UNC format to a mapped drive for this function, though you can control this by editing the Windows Installer package.

This is one reason why Microsoft has developed technologies that support fault tolerance for UNC shares. One main technology is DFS. It can be used to provide many of the same administrative advantages of mapped drives, but without their use.

Work with the Distributed File System

The preferred technology for fault tolerance of file shares is the distributed file system. DFS offers several enterprise features for the support and administration of file shares:

• DFS creates a file share alias that is unique and through which users can access files on a server. This means that you can change the target file share without affecting users because they access the alias and not the physical file server.
• The DFS alias does not only apply to file shares, it can also be applied to Web server addresses, allowing you to modify background Web servers without affecting use of your internal or external Web applications.
• DFS provides fault tolerance through its integration with Active Directory Domain Services. Since DFS namespaces, or aliases, are published in the directory, they are always available to users.
• DFS namespaces can be linked to any number of actual physical file shares. This is called DFS namespace replication. If a server must be shut down for any reason, users continue to work by being redirected by DFS to another physical server.
• DFS can provide load balancing by distributing file access to a number of physical locations, or targets.
• DFS provides transparent consolidation of distributed file shares. If files for a given department are distributed on several physical servers, then DFS can make it appear as if they are all located within a single virtual DFS structure.
• DFS is site-aware; that is, that it can identify ADDS sites and use them to redirect users to a file server located within their site. DFS is ideal for distributing file shares that span regions.
• DFR provides block-level compressed delta replication. It will synchronize the contents of different file share targets by replicating only the changed blocks within a file, not the entire file. By contrast, the File Replication Service (FRS) replicates entire files, even though only a byte of information has changed within them.
• Finally, DFS clients can cache referrals for DFS roots or links for a definable period of time, improving performance by accessing resources without having to perform an AD lookup.

The Distributed File System works in conjunction with DFS Replication system (DFSR) in Windows Server 2008 to provide fault tolerance and link-tracking features. DFS namespaces that are integrated with ADDS are named domain DFS namespaces.

DFS is extremely powerful. For example, if your developers need to work in different environments when preparing corporate applications, they can take advantage of DFS by creating a DFS root for development purposes in the development environment. When it is time to deploy the application into production, they do not have to modify paths within the code.

Another example is the source file for all installations and for the support of Windows Installer features, such as self-healing. By using DFS namespaces, you can have one single installation source path that is available in all sites and that automatically replicates all of the source files from site to site.

You can also work with stand-alone DFS namespaces. These namespaces do not profit from ADDS for redundancy. Because of this, you must run them on failover server clusters or groups of servers that run the same services and that can fail those services over from one to another to provide service continuity. Most organizations run domain-based namespaces since ADDS already exists and they are simpler to set up. Domain-based namespaces are also fault-tolerant at the site level. It is much more complicated to make stand-alone namespaces fault-tolerant at the site level. Use a decision tree to determine which type of namespace you need to work with.