DFS Site Awareness Problem

[mhiney]

Hi.

The latest piece of fun I'm having with DFS is that site awareness has gone completely out the window. I see on another website that this is symptomatic of clients not being able to see a local root replica in their own site, but have no idea why this should be - the replica is most definitely there and available. The only funny thing on my network I can think of that could be contributing to this is that we use a 22 bit netmask. Any ideas anybody?

Cheers,

mh

 

[vbrocks]

Is it shared?

 

[stevedeb]

MH,

If you are still monitoring this link, I am having the same problem w/ a stadard 24 bit mask. Did you ever find the solution? I have looked at a couple of Knowledge base articles with no sucess. It seems that clients are randomly picking referals, not going to the DFS Target that is closest (in same site).

If you found a soluion please share.

Thanks,
Steve

 

[mhiney]

Steve,

No joy I'm afraid mate. I've raised it with both HP consulting and Microsoft themselves, but they've just bluffed me. I'm beginning to think that it's due to a Group Policy Slow Link Detection setting being wrong (which was on the advice of MS, I must add).

Let's see if we can find something common in both our set ups, eh? My GP Slow Links is currently set to 0 in my Default Domain Policy, meaning that all network links are considered "fast" (I'm sure there was a valid reason for this too...)

mh

 

[stevedeb]

MH,

I don't think GP Slow Links is the issue. I have DC/GC in all sites so I know that bw is not an issue on refferral. In fact the problem happens most often (possibly only) on my main site. What I think is happening is that on my remote sites (where referrals happen properly) the server that is hosting the DFS links is also a DC/GC. On my main site DC is separate from the File/DFS server. I tried KB 824730 and it sent me to KB 246261. I had no success with these. How about you. Is you DFS server also a DC?

Steve

 

[mhiney]

Very similar setup, with DC/GC on all sites, 2Mbit between my 3 main sites and 128Kbit to smaller sattelite sites. All my root replicas are on DC/GCs, so that's not what's causing it. 246261 doesn't really apply in my case, but 304719 seems to be going somewhere - all my clients are at SP2.

 

[vbrocks]

Can you access it using a UNC?

 

[xmsre]

Do you see any 5778s in the system log?

 

[stevedeb]

MH,

My client is XP with SP1 and all applicable hot foxes from Update site. I ran a couple more updates that needed to be done, mostly security stuff. Still nothing. If I manualy set the local referral as active it works great until machine is rebooted.

Steve

 

[stevedeb]

Yes, I can access it using UNC but...
If I go to \\DFS\LINK I get the wrong referral. If I go to \\SERVER\SHARE I bypass DFS but can still get there.

 

[stevedeb]

XMSRE,

Am I lookong for 5778s in logs on DFS server, DC, or client?

Steve

 

[xmsre]

DC

 

[vbrocks]

You don't happen to have two dfs roots or links called by the same name do you?

 

[vbrocks]

Try mapping a drive to the dfs root and then accessing it...

 

[vbrocks]

I forgot to say ...

Map the drive on the server where you created the DFS Root..

 

[vbrocks]

Also make sure you have the DFS root replica on a NTFS Version 5 Partition.

 

[mhiney]

I've got 5778s, but they're a false trail cos the prob was there even before the events that could cause them occurred. I think it's AD Sites and Services freaking out over my netmask, myself. 10.x.x.x should normally be an 8 bit netmask, according to strict old-style IP rules, so those of us with 22 (or even 16 or 24) bit netmasks are probably being caught out. Something in the DFS config thinks it's still an 8 bit netmask, meaning that all servers are in the same site...

 

[stevedeb]

MH,

That's interesting. I missed your point about the mask earlier. I am using 10.x.x.x/24, also non standard. Did Miscosoft say anything about this when you called them?

Steve

 

[mhiney]

Not a word, but I think I may be on to something. I'm going through my configuration partition using softerra LDAP browser at the moment, but I seriously suspect that if this is the cause of the problem there's something hardcoded in a client DLL instead.

 

[mhiney]

OK, the problem is definitely being caused by a bug in local subnet prioritization for multihomed IP addresses. MS have a few docs on how it SHOULD work here:

http://www.microsoft.com/resources/...ocs/en-us/sag_DNS_imp_LocalSubnetPriority.asp

and here:

http://www.microsoft.com/resources/...s/en-us/sag_DNS_pro_DisableSubnetPriority.asp

(These relate to 2003 Server, but the concept is the same)

Whether the bug is client-side or server side, and whether it is definitely caused by the "more than 8 bits" netmask prob is still up in the air...