DFS w/o WINS on 2003

[DennisT]

Hi,

I have a question about DFS in a non WINS environment. The setup:

Server A - A DC, NT2003 R2 x64 SP2. Also does DNS.

Server B - Same config, another DC. Does DNS.

Both are catalog servers and both are namespace servers for the DFS shares.

I'm in the middle of a domain restructure (2000 to 2003). DFS is in the new (2003) domain. All PCs are still in the old (2000) domain. There is a trust between the domains.

The new domain is totally TCPIP. No WINS and no NetBios. All the PCs (XP/2000 Pro) have NetBios turned off.

The servers in the 2000 domain still provide and use WINS/NetBios. A check of the WINS database shows WINS only contains the 2000 domain servers info. No PCs or 2003 domain servers appear in WINS.

I have user roamimg profiles and home folders set up in DFS. Redirected folders are also in the same namespace. This is all working as desired without a problem. Users access this data using the FQDN, ie. \\ourdomain.local\User\Home\%USERNAME%

I came across "How DFS Works in Environments Without WINS" in How DFS Works. It states that I must create the DFSDnsConfig key and R&R namespaces/etc. to use DFS in a non WINS/NetBios environment.

??? I haven't done this and I've confirmed the DFSDnsConfig key doesn't exist. DFS appears to be working fine. Users can access DFS data w/o a problem. Other than an occasional file in use error there are no DFS errors in the server error logs.

Have I interpreted the article incorrectly or is it no longer valid? Maybe because I installed the DCs initally w/o WINS/Netbios I somehow avoided this requirement?

Any insight would be helpful. TIA

[DennisT]

I forgot to mention - DNS is AD intergrated.

[Stoic Joker]

I think the key point here is if you're not using either WINS or NetBIOS, then (and only then) do you have to configure DFS to use DNS only. Assuming that all your machines are in the same broadcast zone then NetBIOS can/will work for DFS name resolution.

If you had multiple subnets, sites connected by VPN, or a segmented switch (things that require routers) then you would need a WINS server for the standard UNC fileshare names to work, and likewise for DFS to work.

[DennisT]

That does bring up something I forgot to mention - Everything is in the same subnet.

My concern is that everything is working yet I haven't made the changes. So maybe you don't have to make the changes to use DFS without WINS/NetBios?

[Stoic Joker]

Well... Unless you've made a point of disabling NetBIOS, then you're using it. And if you're using it with a single subnet/broadcast zone (which you are) then it is fine as it is.

[nmX.Memnoch]

Well... Unless you've made a point of disabling NetBIOS, then you're using it.

The new domain is totally TCPIP. No WINS and no NetBios. All the PCs (XP/2000 Pro) have NetBios turned off.

Edited May 18, 2007 by nmX.Memnoch

[Stoic Joker]

Well... Unless you've made a point of disabling NetBIOS, then you're using it.

The new domain is totally TCPIP. No WINS and no NetBios. All the PCs (XP/2000 Pro) have NetBios turned off.

Gee, Let me guess ... You're trying to make me look like an id*** by pointing out a statement that I appear to have missed?

I didn't miss it, I simply ignored it because it didn't make any sense. (e.g. TCP/IP and NetBIOS are not mutually exclusive)

The point is (obviously) that one of two things has happened.

1. Using FQDNs for the share mappings is acting as a "Work-Around" for the name resolution issue.

(That's a stretch, or...)

2. NetBIOS isn't actually as disabled as he thinks it is...

Frankly my money is on option 2, as just setting NetBIOS to disabled in Local Area Connection properties doesn't actually (Completely) disable it. Feel free to spend a bit of quality time with a packet sniffer watching broadcast traffic to confirm this (I have). Also it's currently working without throwing errors, and it's working with roaming profiles which are extreemly touchy and love to fail if everything isn't perfect.

There are several registry hacks that are required to truly (and completely) disable NetBIOS, hence my assumption (based on and confirmed by the above) that NetBIOS is still (kinda) working.

Frankly due to the prevalence of legacy applications (and/or current applications that use legacy code) that require NetBOIS in some manner to function properly (or at all) it is really not recommended to try to run a DNS only domain...But I was trying to not have to go into that part.

[nmX.Memnoch]

Gee, Let me guess ... You're trying to make me look like an id*** by pointing out a statement that I appear to have missed?

I didn't miss it, I simply ignored it

Actually...no, I wasn't. I was simply pointing out that he already stated he wasn't using NetBIOS. Ignoring it and then asking the question did the job quite well.

(e.g. TCP/IP and NetBIOS are not mutually exclusive)

TCP/IP does not require NetBIOS to operate and NetBIOS does not require TCP/IP to operate. NetBIOS will work over IPX/SPX, or even NetBEUI.

[Stoic Joker]

Frankly I have better things to do with my time then argue symantics, but I'll try explaining this one more time.

Gee, Let me guess ... You're trying to make me look like an id*** by pointing out a statement that I appear to have missed?

I didn't miss it, I simply ignored it

Actually...no, I wasn't. I was simply pointing out that he already stated he wasn't using NetBIOS. Ignoring it and then asking the question did the job quite well.

The point is the While he thinks NetBIOS is (completely) disabled ... it isn't, which is why DFS is functioning and not throwing errors every time sombody attempts to access a share. My objective was to get him to confirm just how throughly NetBIOS had been "disabled" and where.

Not to mention (being that there is only one subnet/broadcast zone) that no mention of how addressing is being handled leaves the door open to a DHCP server letting the old WINS server mask the issue. (e.g. does it provide a Node Type and if so which one) DHCP servers don't care what domain you belong to trusted or not...If you're "On the Wire" you're OK.

(e.g. TCP/IP and NetBIOS are not mutually exclusive)

TCP/IP does not require NetBIOS to operate and NetBIOS does not require TCP/IP to operate. NetBIOS will work over IPX/SPX, or even NetBEUI.

So NetBIOS will work over the NetBIOS Enhanced User Interface Eh? *Sigh*

The guy that started the thread made the TCP/IP -vs- NetBIOS connection Not Me which is exactly why I ignored the statement (thanks for pointing out that you noticed its absurdity). The issue is DNS -vs- NetBIOS and does he need to add a registry key that will also require him to rebuild the DFS root from scratch.

The object here is to Help the Guy that started this thread not side track it by branishing yourself. so if you have something relevent to the issue feel free to join in, otherwise leave the space open to those of us who are actually trying to help the poor fellow

[nmX.Memnoch]

My point is I'd like to know where the information came from that going to the WINS tab and selecting 'Disable NetBIOS over TCP/IP' doesn't actually disable NetBIOS. I've seen no documentation that states even though you select 'Disable NetBIOS over TCP/IP' it's not disabled until you do some registry edit.

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

http://www.microsoft.com/resources/documen...g.mspx?mfr=true

http://www.petri.co.il/disable_netbios_in_w2k_xp_2003.htm

A simple link stating otherwise would suffice.

As for DennisT's question...I suspect that since he setup the DFS namespace using the FQDN he won't have to do anything else. If he had originally created his DFS namespace using a NetBIOS name and then turned NetBIOS off across the board I'm sure he would've had a few more steps to go through for it to continue working properly (or more correctly, to get it working again). Since he has a single subnet in a single site in a single domain in a single forest, and apparently no legacy applications, he should be fine running without NetBIOS. However, you are right in that most people don't recommend that option.

[DennisT]

I turned off NetBios by turning off NetBios over TCPIP. NBTSTAT confirms that PCs are not caching any addresses.

I suspect what has made this possible (no WINS/NetBios) is that I'm running in Native mode. I'm experiencing 0 problems even though I haven't made the changes in the article I referenced.

Edited June 4, 2007 by DennisT

[Mordac85]

The Technet article uses examples that used NetBIOS names to initially define the server names and moves from there to use dfsutil to change them to FQDN entries. If this is a domain rootdfs and he used FQDN's to add targets from the beginning, wouldn't he still function properly w/o WINS in a multiple site/WAN environment? Even if the DFS server defaults to using the netBIOS name in the referral (assumed from the lack of the DfsDnsConfig reg key on his DFS servers), when that fails I would think that DNS should pick up the slack and resolve it.

We run DFS across our environment, but we're also tied down with WINS so I can't really test the theory. But if it's working w/o WINS more power to him!