Archive for DFS

DFS Troubleshooting on Windows Server 2008 R2

helpicon

DFS Troubleshooting

The DFS Management MMC is the tool that can manage most common administration activities related to DFS-Namespaces. This will show up under “Administrative Tools” after you add the DFS role service in Server Manager. You can also add just the MMC for remote management of a DFS namespace server. You can find this in Server Manager, under Add Feature, Remote Server Administration Tools (RSAT), Role Administration Tools, File Services Tools.

Another option to manage DFS is to use DFSUTIL.EXE, which is a command line tool. There are many options and you can perform almost any DFS-related activity, from creating a namespace to adding links to exporting the entire configuration to troubleshooting. This can be very handy for automating tasks by writing scripts or batch files. DFSUTIL.EXE is an in-box tool in Windows Server 2008.

What can go wrong?

  • Access to the DFS namespace
  • Finding shared folders
  • Access to DFS links and shared folders
  • Security-related issues
  • Replication latency
  • Failure to connect to a domain controller to obtain a DFSN namespace referral
  • Failure to connect to a DFS server
  • Failure of the DFS server to provide a folder referral

Methods of Troubleshooting

I have a very basic lab set up with DFS running on 2 servers. I will be using this to demonstrate the troubleshooting methods

My DFS Namespace is \\dacmt.local\shared

Troubleshooting Commands

  • dfsutil.exe /spcinfo

Determine whether the client was able to connect to a domain controller for domain information by using the DFSUtil.exe /spcinfo command. The output of this command describes the trusted domains and their domain controllers that are discovered by the client through DFSN referral queries. This is known as the “Domain Cache”

dfs1

  • start \\10.1.1.160 (where 10.1.1.160 is your DC)

This should pop up with an Explorer box listing the shares hosted by your Domain Controller

dfs2

  •  netview \\10.1.1.160 (where 10.1.1.160 is your DC)

A successful connection lists all shares that are hosted by the domain controller.

dfs3

  • net view \\10.1.1.200 (Where 10.1.1.200 is your DFS Server)

You can see this shows you your namespace and your shares held on your DFS Server

dfs7

  • dfsutil.exe /pktinfo 

If the above connection tests are successful, determine whether a valid DFSN referral is returned to the client after it accesses the namespace. You can do this by viewing the referral cache (also known as the PKT cache) by using the DFSUtil.exe /pktinfo command

If you cannot find an entry for the desired namespace, this is evidence that the domain controller did not return a referral

dfs4

  • dfsutil.exe cache domain flush
  • dfsutil.exe cache referral flush
  • dfsutil.exe cache provider flush

dfs6

  • ipconfig /flushdns and dfsutil.exe /pktflush and dfsutil.exe /spcflush

By default, DFSN stores NetBIOS names for root servers. DFSN can also be configured to use DNS names for environments without WINS servers. For more information, click the underlined link to view the article in the Microsoft Knowledge Base:

dfs8

  •  DFS and System Configuration

Even when connectivity and name resolution are functioning correctly, DFS configuration problems may cause the error to occur on a client. DFS relies on up-to-date DFS configuration data, correctly configured service settings, and Active Directory site configuration.

First, verify that the DFS service is started on all domain controllers and on DFS namespace/root servers. If the service is started in all locations, make sure that no DFS-related errors are reported in the system event logs of the servers.

dfs9

  • repadmin /showrepl * dc=dacmt,dc=local

When an administrator makes a change to the domain-based namespace, the change is made on the Primary Domain Controller (PDC) emulator master. Domain controllers and DFS root servers periodically poll PDC for configuration information. If the PDC is unavailable, or if “Root Scalability Mode” is enabled, Active Directory replication latencies and failures may prevent servers from issuing correct referrals.

dfs10

  • DFS and NTFS Permissions

If a client cannot gain access to a shared folder specified by a DFS link, check the following:

  • Use the DFS administrative tool to identify the underlying shared folder.
  • Check status to confirm that the DFS link and the shared folder (or replica set) to which it points are valid. For more information, see “Checking Shared Folder Status” earlier in this chapter.
  • The user should go to the Windows Explorer DFS property page to determine the actual shared folder that he or she is attempting to connect to.
  • The user should attempt to connect to the shared folder directly by way of the physical namespace. By using a command such as ping, net view or net use, you can establish connectivity with the target computer and shared folder.
  • If the DFS link has a replica set configured, then be aware of the latency involved in content replication. Files and folders that have been modified on one replica might not yet have replicated to other replicas.

It is also worth checking you do not have any general networking issues on the server you are connecting from and also that there are no firewall rules or Group Policies blocking File and Printer Sharing!

  • DFS Tab on DFS folders accessed through the DFS Namespace

It is recommended that one of the first things that you determine when tracking an access-related issue with DFS is the name of the underlying shared folder that the client has been referred to. In Windows 2000, there is a shell extension to Windows Explorer for precisely this purpose. When you right-click a folder that is in the DFS namespace, there is a DFS tab available in the Properties window. From the DFS tab, you can see which shared folder you are referencing for the DFS link. In addition, you can see the list of replicas that refer to the DFS link, so you can disconnect from one replica and select another. Finally, you can also refresh the referral cache for the specified DFS link. This makes the client obtain a new referral for the link from the DFS server.

dfs11

  • Replication Latency

Because the topology knowledge is stored in the domain’s Active Directory, there is some latency before any modification to the DFS namespace is replicated to all domain controllers.

From an administrator’s perspective, remember that the DFS administrative console connects directly to a domain controller. Therefore, the information that you see on one DFS administrative console might not be identical with the information about another DFS administrative console (which might be obtaining its information from a different domain controller).

From a client’s perspective, you have the additional possibility that the client itself might have cached the information before it was modified. So, even though the information about the modification might have replicated to all the domain controllers, and even if the DFS servers have obtained updates about the modification, the client might still be using an older cached copy. The ability to manually flush the cache before the referral time-out has expired, which is done from the DFS tab in the Properties window in Windows Explorer, can be useful in this situation.

  • dfsdiag /testdcs /domain:dacmt.local
  • DFSDiag /testsites /dfspath:\\dacmt.local\Shared\Folder 1 /full
  • DFSDiag /testsites /dfspath:\\dacmt.local\Shared /recurse /full
  • DFSDiag /testdfsconfig /dfsroot:\\dacmt.local\Shared
  • DFSDiag /testdfsintegrity /dfsroot:\\dacmt.local\Shared
  • DFSDiag /testreferral /dfspath:\\dacmt.local\Shared

With this you can check the configuration of the domain controllers on your DFS Server. It verifies that the DFS Namespace service is running on all the DCs and its Startup Type is set to Automatic, checks for the support of site-costed referrals for NETLOGON and SYSVOL and verifies the consistency of site association by hostname and IP address on each DC.

dfs12
and

dfs13

and

dfs14

DFSR and File Locking

DFS lacks a central feature important for a collaborative environment where inter-office file servers are mirrored and data is shared: File Locking. Without integrated file locking, using DFS to mirror file servers exposes live documents to version conflicts. For example, if a colleague in Office A can open and edit a document at the same time that a colleague in Office B is working on the same document, then DFS will only save the changes made by the person closing the file last.

There is also another version conflict potential which arises even when the two colleagues are not working on the same file at the same time. DFS Replication is a single-threaded operation, a “pull” process. The result, synchronisation tasks are able to quite easily “queue” up and create a backlog. As a result changes made at one location are not immediately replicated to the other side. It is this time delay which creates yet another opportunity for file version conflicts to occur.

http://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx

NETBIOS Considerations

In terms of NetBios, the default behavior of DFS is to use NetBIOS names for all target servers in the namespace. This allows clients that support NetBios only name resolution to locate and connect to targets in a DFS namespace. Administrators can use NetBIOS names when specifying target names and those exact paths are added to the DFS metadata. For example, an administrator can specify a target \\dacmt\Users, where dacmt is the NetBIOS name of a server whose DNS or FQDN name is dacmt.local

http://support.microsoft.com/kb/244380

DFS – Enable Access-Based Enumeration on a Namespace

Applies To: Windows Server 2008

Access-based enumeration hides files and folders that users do not have permission to access. By default, this feature is not enabled for DFS namespaces. You can enable access-based enumeration of DFS folders by using the Dfsutil command, enabling you to hide DFS folders from groups or users that you specify. To control access-based enumeration of files and folders in folder targets, you must enable access-based enumeration on each shared folder by using Share and Storage Management.

Caution

Access-based enumeration does not prevent users from getting a referral to a folder target if they already know the DFS path. Only the share permissions or the NTFS file system permissions of the folder target (shared folder) itself can prevent users from accessing a folder target. DFS folder permissions are used only for displaying or hiding DFS folders, not for controlling access, making Read access the only relevant permission at the DFS folder level

In some environments, enabling access-based enumeration can cause high CPU utilization on the server and slow response times for users.

Requirements

To enable access-based enumeration on a namespace, all namespace servers must be running at least Windows Server 2008. Additionally, domain-based namespaces must use the Windows Server 2008 mode

To use access-based enumeration with DFS Namespaces to control which groups or users can view which DFS folders, you must follow these steps:

  • Enable access-based enumeration on a namespace.
  • Control which users and groups can view individual DFS folders.

Method

To enable access-based enumeration on a namespace by using Windows Server 2008, you must use the Dfsutil command

  • Open an elevated command prompt window on a server that has the Distributed File System role service or Distributed File System Tools feature installed.
  • Type the following command, where <namespace_root> is the root of the namespace

dfsutil property abde enable \\<namespace_root>

For example, to enable access-based enumeration on the domain-based namespace \\contoso.office\public type the following command:

dfsutil property abde enable \\contoso.office\public

Controlling which users and groups can view individual DFS folders

By default, the permissions used for a DFS folder are inherited from the local file system of the namespace server. The permissions are inherited from the root directory of the system drive and grant the DOMAIN\Users group Read permissions. As a result, even after enabling access-based enumeration, all folders in the namespace remain visible to all domain users.

To limit which groups or users can view a DFS folder, you must use the Dfsutil command to set explicit permissions on each DFS folder

dfsutil property acl grant DOMAIN\Account:R (…) Protect Replace

For example, to block inherited permissions (by using the Protect parameter) and replace previously defined ACEs (by using the Replace parameter) with permissions that allow the Domain Admins and CONTOSO\Trainers groups Read (R) access to the \\contoso.office\public\training folder, type the following command:

dfsutil property acl grant \\contoso.office\public\training ”CONTOSO\Domain Admins”:R CONTOSO\Trainers:R Protect Replace

Permission table

DFS Replication

What is DFS Replication?

DFS Replication is a multimaster replication engine that supports replication scheduling and bandwidth throttling. DFS Replication uses a compression tool called Remote Differential Compression (RDC) which can be used to efficiently update files over a limited bandwidth network. RDC detects insertions, removals and re-arrangements of data in files thereby enabling DFS Replication to replicate only the changes when the files are updated. Another important feature of DFS Replication is that in choosing replication paths,it leverages the Active Directory site links configured in Active Directory Sites and Services. RDC replaced FRS (File Replication Services)

Configuration

As an example lets, use DFS Replication to replicate the contents of a share called Invoices from Server1 to Server2. That way, should the share on Server1 somehow become unavailable, users will still be able to access its content using Server2. Every file server that needs to participate in replicating DFS content must have the DFS Replication Service installed and running

Simply create a second Invoices share on Server2, replicate the contents of \\Server1\Invoices to \\Server2\Invoices, and add \\Server2\Invoices to the list of folder targets for the \\domain\Namespace\Invoices folder in the namespace. That way if a client tries to access a file named Sample.doc found in \\domain\Namespace\Invoices on Server1 but Server1 is down, it can access the copy of the file on Server2.

  • To accomplish this, the first thing you need to do is install the DFS Replication component if you haven’t already done so.
  • Create a new folder named C:\Invoices on Server2 and share it with Full Control permission for Everyone (this choice does not mean the folder is not secure as NTFS permission are really used to secure resources, not shared folder permissions)
  • Now in the DFS Management Console, let’s add \\Server2\Invoices as a second folder target for \\Domain\Namespace\Server1\Invoices. Open the DFS Management console and select the following node in the console tree: DFS Management, Namespaces, \\r2.local\Accounting, Billing, Invoices
  • Right-click the Invoices folder in the console tree and select Add Folder Target. Then specify the path to the new target -\\Server2\Invoices
  • Once the second target is added, you’ll be prompted to create a replication group

  • A replication group is a collection of file servers that participate in the replication of one or more folders in a namespace. In other words, if we want to replicate the contents of \\Server1\Invoices with \\Server2\Invoices, then Server1 and Server2 must first be added to a replication group. Replication groups can be created manually by right-clicking on the DFS Replication node in the DFS Management console, but it’s easier here if we just create one on the fly by clicking Yes to this dialog box. This opens the Replicate Folder Wizard, an easy-to-use method for replicating DFS content on R2 file server

Next steps of the wizard

  • Replication Eligibility. Displays which folder targets can participate in replication for the selected folder (Invoices). Here the wizard displays \\Server1\Invoices and \\Server2\Invoices as expected.
  • Primary Member. Makes sure the DFS Replication Service is started on the servers where the folder targets reside. One server is initially the primary member of the replication group, but once the group is established all succeeding replication is mulitmaster. We’ll choose Server1 as the primary member since the file Sample.doc resides in the Invoices share on that server (the Invoices share on Server2 is initially empty).
  • Topology Selection. Here you can choose full mesh, hub and spoke, or a custom topology you specify later.
  • Replication Group Schedule and Bandwidth. Lets you replicate the content continuously up to a maximum specified bandwidth or define a schedule for replication (we’ll choose the first option, continuous replication).

Configure a DFS NameSpace on Windows Server 2008

The DFS Management snap-in is the graphical user interface (GUI) tool for managing DFS Namespaces and DFS Replication. This snap-in is new and differs from the Distributed File System snap-in in Windows Server 2003

The DFS NameSpace will be the client facing aspect of DFS and what really makes life easier for the end users. Having a common namespace across your enterprise for the users to share files will cut down on support calls and make collaboration on documents a breeze.

Configuring DFS

  • Click Start, point to All Programs, point to Administrative Tools, and then click DFS Management.

  • In the left pane click on Namespaces and then in the right column click New Namespace

  • In the New Namespace Wizard, the first thing it wants to see is your server that will host the Namespace. In this case it will be the server that you installed DFS on. Therefore enter TESTDOMAIN as your server name

  • The next window is Namespace Name and Settings, and it is asking for the name of the namespace. Depending on if this is a standalone install or a domain, this is the name that will be after the server or domain name. In this case I am going to type the namespace Sharedfiles.
  • Notice when you type in the name the Edit Settings button becomes live. This is because the wizard will create the shared folder. You can modify the settings it uses at this time by clicking Edit Settings

  •  You can now edit the following settings:Local path of share folder
    Shared folder permissionsI am going to go with Administrators have full access; Other users have read and write permissions. If you select Custom you can choose specific groups and users and give them specific rights. Click Ok when you are done choosing permissions, then click Next.

  • Next > Namespace Type, there are two choices: Domain-based namespace or Stand-alone namespace. There are some big difference between the two so let’s take a quick look at them now:
  • Domain Based Namespace = Stored on one of more servers and in Active Directory Domain Services.Increased scalability and access based enumeration when used in Server 208 Mode
  • Standalone Namespace = Stored on only a single namespace server, for redundancy, you have to use a failover cluster

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.
  • Choose Domain-based namespace in Windows Server 2008 mode and you can see the preview is going to be \\ADExample.com\Sharedfiles, once your choice is made click on Next.
  •  The next screen lets you review the choices you just made, if they are correct go ahead and click Create.

  • Next you will see a screen telling you that the namespace is being created. After a few minutes you should see the status of Success, and then click Ok.

  • Now in DFS Management Snap-in you can see the Namespace we just created.

  • Next try creating a folder. Right click on the namespace and click New Folder.

  • Now type the name of the folder you want. In this case I am going to be very original and type Folder1, but hopefully you will use something more descriptive when the time comes.Below the Name field you will see a space that shows you a preview of the Namespace with this new folder. Also under that you will see Folder Targets. This allows you to point this folder at a shared folder already on your network.That way you don’t have to migrate files over, but be warned; if you setup these target folders there is no replication, so if that share goes down for any reason users will not be able to access that data. Go ahead and click Ok

  • You will now see in the DFS Management Snap-in Folder1 under the namespace we just created.

Adding another Namespace Server

This has several advantages:

  • If one namespace server hosting the namespace goes down, the namespace will still be available to users who need to access shared resources on your network. Adding another namespace thus increases the availability of your namespace.
  • If you have a namespace that must be available to users all across your organization but your Active Directory network has more than one site, then each site should have a namespace server hosting your namespace. That way, when users in a site need to contact a namespace server for referrals, they can do so locally instead of sending traffic requests to other sites. This improves performance and reduces unnecessary WAN traffic

Instructions

  • Firstly install DFS on a second server. Include replication as ticked if you need to
  • Go back to your first DFS Server and click on Add Namespace Server
  • Choose your second Namespace server

  • Note that a folder named Shared (or whatever you created already) will now automatically be created on your second server and shared with the appropriate permissions (Read permission for Everyone). You can override this default behavior if you like by clicking Edit Settings.
  • Now you have two namespace servers defined for your namespace.
  • The question is, when a user in one department tries to access the namespace, which namespace server will it use? This brings us to the next topic—referrals.

Referrals

By default, DFS tries to connect a client with a target in the client’s own site first whenever possible to prevent the client from having to use a WAN link to access the resource. Furthermore, DFS also tries to randomly load-balance such access when there are multiple targets available in the client’s site.

  1. Click on the root then click Namespace Servers in the Details pane.
  2. Right click on the entry here and select Properties > Advanced
  3. Tick Override referral ordering and select First among all targets for the server you want to be the priority DFS server

Note that adding additional namespace servers is only supported for domain-based namespaces, not standalone namespaces

Finally, if your WAN links are unreliable, you might find your clients frequently accessing different targets for the same folder. This can be a problem, for by default, DFS caches referrals for a period of time (300 seconds or 5 minutes) so if a target server suddenly goes down the client will keep trying to connect to the target and give an error instead of making the resource available to the client from a different target. Eventually (by default after 300 seconds or 5 minutes) the referral will expire in the client’s cache and a new referral will be obtained to a target that is online and the client will be able to access the desired resource, but in the meantime the user may grow frustrated since (a) the user has to wait for the referral to expire and (b) after the referral expires and a new one is obtained, the referral may direct the client to access a remote target over the WAN link which is not an optimal situation. To prevent this from happening (especially non-optimal targets), you can configure client failback on the namespace (or on specific folders in your namespace) so that when the failed target comes back online the client will fail back to that target as its preferred target

Enabling Access Based Enumeration (See next Blog for more info)

  1. On your DFS Server right click on the root and
  2. Select Properties
  3. Select Advanced and choose “Enable access-based enumeration for this namespace”
  4. On each Shared Folder, right click > Properties > Advanced > Set explicit view permissions on the DFS Folder which will enable folders to be seen if the user has permission, or the folders will be hidden

Useful Link

http://www.youtube.com/watch?v=KQ_oW7JlRRU

http://www.youtube.com/watch?v=yPyfQ_NkyNw

 

Installing DFS (Distributed File System)

What is DFS?

DFS stands for Distributed File System and provides two very important benefits for system administrators of Wide Area Networks (WAN) with multiple sites that have a need to easily store, replicate, and find files across all locations.

  • The first is the benefit of being able to have one Namespace that all users can use, no matter what their location, to locate the files they share and use.
  • The second is a configurable automatic replication service that keeps files in sync across various locations to make sure that everyone is using the same version.

Distributed File System (DFS) allows administrators to group shared folders located on different servers by transparently connecting them to one or more DFS namespaces. A DFS namespace is a virtual view of shared folders in an organization. Using the DFS tools, an administrator selects which shared folders to present in the namespace, designs the hierarchy in which those folders appear, and determines the names that the shared folders show in the namespace. When a user views the namespace, the folders appear to reside on a single, high-capacity hard disk. Users can navigate the namespace without needing to know the server names or shared folders hosting the data. DFS also provides many other benefits, including fault tolerance and load-sharing capabilities, making it ideal for all types of organizations.

Two very important aspects of DFS

DFS NameSpaces

Each namespace appears as a folder with subfolders underneath.

The trick to this is that those folders and files can be on any shared folder on any server in your network without the user having to do any complicated memorization of server and share names. This logical grouping of your shares will also make it easier for users at different sites to share files without resorting to emailing them back and forth.

DFS Replication

This service keeps multiple copies of files in sync.

Why would you need this? Well if you want to improve performance for your DFS users you can have multiple copies of your files at each site. That way a user would be redirected to the file local to them, even though they came through the DFS Namespace. If the user changed the file it would then replicate out to keep all copies out in the DFS Namespace up to date. This feature of course is completely configurable.

DFS Namespaces Illustrated

The following figure illustrates a physical view of file servers and shared folders in the Contoso.com domain. Without a DFS namespace in place, users need to know the names of six different file servers, and they need to know which shared folders reside on each file server.

When the IT group in Contoso.com implements DFS, they must first decide the type of namespace to implement. Windows Server 2003 offers two types of namespaces: stand-alone and domain-based. The IT group also chooses a root name, which is similar to the shared folder name in a Universal Naming Convention (UNC) path \\ServerName\SharedFolderName.

The following figure illustrates two namespaces as users would see them. Notice how the address format differs — one begins with a server name, Software, and the other begins with a domain name, Contoso.com. These differences illustrate the two types of roots: stand-alone roots, which begin with a server name, and domain-based roots, which begin with a domain name. Valid formats for domain names include \\NetBIOSDomainName\RootName and \\DNSDomainName\RootName

Installing DFS

Installing DFS Management also installs Microsoft .NET Framework 2.0, which is required to run the DFS Management snap-in.

  • Open Server Manager.
  • Click Roles > Click Add Roles

  • Select File Services from the list of roles.

  • Now you will get an Introduction to File Services information screen; read through it and move on by clicking Next.

  • In Select Service Roles you can click on Distributed File System and it should also place a check next to DFS Namespaces & DFS Replication; after this click Next.NOTE: At the bottom you will see Windows Server 2003 File Services and File Replication Service. You would only choose this if you were going to be synchronizing the 2008 server with old servers using the FRS service.

  • On the Create a DFS Namespace screen you can choose to create a namespace now or later.I am going to create one later. So I am going to choose Create a namespace later using the DFS Management snap-in in Server Manager and then click Next.

  • The next screen allows you to confirm your installation selections, so review and then click Install.

  • After a short interval of loading you will see the Installation Results screen which will hopefully have Installation succeeded in the top right. Go ahead and click Close.

  • In Server Manager you should now see File Services and under the Role Services you will see the installed components:

DFS has the following dependencies:

  • Active Directory replication. Domain-based DFS requires that Active Directory replication is working properly so that the DFS object resides on all domain controllers in the domain.
  • Server Message Block (SMB). Clients must access DFS root servers by using the SMB protocol.
  • Remote Procedure Call (RPC) service and Remote Procedure Call Locater service. The DFS tools use RPC to communicate with the DFS service running on DFS root servers.
  • Distributed File System service dependencies. The Distributed File System service must be running on all DFS root servers and domain controllers so that DFS can work properly. This service depends on the following services:

The Server service, Workstation service, and Security Accounts Manager (SAM) service on DFS root servers. The Distributed File System service also requires an NTFS volume to store the physical components of DFS on root servers.

The Server service and Workstation service on domain controllers.

See the next Blog Post for information on Configuring DFS