Partager via

Monitoring and Maintaining DFS Namespaces

  • Article

Hello all, David here again. If you are reading this post, you likely have Distributed File System Namespaces (DFSN) deployed or are at least considering it. In large environments, DFS Namespaces may stretch across many sites and target tens or hundreds of file servers. Depending on the size and quantity of namespaces, you may be wondering about the methods available to monitor the health of namespaces and ensure their proper function. I have written the information below to provide such methods.

Utilize the DFSDiag.exe utility

First, the administrator of any environment with namespaces should routinely run the DFS Diagnostics (DFSDiag.exe) tool. DFSDiag is available in Windows Vista, Server 2008, 7, and 2008 R2. For any 2008 or 2008 R2 systems not hosting the DFS Namespaces service, you will need to install the Distributed File System Tools found in the Remote Server Administration Tools (RSAT) by using Server Manager. RSAT is a separate download for Vista and Windows 7. In addition, you may leverage the tool in an environment consisting of Windows Server 2003 domain controllers and namespace servers, but you will need at least one of the later OS's to run DFSDiag. If possible, use the Windows 7 or 2008 R2 version of DFSDiag--it contains additional help text describing each option. Lastly, it supports both domain-based and standalone namespaces.

While there have been a few other blog posts about DFSdiag (look here and here), I will mention the key issues it detects within an environment:

  • Offline file servers, domain controllers, and DFSN servers (Helpful in detecting retired servers that are still referenced within the namespace!)
  • Inaccessible file servers because they have inconsistent NTFS and share permissions when compared to other targets of the DFSN folder
  • Invalid site associations of the system running DFSDiag locally or of any targets defined in the namespace
  • Inconsistent registry settings for the DFSN service compared between namespace servers
  • Inconsistent Active Directory metadata between the domain's domain controllers (may indicate replication latencies or failures)
  • Overlapping folders, folder targets, and duplicated folders
  • Inconsistencies with Access Based Enumeration (ABE) of the namespace and of the namespace share

Here is a screenshot of DFSDiag output while file server "2008fs1" is offline and the NTFS permissions of the two targets of \\CONTOSO\Namespace1\folder1 are not consistent:

image

As you can see, checking all these dependencies manually would take an enormous amount of time. So let DFSDiag do all the work and allow you to fix problems before your users have an opportunity to call the helpdesk!

Be mindful when configuring subnets and their site associations within the Active Directory. Clients and servers which cannot be mapped to a site will prevent DFS from referring clients to their local targets. DFSDiag will report a failure to map a server's IP address to a site, but it will not alert you if there are random clients in your environment not belonging to an Active Directory site. For this reason, periodically check if any Netlogon ‘5807’ events have been reported on any domain controllers. If any are found, follow the instructions within the event to review the Netlogon.log debug log file located within "%systemroot%\debug" and search for all occurrences of 'NO_CLIENT_SITE'. These indicate the name and IP address of clients on your network which cannot be mapped to an Active Directory site. Then, create the appropriate subnets.

Event ID: 5807
Source: NETLOGON
Description:

During the past number hours there have been number connections to this Domain Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client's site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites. The names and IP addresses of the clients in question have been logged on this computer in the following log file 'SystemRoot\debug\netlogon.log' and, potentially, in the log file 'SystemRoot\debug\netlogon.bak' created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text 'NO_CLIENT_SITE:'. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize'; the default is 20000000 bytes. The current maximum size is 20000000 bytes. To set a different maximum size, create the above registry value and set the desired maximum size in bytes.

Leverage the File Services Management Pack found in SCOM

If you have System Center Operations Manager (SCOM) deployed, you may utilize the File Services Management Pack to retrieve health information from all File Services roles, including DFS Namespaces. Download is available here.

Ready a “toolkit” of common tools and utilities

Troubleshooting DFS Namespace issues can be difficult. It usually makes sense to begin investigations on a client experiencing a specific failure to access the namespace. Consider building a “toolkit” to make it easier to run DFSDiag, DFSUtil, and Network Monitor 3.4 on the problematic client. Otherwise, you will be forced to download and install the Remote Server Administration Tools (RSAT) to the system you wish to diagnose, and then configure the DFSN RSAT component. A much easier method is to copy DFSUtil.exe and DFSDiag.exe (both found in %systemroot%\system32) to a share, to a thumbdrive, or directly to the client. Ensure that you also copy the dfsdiag.exe.mui language file from the '%systemroot%\system32\en-us' folder and place it into an 'en-us' subfolder where you intend to run dfsdiag. Note, you will also need to maintain separate versions of dfsdiag if you maintain both Vista/2008 and Window 7/2008 R2 systems. If you were to rename dfsdiag.exe to 'dfsdiagwin7.exe', ensure you similarly rename the MUI file to 'dfsdiagwin7.exe.mui'.

Create a disaster recovery plan

Do you have a disaster recovery plan in the event all or portions of your namespace are lost due to hardware failures or accidental deletions? If not, strongly consider exporting your namespace using DFSUtil.exe periodically. The XML-based output file may be imported back into the namespace (or a completely new namespace) in the event of a problem, or it may be utilized simply as a historical record of the namespace's design. The export should be considered in addition to regular Active Directory (system state) and namespace server backups (you are backing up Active Directory regularly, right???). Trust me... you won't realize the value of this exported namespace data until you experience a situation where it takes you hours to recover the namespace rather than minutes. A sample command to export a namespace 'sales' in domain 'contoso.com' is:

dfsutil /root:\\contoso.com\sales /export:c:\NameSpaceBackups\sales_namespace_1-10-2011.txt

Install Service Updates

Ensure that you are running the latest version of DFS Namespace-related components. The articles listed in the link below are routinely updated to reflect the latest updates available for both DFSN and DFSR: https://www.microsoft.com/windowsserversystem/dfs/hotfixes.mspx

Increase the scalability of DFSN

If your namespaces host thousands of links and operates in 'Windows 2000 Server mode', strongly consider converting the namespace to 'Windows Server 2008 mode'. You will gain increased scalability and the option to use Access Based Enumeration (ABE). For more information, please see https://technet.microsoft.com/en-us/library/cc753875.aspx.

Utilize the Best Practices Analyzer

Lastly, on Windows Server 2008 R2 DFSN servers run the Best Practices Analyzer for File Services. While it is focused on DFSN settings of the local server, it covers a few scenarios not covered by DFSDiag. More information about the BPA, please visit https://technet.microsoft.com/en-us/library/ff633466(WS.10).aspx and also download an updated version of the BPA here.

Any distributed service can be very difficult to monitor and maintain. My hope is the strategies and methods above keep your DFS Namespaces in tiptop shape. Happy DFSN'ing!

- Dave “Fire Marshall Bill” Fisher

Comments

  • Anonymous
    February 03, 2011
    Thanks Dave. DFS is one of those technologies solves many problems and quickly becomes a Tier 1 service though no one ever (thinks they) sees it. Keeping your skills in the subject are critical, because the day may come when a fellow tech or hardware failure, etc; makes you wish you had. Though I rarely use it, I am seeing a trend with using the Network Monitor.