Common DFSN Configuration Mistakes and Oversights
Hello all, Dave here again. Over a year ago, Warren created an ASKDS blog post covering common DFS Replication (DFSR) mistakes and oversights. Someone asked me recently where the common DFS Namespaces (DFSN) mistakes article was located. Well, here it is now...
Below you will find details about the more common configuration mistakes or oversights with the DFSN service. I hope this post helps you avoid them. Where possible, I provided links for additional details.
Improperly decommissioning a namespace server or reinstalling the operating system of a namespace server
If someone removes a namespace server from the network, turns it off permanently, or reinstalls the operating system, namespace access by clients and administrators alike may experience delays. If the server is the only namespace server hosting the namespace, namespace access will fail. In addition, this blocks you from creating a new namespace with that original namespace's name, as its configuration information still resides within the Active Directory. It is also possible to leave orphaned configuration information in the registry of a namespace server that may prevent it from hosting a future namespace.
None of these are irreversible situations, but it takes some manual work to remove references to an improperly decommissioned namespace server as detailed here (and check out all those errors you could cause!):
977511 About the DFS Namespaces service and its configuration data on a computer that is running Windows Server 2003 or Windows Server 2008
https://support.microsoft.com/kb/977511/EN-US
Before decommissioning a namespace server, remove the server from all namespaces using dfsmgmt or dfsutil. If a namespace server goes permanently offline, clean up the namespace configuration in Active Directory.
Disabling the DFS Namespace service of domain controllers
It may seem tempting, but domain controllers should never have the DFS Namespace service disabled. Clients require access to the DFS service of domain controllers to enumerate trusted domains, obtain lists of available domain controllers, and to process domain namespace referral requests. The DFSN service typically requires very little CPU and memory to service requests, even from numerous clients. Also, realize that Group Policy processing requires issuing DFSN referrals to clients that attempt to access the SysVol and Netlogon shares. Sysvol and Netlogon are specialized namespaces that Active Directory automatically manages.
Always keep the DFS Namespaces service running on domain controllers.
Managing a namespace using the original Windows Server 2003 (non-r2) management MMC snap-in
In Windows Server 2003, there exists an original version of the tool to manage DFS Namespaces called dfsgui.msc
("Distributed File System"). This version lacks many features provided by the 2003 R2 (and later) versions of the DFSN management tool dfsmgmt.msc ("DFS Management"). Although you may use dfsgui.msc to manage a namespace running on these later operating systems, the Windows product team never tested interoperability. The newer MMC also is much more efficient and has some usability improvements. Lastly, the older tool does not allow the configuration of delegation, referral ordering, client fail back, polling configuration, Access-based enumeration (2008 and later), DFSR, etc.
Always use the newer "DFS Management" console in lieu of the "Distributed File System" console.
Configuring the "Exclude targets outside of the client's site" setting on a namespace though some Active Directory sites have no targets
The major benefit of DFSN is fault tolerance. However, there are times when namespace administrators would prefer a client's file access to fail if the local site's namespace or file server (DFS folder target) is unavailable. A common mistake is to enable this feature and not realize a number of conditions may prevent clients from reaching any targets.
For instance, to issue proper referrals, the DFSN service must determine the site of all namespace and folder targets. Then, it must identify the site of the client. With the exclusion setting configured, if the client's site cannot be determined, if the client is erroneously associated with a site without any targets, or if the site association of namespace servers and/or folder targets cannot be properly determined, access to the namespace's resources may fail. Below, I attempt to identify the site of the system named “workstation” using DFSUtil and the operation failed:
At the bottom of KB article 975440 are methods for troubleshooting this scenario. You may find the other details in the article useful as well.
Before configuring the "exclude targets outside of the client's site" setting, ensure each site containing clients that require access to a namespace path has a target within their site and verify your Active Directory site configuration is accurate.
Configuring multiple DFSN folder targets on a replicated folder hosting user profiles data
Ned's details found here have become the standard for why Microsoft does not recommend or support using Distributed File System Replication (DFSR) and DFSN (multiple folder targets) for user profile data. For example: if a user were to be referred to a file server that hasn't yet replicated in recently changed data (or perhaps you don't have replication enabled on the shared folder), then the user will not have access to their expected data. The user will logon and receive an old version of their user profile. At best, this generates helpdesk calls--at worst, a user may unknowingly utilize outdated files and lose data.
Do not use DFSN paths with multiple folder targets to store user profiles or volatile user data. Whenever implementing DFSN, you must be vigilant to ensure users and clients are never affected by referrals to alternate file servers where expected data may not reside.
Active Directory site configuration doesn't accurately reflect the physical network topology
As mentioned previously, site associations evaluated by the DFS namespace service are crucial for clients’ direction to optimal folder targets. It is important to validate that each site required to have a target has one (or more) targets, that site configurations defined in the Active Directory are accurate, and that you monitor the environment for changes that can affect site associations.
DFSDiag.exe is one method to validate site associations of all servers involved in the referral process and you should run it from a client if you suspect it isn't working properly. I recommend using the "/testreferral" argument as it diagnoses just about everything related to the namespace's health along with the site associations of clients and targets.
Routinely use DFSDiag.exe to check for failures before they impact users or prior to going "live" with a new namespace.
Incorrectly disabling IPv6 on servers involved in the DFSN referral process
As detailed in this blog post, IPv6 can cause the DFSN referral process to fail or be inaccurate (even on networks that do not support IPv6 functionality). If you are using IPv4 addresses that are not considered a member of the private address space (look here for details), then it is likely your servers are registering IPv6 address in DNS. If you haven't configured IPv6 subnet definitions in Active Directory, these DNS records may be used by DFSN when processing referrals. They cause site associations to fail and incorrect referral ordering.
Once easy method to see if this scenario affects you is to simply open up the DNS Manager MMC snap-in and scan all the host (A) records for your domain's forward lookup zone. If you see any that report an IPv6 address and they are namespace servers or folder targets, you must take corrective action. The aforementioned blog post details some options.
Validate your site configuration for IPv6 compatibility.
Not utilizing multiple namespace servers for domain-based namespaces or a clustered namespace server for standalone namespaces
Avoid single-point-of-failure wherever possible. If hosting important data within a DFS Namespace that must be available at all times, there is no reason to have only a single namespace server hosting it. As mentioned previously, DFSN requires very little CPU and memory resources under typical conditions. If the single namespace server goes down, no one can access the data.
If server resources are scarce and prevent the configuration of additional namespace servers to host a namespace, consider adding domain controllers as namespace servers. On Windows Server 2008 and 2008 R2 domain controllers, install the "DFS Namespaces" role service to get the DFSN management console and command-line tools. Otherwise, the DFSN service is already installed on domain controllers via the DCPromo operation, but none of the tools are available on it.
Always utilize multiple namespace servers. If a standalone namespace is necessary, use a clustered namespace.
Using the less capable namespace type
Windows Server 2008 introduced a new type for DFS Namespaces, aptly named "Windows Server 2008 mode". This offers increased scalability and functionality over a "Windows 2000 Server Mode" namespace. As long as your environment supports the minimum requirements for 2008 mode namespaces, there is no reason not to use them.
To use the Windows Server 2008 mode, the domain and namespace must meet the following minimum requirements:
- The forest uses the Windows Server 2003 or higher forest functional level
- The domain uses the Windows Server 2008 domain functional level
- All namespace servers are running Windows Server 2008 (or later)
Not choosing this mode is a common mistake by administrators. However, it is possible to migrate from a Windows 2000 Server Mode namespace to a Windows Server 2008 mode namespace using the information found here. However, you should perform the migration during a period where your DFS clients can tolerate an outage--migration requires recreating the namespace.
Standalone namespaces used to be the only option if your namespace required more than 5,000 DFS folders (links). If you fall into this scenario, consider replacing it with a Windows Server 2008 mode namespace.
Choose the correct namespace mode when creating a namespace.
Using mount points
Ned covers this very succinctly in a mail sack response found here. There is no reason to utilize mount points within a DFS Namespace's configuration for the namespace's shared folder. Note: we fully support utilizing mount points under a file share that is the target of a DFS folder.
Do not use mount points within the namespace.
Enabling DFSR or FRS on the namespace share
Generally, we do not recommend enabling DFSR or File Replication Service (FRS) replication on a DFS namespace's share. Doing so causes a number of issues, as the replication service attempts to replicate modifications to the reparse folders maintained by the DFSN service within the share. As DFSN removes or adds these reparse folders, FRS/DFSR may replicate the changes before or after DFSN has an opportunity to update the reparse folders based on recent configuration changes.
Ken has an excellent blog here that goes into this further. He also covers additional problems if you try to mix DFSN with DFSR read-only replicas.
Replicate data within separate shared folders and refer clients to those shares using DFS folders within a namespace.
Placing files directly in the namespace share
Avoid placing files or folders within the namespace share. Place any data requiring access via the namespace within a share targeted by a DFS folder. This prevents any potential conflicts with reparse folders. It also ensures that in the event a user connects to an alternate namespace server, they always have a consistent view of the data.
Do not place files or folders within the namespace share.
Not implementing DfsDnsConfig on namespace servers
“DfsDnsConfig?” you may ask. This setting alters the types of names, NetBIOS or DNS FQDN, used for namespace referrals. As network environments grow larger and more complex, it makes sense to move away from the flat NetBIOS WINS namespace to a DNS namespace. Only utilize NetBIOS names if you have network clients that specifically require it and must access DFS namespaces. By using FQDN names, you reduce complexity as clients no longer are dependent on appending correct DNS suffixes to the targets’ names. .
Configure namespace servers to utilize the FQDN names for namespace referrals.
Using Access Based Enumeration on “Windows 2000 Server Mode” namespaces hosted by 2008 and/or 2008 R2 namespace servers
If you have enabled Access Based Enumeration (ABE) on a “Window server 2000 Mode” namespace using the instructions found here, you may find that the Windows Server 2008 or 2008 R2 namespace servers are not correctly maintaining permissions their reparse folders. Your custom permissions may be lost if you restart the server or its DFSN service. If any Windows Server 2003 namespace servers also host that namespace, they do not experience this symptom…
An update is available for both Windows Server 2008 and 2008 R2 to correct this behavior. It prevents the DFS Namespaces service from replacing your custom reparse folder permissions you implement via the instructions found in KB article 907458. Again, those instructions are only appropriate if you have a specific requirement to utilize “Windows 2000 Server Mode” namespaces with 2008 and/or 2008r2 namespace servers.
If supported by your environment (see section “Using the wrong namespace version” above), it is better to leverage the native support for ABE in a “Windows Server 2008 mode” namespace. You no longer require use of icacls.exe (or similar NTFS security editing tool) on each namespace server. The DFSN service automatically enforces the reparse folder permissions defined in the DFS Namespace configuration. Because of the mode requirement, Windows Server 2003 servers cannot be namespace servers in the namespace.
This is also a good opportunity to mention the "latest hotfixes" articles for DFS Namespace servers:
Ensure you update the DFSN services, especially if you wish to use ABE with 2008 and/or 2008 R2 namespace servers.
Configuring domain-based namespaces in an unhealthy Active Directory environment
All DFS Namespace deployments require a healthy Active Directory environment to operate successfully. That is why the "How DFS Works" TechNet article begins by describing what constitutes an "optimal environment" for DFS. If DNS, Active Directory replication, site configuration, PDC FSMO owner domain controller, DFS service state, client health, network communications, and security settings are not operating properly, DFSN operations will suffer. Too often, administrators deploy DFSN in unhealthy environments and clients are unable to access resources properly.
Below are some strategies for verifying many components of your environment:
Use DFSDiag.exe to test all major dependencies of the DFSN service.
If you don't yet have any namespaces in the environment, you may still run the following command to test the domain controllers for DFSN service state and consistency of their site associations:
Dfsdiag /testdcs > dfsdiag_testdcs.txt
If a domain-based namespace already exists, the following commands may be utilized to exercise all of Dfsdiag's tests and output results to the specified file:
dfsdiag.exe /testreferral /dfspath:\\contoso.com\namespace1 /full > dfsdiag_testreferral.txt
dfsdiag.exe /testdfsintegrity /dfsroot:\\contoso.com\namespace1 /recurse /full > dfsdiag_testdfsintegrity.txt
Note: Many of DFSDiag's diagnostics are relative to the system running the utility (e.g. site associations, network connectivity, etc.). Thus, you may find running it from various systems throughout your environment gives you more accurate health assessment . In addition, you may acquire dfsdiag.exe from the Remote Server Administration Tools included with Server editions of 2008 or 2008 R2, or from the download for Vista or Windows 7. Install the "Distributed File System Tools" role administration tool.
Evaluate domain controller health, site configurations, FSMO ownerships, and connectivity:
Use Dcdiag.exe to check if domain controllers are functional. Review this for comprehensive details about dcdiag.
Suggested commands:
Dcdiag /v /f:Dcdiag_verbose_output.txt
Dcdiag /v /test:dns /f:DCDiag_DNS_output.txt
Dcdiag /v /test:topology /f:DCDiag_Topology_output.txt
Active Directory replication
If DCDiag finds any replication failures and you need additional details about them, Ned wrote an excellent article a while back that covers how to use the Repadmin.exe utility to validate the replication health of domain controllers.
Suggested commands:
Repadmin /replsummary * > repadmin_replsummary.txt
Repadmin /showrepl * > repadmin_showrepl.txt
Always validate the health of the environment prior to utilizing a namespace.
My hope is that you find this article helpful (I guess sometimes the glass half-empty folks need an article too!)
-Dave “Doppelwarren” Fisher
Comments
Anonymous
July 25, 2012
This is a great article, thanks! I have a question regarding the "DfsDnsConfig" option on our namespace servers. Is there a safe way to do this for an existing namespace that has 3 members participating in DFSR with mutli-TB of data, to avoid replication? The KB article states that it only applies to new namespaces, but you can delete and add a member to activate it. What I'd like clarification on is how safe is it to use the DFScmd commands listed in that KB article to avoid replication or major problems?Anonymous
January 02, 2014
Pingback from ???? ???????????????????? IPv6 ?? Windows Firewall | IT in realworldAnonymous
January 03, 2014
Pingback from ???? ???????????????????? IPv6 ?? Windows Firewall | IT in realworldAnonymous
January 03, 2014
Pingback from ???? ???????????????????? IPv6 ?? Windows Firewall | IT in realworld