Setting up Windows DFS without WINS

I always have a strange suspicion that Windows DFS (up to W2K3) still needs WINS for it to work, but some people were saying that a purely W2K3 environment should not need to WINS and even have DFS working as such.

Anyway, I went to look up the Microsoft technical reference for DFS and found this:

How DFS Works in Environments Without WINS

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 \\FS1\Users, where FS1 is the NetBIOS name of a server whose DNS or FQDN name is FS1.contoso.com.

Organizations that do not use NetBIOS and WINS can still use DFS, but before setting up namespaces the administrators must create the DFSDnsConfig registry entry on all root servers and then restart the DFS service on all root servers. Administrators must then use the DNS names for when adding all targets to the namespace. When these steps are complete, the referrals will contain the DNS names of targets accessed by clients. If a namespace already exists, the administrator must perform the following steps:

1. Export the namespace to a data file by using Dfsutil.exe.
2. Delete the namespace.
3. In the exported data file, change the NetBIOS names to DNS names for all targets.
4. Recreate all root targets by using DNS names.
5. Import the updated data file.

Now this is interesting because it appears that by default DFS (even in W2K3) still uses NetBIOS and you need to make changes to change this behaviour. Hmm… I wonder how my colleague managed to get his DFS working only on DNS straight out of the box.

Anyway, if anyone managed to get DFS working without WINS and without make the changes to the default above, do drop me a line. I would be interested to find out more.

Slow DFS and dead DFS root target

One of our branch IT staff complained that accessing their group and user data was slow. I logged onto a server in the branch site and tried browsing the data and also found it’s reaction, far from normal, a bit retarded. Browsing folders in explorer would hang explorer from a while before responding.

As our DFS links point to Netapps filers, I thought, it could be a problem with the filer performance. So I opened the physical folders and tried browsing around, but performance was good.

So the issue must be coming from the DFS roots itself, but why would this degrade suddenly?

A quick check on the cache with dfsutils immediately tells me what is wrong, I am getting my referrals from another branch (say from Taiwan to India!). No wonder its slow!

Another check and I found that we had decommissioned a DC in this branch sometimes ago and its a replica of our DFS root. We have a dead DFS root target.

To remove dead DFS root target, you cannot do it from the GUI, you have to use dfsutil to remove the dead target:

dfsutil /unmapftroot /root:\\myroot.com\myshare /server:\\server /share: myshare1

Check out MS DFSUtil examples.

DFS referral issue

Quite a while ago, helpdesk came to use with this unusual problem

When some users logon to their workstation, they receive the error “Logon Failure: The target account name is incorrect”. This happens when they are trying to map to any shares in our DFS root, e.g. \\mycom\dfsroot. As such, non of their network drives were mapped.

For some workstations, they could still map to the network drives after logon manually, but for some they received the same errors when trying to map manually. For some workstations, a secure channel reset to another DC and a reboot seems to work. And users have no problems with mapping to another root, e.g \\mycom\dfsroot2, though. This isolates the problem to the dfsroot share.

The event logs on the clients contains the following:

Event ID: 3034
Type: Warning
Source: MRxSmb
Description:
The redirector was unable to initialize security context or query context attributes.

Error code
0000: 00080000 00560002 00000000 80000bda
0010: 00000000 80090322 00000000 00000000
0020: 00000000 00000000 0000046c 80090322

We ran a check on MSKB and came across this:
Connecting with Incorrect Computer Name Results in 3034 Warning

This is confirmed via netmon on the client, in the netmon capture we saw:

• Client as for DFS referral and got a reply from SERVER1
• However, SERVER1 address somehow resolves to SERVER2 and when the client actually requests for a DFS referral, they ask from SERVER2.
• SERVER2 then rejected the request, as the referral was for SERVER1

How did this happened?

Well, it seems like one of my team mates was pre-building SERVER1 here, which was meant to be shipped to another location. SERVER1 is a DFS root replica for \\mycom\dfsroot. This was then shutdown and the SAME IP address was during to pre-build SERVER2 and install DFS also. This is also going to be a replica in the same \\mycom\dfsroot. SERVER1’s was still listed as a DFS replica.

Unfortunately within that short time, SERVER1’s WINS entry is still alive.

As a result, client who happened to get SERVER1 as a DFS referral talked to SERVER2 instead, which reject the request as the client principal name was incorrect, ie. not SERVER2, but SERVER1.

Turning of SERVER2 resolved this issue.

Lesson learned:

• Never reuse an IP address to build 2 servers successively, esp. not DFS root replicas.
• When turning off infrastructure server, ensure that their WINS & DNS entries are released in a timely manner.

Target account name is incorrect… when trying to map DFS shares

This was one of the problems I worked on 1 years ago…

Problem:

When some users logon to their workstation, they receive the error “Logon Failure: The target account name is incorrect” when trying to map to any shares in \\<domain>\dfsroot. As such, non of their network drives were mapped.

For some workstations, they could still map to the network drives after logon manually, but for some they received the same errors when trying to map manually. For some workstations, a secure channel reset to another DC and a reboot seems to work.

The eventlogs on the clients contains the following:

Event ID: 3034
Type: Warning
Source: MRxSmb
Description:
The redirector was unable to initialize security context or query context attributes.

Error code
0000: 00080000 00560002 00000000 80000bda
0010: 00000000 80090322 00000000 00000000
0020: 00000000 00000000 0000046c 80090322

The KB seems to point to the reason for it: http://support.microsoft.com/default.aspx?scid=kb;en-us;263208

Diagnosis and Resolution:

From a network monitor capture, it seems like the clients were referring to Server1 for DFS referral, but the IP address resolved to Server2 which is not a DFS replica, which rejected their request. Turning off Server2, seems to have resolved the issue, as client referred to an alternative DFS working replica instead.

The problem started when one of our team member built Server1 and added it as a DFS replica in our dfsroot. It was then turned off as its not in use yet. The SAME IP address was then used to build Server2. Server2 is not a DFS replica.

When client does a dfs referral for dfsroot, some of them got referred to Server1. Also the WINS entry of Server1 was still alive and not expired nor tomestoned. Thus, Server1 name was resolved to the IP address that was held by Server2 and hence the clients tried to make dfs referrals with Server2, which rejected the rejected the request. As a result, users could not map drives via our dfsroot.