[NT4] Gebruikers worden door verkeerde BDC gevalideerd

[Wimmel]

Wij hebben een netwerk met één masterdomein en 25 resourcedomeinen verdeeld over heel Nederland. Voor elke locatie in Nederland is er een apart resourcedomein + BDC van het masterdomein ter plaatse.

Het probleem dat ik nu ondervind is het volgende:

De gebruikers van b.v. de locatie Den Haag worden normaliter gevalideerd door de BDC te Den Haag. Nu komt het regelmatig (meerdere malen per week) voor dat de validatie geschiedt door een BDC van een andere locatie.
Dit is om meerdere redenen niet gewenst, o.a. omdat de validatie langer duurt als het via een andere locatie gebeurt.

Wat is er al onderzocht:

* Het netwerk is gecontroleerd en enkele weken is vanaf meerdere werkstations op locatie Den Haag gekeken of de BDC bereikbaar blijft.
* De event viewer van de BDC van het master domein en de PDC en BDC's van het resourcedomein zijn schoon.
* d.m.v. Nltest.exe en Dommon.exe de trust gemonitored en gereset wanneer de validatie weer aan de wandel ging. <- Als de trust via een andere BDC liep was een keer resetten voldoende om de trust weer via de juiste server te laten lopen, hieruit blijkt dat de BDC in kwestie eigenlijk geen problemen heeft.

Meerdere Technet artikelen erop nageslagen waaronder Q181171, Q266729 en Q167029.
In deze artikelen worden meerdere scenario's geschetst waar de logon validatie niet via de gewenste server loopt. Eén van de mogelijke oplossingen is om in het lmhostfile van de servers van het resourcedomein de geprefereerde BDC van het masterdomein te plaatsen, helaas heeft dit als bijwerking dat als de BDC in kwestie echt niet bereikbaar is (b.v. netwerk of server probleem) de gebruikers niet kunnen aanloggen of worden gevalideerd met cached info.

Heeft iemand nog een idee waar ik verder zou kunnen zoeken of wat ik nog meer kan proberen?

Additionele info:
Alle servers en werkstations draaien WinNT 4.0 sp6a
Alle servers staan met de juiste 1c entry in wins.
Alle servers hebben een statisch IP-adres en staan ook netjes vermeld in DNS.
De BDC van het masterdomein staat in hetzelfde sub-net als het resourcedomein.

[elevator]

Het node-type zou je eventueel op (iirc) m-node kunnen zetten, dan zou hij eerst een broadcast moeten doen en daarna pas de WINS moeten queryen.

[Wimmel]

Ik zal dat maandag even checken, misschien dat ik ik dat even kan proberen.
Weet jij of er nog andere consequenties aan verbonden zijn als ik het node type aanpas?

[Zwelgje]

Wimmel schreef op 03 augustus 2002 @ 16:20:
Ik zal dat maandag even checken, misschien dat ik ik dat even kan proberen.
Weet jij of er nog andere consequenties aan verbonden zijn als ik het node type aanpas?

dat je heel veel broadcast verkeer kan gaan krijgen op je netwerk, maar voor troubleshooting puposes is het wel te doen, client gaan immers gelijk 'schreeuwen' op het lan alvoren wins te raadplegen

[elevator]

idd, wat zwelgje zegt. Als je ook niet al te veel clients ( < 40 oid) hebt, kan het ook verder weinig kwaad, als is het netter om hem op H-type te laten staan.

[Wimmel]

Jammer genoeg hebben we het over >1000 gebruikers, maar ik zal maandag even verder kijken. Voor nu alvast bedankt voor het meedenken.

[elevator]

op een locatie? Misschien dat die DC dan gewoon niet 'snel' genoeg is ?

[Koffie]

Move NT -> PNS

[Verwijderd]

Heb je setprfdc uit Q167029 gebruikt? Zet anders eens een 2e BDC ( desnoods tijdelijk een opgefokte desktop ) op een locatie en kijk hoe vaak het voorkomt dat er nog steeds over het WAN gevalideerd wordt. Met inloggen kijkt NT wie het snelt reageerd. Als je BDC net iets aan het doen is kan het zijn dat een DC over het WAN sneller is.

[igmar]

elevator schreef op 03 augustus 2002 @ 15:55:
Het node-type zou je eventueel op (iirc) m-node kunnen zetten, dan zou hij eerst een broadcast moeten doen en daarna pas de WINS moeten queryen.

Dit zou ik niet doen.. Dit help in sommige gevallen bijzonder en snel je LAN om zeep, zeker als de bandbreedte wat kleiner is.

Ik zou even een networksniffer op het netwerk zetten om te kijken wat er nu werkelijk gebeurd, desnoods in combinatie met een bridging bak om het verkeer van de BDC te sniffen.

[elevator]

als er idd 1000 pc's op een segment zitten is het niet handig.

Heb je het echter over 25 PC's ofzo, dan is het geen mooie oplossing, maar dat beetje broadcast traffic kan een fatsoenlijk lan toch echt wel aan. Het aantal resolves wat je normaal gesproken doet valt namelijk erg tegen (1 of 2 file/print servers en de rest doe je met DNS normaal gesproken).

om Microsoft nog even te quoten (uit Q119493):

M-node is typically not the best choice for larger networks because it uses b-node and thus results in broadcasts. However, when you have a large network that consists of smaller subnetworks connected via slow Wide Area Network (WAN) links, M-node is a preferred method since it will reduce the amount of communication across the slow links.

[Wimmel]

Verwijderd schreef op 04 augustus 2002 @ 12:17:
Heb je setprfdc uit Q167029 gebruikt? Zet anders eens een 2e BDC ( desnoods tijdelijk een opgefokte desktop ) op een locatie en kijk hoe vaak het voorkomt dat er nog steeds over het WAN gevalideerd wordt. Met inloggen kijkt NT wie het snelt reageerd. Als je BDC net iets aan het doen is kan het zijn dat een DC over het WAN sneller is.

setprfdc.exe heb ik ook gebruikt, heb je trouwens enig idee hoe moeilijk je daar aan kunt komen? Het staat alleen op de originele sp4 cd. Downloaden bij MS is me niet gelukt.

Voor de andere suggesties geldt dat ik maandag even verder kijk.

[Brahiewahiewa]

't Is een wijdverbreid misverstand dat M-node clients dramatisch meer broadcasts zouden veroorzaken dan H-node of P-node clients. Aan het raadplegen van de WINS server gaat namelijk meestal ook een ARP broadcast vooraf. Dus de hoeveelheid broadcasts van M-node clients is hoegenaamd hetzelfde als die van H-node clients en de hoeveelheid netwerk verkeer is zelfs minder (NetBIOS broadcast + NetBIOS antwoord is slechts twee pakketjes; ARP broadcast + ARP antwoord + WINS query + WINS antwoord = 4 pakketjes)
Kortom: geen enkele reden om geen M-node clients te gebruiken

[Aetje]

iig is het een latency probleem: De WAN BDC's kunnen eerder reageren dan de LAN-BDC. Lijkt me dat de LAN-BDC ietwat overloaded is. Wellicht een idee om hem eens een dag lang continu te pingen, kijken wat de max/min statistieken zijn (uitvoer natuurlijk naar textfile ipv scherm dmv ping BDC -t > C:\Output.txt)
Als de BDC ook als lokale fileserver dient, is het wellicht idd raadzaam een piepklein desktopje als dedicated BDC neer te zetten...