[NT4] Waarom werkt NET USE hier niet?

[CmdrKeen]

Een raar probleem deze keer. Ons bedrijf heeft drie vestigingen die met routers aan elkaar zijn geknoopt. De vestigingen zijn klonen van elkaar: er is een Windows NT4-server en Win9x-clients.
In de hoofdvestiging staat een internet-gateway achter een firewall. De twee andere vestigingen netwerken en internetten via vestiging A.

Vestiging A: hoofdvestiging, i-netgateway, firewall
Vestiging B en C: via router naar vestiging A.

Om te testen heb ik op de firewall en op de routers alle poorten opengezet.

Het probleem: vestiging B kan internetten en netwerken in vestiging A, maar vestiging C kan alleen internetten. Met het commando NET USE F: \\SERVER\SHARE maak ik in vestiging B en C een netwerkverbinding voor de clients, maar in C kan dat dus niet: "kan de netwerklokatie niet vinden".

Van C kan ik pingen naar A, maar WINS, dat in A werkt, is niet beschikbaar in C. In B werkt dit wél op die manier. Het rare vind ik dat B en C identieke netwerkinstellingen hebben, maar dat het in C goed gaat en in B niet.. Ik kan vanuit elke vestiging met pcAnywhere computers in alle andere vestigingen overnemen.

WINS is trouwens niet het probleem omdat NET USE F: \\192.168.0.100\SHARE evengoed niet werkt. Ik heb ik vest. B drie verschillende clients met W2k, 98 en NT4 getest, naar verschillende shares op verschillende servers waarbij de rechten op de share "alle voor iedereen" waren. Elke vestiging heeft z'n eigen domein, maar overal bestaan dezelfde useraccounts met dezelfde passwords. Dit werkt vanuit C naar A goed, maar vanuit B dus niet.

De MSKB leert mij dat het NET-commando een sessie moet opzetten, en PING niet. Daartoe moet TCP-poort nummer 139 (ff uit 't koppie) openstaan op alle routers - maar álles staat wagenwijd open.

De melding die ik krijg is dat de netwerkshare niet gevonden kan worden, terwijl ik zeker weet dat die bestaat. Ook weet ik zeker dat het account recht heeft om in de share te komen.

De netwerksnelheid is gegarandeerd 256kb up en down tussen alle vestigingen onderling.

Waarom werkt NET USE hier niet?

/Edit
Ik had uiteraard ook al in GoT en met Google gezocht, in de Microsoft Knowlegde Base en de diverse sites over Windows NT en zo. De leverancier van de DSL-lijnen heeft me ervan verzekerd dat ALLE netwerkverkeer op ALLE poorten met ALLE protocollen wordt doorgelaten door de tunnels.

[Zwelgje]

welke ip ranges gebruik je op de verschillende vestigingen?

[veldmuis]

je weet zeker dat ie bestaat
wat zegt net view \\server

[CmdrKeen]

Op woensdag 10 juli 2002 21:12 schreef zwelgje het volgende:
welke ip ranges gebruik je op de verschillende vestigingen?

In A:
10.0.0.0 netmask 255.255.255.0 (hoofdvestiging)

In B:
10.0.10.0 netmask 255.255.255.0 (deze werkt niet)

In C:
192.168.0.0 netmask 255.255.255.0 (deze werkt wél)

Overigens hééft het vanuit B wél gewerkt, alleen met ISDN-routers. We gebruiken nu DSL-routers.

[CmdrKeen]

Op woensdag 10 juli 2002 21:12 schreef veldmuis het volgende:
je weet zeker dat ie bestaat
wat zegt net view \\server

NET VIEW \\SERVER geeft alle bestaande shares, incl. printers, maar vanaf B kan ik A niet bekijken. Even op A gecontroleerd: check en double-check. De share bestaat 750% zeker weten. (De werkelijke naam van de share is \\NTSERVER01\Data, dus daar vallen ook weinig typfouten in te maken..)

[Verwijderd]

er staat waarschijnlijk toch nog ergens een verkeerde rule in 1 of andere firewall.

Permissies kloppen wel?

Verkeerde (evt.) statische routes?

[Verwijderd]

hmm.. en als je nu in vestiging B ook eens op ip-range 192.168.0.0 gaat zitten? wat voor effect krijg je dan?

of moet je dan ook in vestiging A op je servers allerlei settings gaan aanpassen?

[CmdrKeen]

Op woensdag 10 juli 2002 21:20 schreef arjo_kamp het volgende:
er staat waarschijnlijk toch nog ergens een verkeerde rule in 1 of andere firewall.

Permissies kloppen wel?

Verkeerde (evt.) statische routes?

Er is maar één firewall en het enige dat die doet is verkeer voor 10.0.10.0 doorsturen naar de router (10.0.0.3). Dit werkt voor de andere vestiging ook. Ik heb die ene rule gekopieerd en aangepast naar het andere subnet. Dit werkt goed omdat men er ook langs kan internetten.

De permissies kloppen, want iedereen heeft nu alle rechten op alle apparaten; dit juist om uit te sluiten dat het een rechten-probleem is.

De routes zijn in orde, anders had ik de computers niet kunnen overnemen met pcAnywhere en niet kunnen pingen. Toch?

[CmdrKeen]

Op woensdag 10 juli 2002 21:21 schreef Chief_BoZ het volgende:
hmm.. en als je nu in vestiging B ook eens op ip-range 192.168.0.0 gaat zitten? wat voor effect krijg je dan?

of moet je dan ook in vestiging A op je servers allerlei settings gaan aanpassen?

Helaas kan ik de instellingen van de routers niet aanpassen, maar zoals ik hierboven schreef: als dat het probleem zou zijn, dan zou ik toch ook niet kunnen pingen e.d.?

Dat van dat pingen en overnemen met pcAnywhere (en het feit dat men in alle vestigingen via de hoofdvestiging kan internetten) doen mij vermoeden dat de routing dik in orde is, maar aangezien het tussen twee vestigingen goed werkt en maar bij eentje niet, en de vestigingen klonen van elkaar zijn, lijkt mij dat ook niet het probleem.

Zelden heb ik een vager probleem meegemaakt...

[Predator]

[forum=24] -> [forum=19]
Vaag probleem of niet, dit is toch wel NT

[elevator]

Op woensdag 10 juli 2002 21:27 schreef Vilenin het volgende:
Zelden heb ik een vager probleem meegemaakt...

Vanuit site b, telnetten naar poort 139 op de ntserver01, lukt dat wel? (krijg je connectie of breekt telnet af?)

Als dat al niet lukt (en op site c wel), dan is er ergens een blokkade op poort 139

[Brahiewahiewa]

Doe in locatie B eens achtereenvolgens

code:

tracert NTSERVER01
ping NTSERVER01
ping <IP-adres van NTSERVER01>

en laat hier zien wat het resultaat is.
En weet je zeker dat in locatie A en B het netmask 255.255.255.0 is en niet 255.0.0.0 ?

[CmdrKeen]

Telnetten naar poort 139 werkt gewoon.

code:

tracert NTSERVER01

Unable to resolve target system name ntserver01.


ping NTSERVER01

Bad IP address ntserver01.


ping <IP-adres van NTSERVER01>

Pinging 10.0.0.1 with 32 bytes of data:

Reply from 10.0.0.1: bytes=32 time=20ms TTL=124
Reply from 10.0.0.1: bytes=32 time=20ms TTL=124
Reply from 10.0.0.1: bytes=32 time=20ms TTL=124
Reply from 10.0.0.1: bytes=32 time=20ms TTL=124

Pingen heb ik trouwens op aanraden van MS (Q142027) ook geprobeerd met grotere pakketten: Ping <IP-adres> -l 8000 enzo. Om te kijken of niet alleen hele kleine pakketjes worden doorgelaten.

En weet je zeker dat in locatie A en B het netmask 255.255.255.0 is en niet 255.0.0.0 ?

Ja. Check en double-check. Triple-check. Heel zeker: het heeft namelijk een hele tijd gewerkt, *tot* we andere routers gingen gebruiken (van ISDN naar DSL).

Check:

[Sn3akz]

Als ik het zo zie ligt of je WINS systeem, of je DNS systeem, of je Netbios-name niet helemaal lekker.. want als je gewoon een rauw ip invult pakt ie hem wel..

Probeer eens
\\ipadres\share

Kijken wat dat geeft...

Suc6

[CmdrKeen]

Al geprobeerd.. nu opnieuw geprobeerd: zelfde foutmelding als wanneer ik de naam gebruik.

[collin]

Staat op die probleem PC "Enable NETBIOS over TCP/IP" aan? Lijkt er wel heeeel sterk op namelijk..
[edit] durf er een virtueel kratje bier op te zetten

[Brahiewahiewa]

Op donderdag 11 juli 2002 17:47 schreef collin het volgende:
Staat op die probleem PC "Enable NETBIOS over TCP/IP" aan? Lijkt er wel heeeel sterk op namelijk..
[edit] durf er een virtueel kratje bier op te zetten

Kom maar op met dat kratje. Als je nou het hele topic had gelezen, had je gezien dat er geen sprake is van een "probleem PC" maar van een "probleem vestiging". Wel errug toevallig dat ineens op alle PC's NetBIOS over TCP/IP uit zou staan, na het vervangen van de routers. _{Letop: gaatie zeggen dat je port 139 op je routers open moet zetten; kost'm weer een kratje}
Vilenin: Je moet in ieder geval je naam resolutie fixen. Hoe was die geregeld voordat je de routers verving? WINS? DNS? LMHOSTS files? Kan het zijn dat je WINS server nog naar een verkeerde gateway point, zodat vestiging B niet met de WINS server kan praten?

[Zwelgje]

check inderdaad die wins database eens, (of haal hem desnoods leeg en laat hem opnieuw vullen (nbtstat -RR op de servers doen, om te opnieuw te laten registreren in de database, de clients kunnen dan herstart worden om zichzelf opnieuw te reggen)

[Brahiewahiewa]

Op donderdag 11 juli 2002 22:16 schreef zwelgje het volgende:
[..]nbtstat -RR[..]

...op NT4
'k Zou ook, alvorens te besluiten het hele machine park te rebooten, eerst proberen of je het probleem niet intelligent op kunt lossen (NOFI)

[collin]

euh
Maar als hij ook niet naar een share \\ip.add.res.je\share kan verbinden, heeft het dus nix meer met WINS te maken (feit is wel dat WINS niet werkt, maar laat dat nou ook Netbios over TCP/IP verkeer zijn). Het kan bijna niet anders dan dat het te maken heeft met Netbios over TCP/IP over de B - A link. Als het voorheen wel werkte en nu niet, KAN het in mijn opinie aan niets anders liggen dan aan de configuratie van de B - A verbinding. Mijn virtuele kratje bier blijft uit staan

Kan je niet met RAS vanaf een PC in B inbellen op een RAS server in A? Kijken of je dan wel naar een share kan verbinden.

Op donderdag 11 juli 2002 10:22 schreef Vilenin het volgende:
het heeft namelijk een hele tijd gewerkt, *tot* we andere routers gingen gebruiken (van ISDN naar DSL).

Is dan toch zo klaar als een klontje waar het aan ligt lijkt me?

[elevator]

Op donderdag 11 juli 2002 10:22 schreef Vilenin het volgende:
Telnetten naar poort 139 werkt gewoon.

Fantastisch.

Nu zie ik dat je zowel Win98 als NT4 clients gebruikt, Win98 heeft de vervelende gewoonte als ik het me goed herinner om geen IP addressen te kunnen gebruiken bij het browsen van shares.

Heb je de test die hierboven gegeven is (\\ip-address\share) op de NT4 WKS uit gevoerd, of toevallig op een Win9x machine ?

Wat geeft een 'nbtstat -n' en wat geeft 'nbtstat -r' nadat je een 'net view \\ntserver01' gedaan hebt ?

[Zwelgje]

Op donderdag 11 juli 2002 22:34 schreef Brahiewahiewa het volgende:

[..]

...op NT4
'k Zou ook, alvorens te besluiten het hele machine park te rebooten, eerst proberen of je het probleem niet intelligent op kunt lossen (NOFI)

ja hoor nbtstat -RR werkt ook op nt4 (net getest overigens)

het hele machinepark rebooten is geen intelligente oplossing een aantal routers plots vervangen dan wel? lijkt me ook niet al te slim dan...

[Brahiewahiewa]

Op donderdag 11 juli 2002 22:46 schreef zwelgje het volgende:
[..]
ja hoor nbtstat -RR werkt ook op nt4 (net getest overigens)

Je hebt helemaal gelijk; ik verwarde 't met IPCONFIG /RegisterDNS, wat niet werkt in NT4

het hele machinepark rebooten is geen intelligente oplossing een aantal routers plots vervangen dan wel? lijkt me ook niet al te slim dan...

Klopt, maar da's nog geen reden om het dan maar te doen. Niet eens zozeer omdat de actie wel of niet slim zou zijn, maar omdat 't een gok is; je weet niet of 't gaat helpen
_{...of zet je ook een kratje bier in?}

[CmdrKeen]

Op donderdag 11 juli 2002 21:31 schreef Brahiewahiewa het volgende:
Vilenin: Je moet in ieder geval je naam resolutie fixen. Hoe was die geregeld voordat je de routers verving? WINS? DNS? LMHOSTS files? Kan het zijn dat je WINS server nog naar een verkeerde gateway point, zodat vestiging B niet met de WINS server kan praten?

WINS in vest. B staat via de DHCP-service van de lokale server gericht op de WINS-service op diezelfde server, omdat de clients ook Outlook draaien en die naar een Exchange-server op naam zoeken. Dit werkt voor de clients.
De lokale server draait er dus WINS, maar de WINS-instelling op die server is de server in de hoofdvestiging, omdat ik daarmee de verbinding getest heb, het voor de clients niet uitmaakt, en de server natuurlijk geen Outlook draait.
De clients kunnen dus wél gewoon pingen op naam naar vest. A, omdat de lokale WINS-server gevonden kan worden.

Ik had er van tevoren trouwens bij moeten vertellen dat:
- het complete serverpark al gereboot was
- ik in vest. B clients met Windows 95, 98, NT4, 2k en XP heb geprobeerd, ook als de lokale server uit stond

Overigens heb ik IIS in vest. A op een client aangezet op poort 80 en vanuit B en C gekeken. Dat werkte. Op poort 139 kreeg ik echter vreemde resultaten: in C was de uitkomst enkele vreemde tekens op een verder lege pagina (de testpagina was rood met in gele letters: "TEST") en in B kon de pagina niet gevonden worden!
De twee FTP-servers die ik geprobeerd heb, kunnen niet op poort 139 draaien!

Zou het dan toch aan de poort liggen? Het lijkt er sterk op, hoewel de aanbieder van de tunnel (Versatel) zegt dat ALLES, maar dan ook ALLES aan netwerkverkeer wordt doorgelaten; bovendien werkte het via de oude routers prima.

[Brahiewahiewa]

Effe hoor. Je probeert wel erg veel tegelijk te zeggen.
- Er staat aan WINS server in locatie B
- Clients in locatie B krijgen via DHCP een IP adres en een pointer naar de WINS server in locatie B

Dat begrijp ik. Dan:

- De WINS server in locatie B verwijst zelf, in z'n eigen TCP/IP propertie, naar de WINS server in locatie A

Zo werkt WINS niet. Als je wilt dat clients in locatie B hostnames uit locatie A kunnen resolven naar IP-adressen, dan zul je WINS replicatie moeten configureren.
Als jij het daadwerkelijk op de bovenbeschreven manier hebt ingericht, heeft het waarschijnlijk nooit gewerkt, maar heb je pas na het veranderen van de routers gecontroleerd of het werkt en denk je nu dat het aan de routers ligt.

De clients kunnen dus wél gewoon pingen op naam naar vest. A, omdat de lokale WINS-server gevonden kan worden.

Hoe verklaar je dan je vorige posting:

code:

tracert NTSERVER01
Unable to resolve target system name ntserver01.

ping NTSERVER01
Bad IP address ntserver01.

Dat betekent toch ècht dat een client geen name resolution heeft, dus niet op naam kan pingen. Of kan het nu ineens wel?

[Goost]

Staat de replicatie tussen de WINS-servers aan?

[Verwijderd]

een tussentijdse oplossing zou kunnen zijn dat je even een host tabel aanmaakt. Geen elegante oplossing, maar je kunt dan wel even werken.

Het probleem is dat er geen name resolution mogelijk is. Hetzij via wins, hetzij via dns. Wat zijn de instellingen daarvan?

Je zegt dat jullie zijn overgegaan naar DSL, levert je SP toevalling een DNS server adres?

[CmdrKeen]

* De clients in B kijken naar de WINS-service die in B draait. Daar zijn static mappings gemaakt voor alle servers in het hele WAN. De clients kunnen dus gewoon het IP resolven, maar via de server in B, en niet via de server in A. De clients hebben name-resolving nodig om Outlook te kunnen gebruiken, aangezien Exchange in A draait.

* De server in B kijkt voor WINS niet zoals gebruikelijk is naar zichzelf, maar naar de server in A.

* Het is niet de bedoeling dat de WINS-tabel in A naar B gerepliceerd wordt. Dat is nooit mijn opzet geweest.

Bovenstaande situatie is misschien ongebruikelijk, maar er is volgens mij niets mis mee.

Bovendien: of je nou wel of geen WINS gebruikt, je zou überhaupt moeten kunnen connecten naar een share op deze manier: NET USE \\10.0.0.1\data. Zo niet vanaf een 9x-clients, dan wel vanaf een 2k-client.

De DNS-adressen zijn in alle vestigingen hetzelfde ingesteld; het zijn de primaire en secundaire nameservers van de provider. Internetten gaat prima in alle vestigingen.

[elevator]

Op vrijdag 12 juli 2002 08:36 schreef Vilenin het volgende:

[http server op tcp/139]

testpagina was rood met in gele letters: "TEST") en in B kon de pagina niet gevonden worden!
De twee FTP-servers die ik geprobeerd heb, kunnen niet op poort 139 draaien!

ehm. Je zei eerder dat je wel kon telnetten naar port 139.

Nu je een IIS op 139 hebt gezet, telnet dan nog eens. Krijg je verbinding? Wat doet het als je een paar keer op enter ramt ?

[collin]

Zucht als je vanaf een NT4 of hoger machine NIET kan verbinden naar \\ip.van.server.in.a\share heeft het al NIETS MAAR DAN OOK NIETS meer met name resolving te maken (nameresolving werkt wel niet, maar da's NIET de reden dat hij niet naar shares kan verbinden).

ALLES werkt maar dan ook alles, BEHALVE NetBIOS over TCP/IP. Die knakkers van je verbindingen moeten dit gewoon fix0ren! Laat ze maar op komen draven, ligt 100% zekers daaraan wat mij betreft..

[Brahiewahiewa]

Op vrijdag 12 juli 2002 10:43 schreef Vilenin het volgende:
[..]
Bovendien: of je nou wel of geen WINS gebruikt, je zou überhaupt moeten kunnen connecten naar een share op deze manier: NET USE \\10.0.0.1\data. Zo niet vanaf een 9x-clients, dan wel vanaf een 2k-client.
[..]

Klopt. Als NET USE \\10.0.0.1\data vanaf een Win2k client niet werkt heb je waarschijnlijk ergens toch NetBIOS dicht staan. Overigens krijg je ook wel eens de "kan netwerk locatie niet vinden" als je geen account hebt in het target domain.

Probeer voor de zekerheid effe:

code:

NET USE \\10.0.0.1\ipc$ /u:<domain>\<user>

Waarbij <domain> het domein is waar de server in staat en <user> een user in dat domein. Je krijgt ook nog een prompt voor een password

Als je redelijk snel wilt weten wat er precies aan de hand is, zou 'k Network Monitor (van MS SMS) installeren, zowel op een client als op de server. Dan kun je aan twee kanten tracen wat er over je netwerk gaat en kun je dus zien of je router eventueel ports blokkeert of packets dropt. Ook eventuele name resolutie problemen zie je dan meteen. Een ander sniffer pakket voldoet ook, overigens, 't is maar wat je het prettigst vind werken.

[Brahiewahiewa]

Op vrijdag 12 juli 2002 11:49 schreef collin allemaal hoofdletters:
Denk je een beetje om je bloeddruk, jongen?

[collin]

Op vrijdag 12 juli 2002 11:54 schreef Brahiewahiewa het volgende:
Op vrijdag 12 juli 2002 11:49 schreef collin allemaal hoofdletters:
Denk je een beetje om je bloeddruk, jongen?

10-4

[CmdrKeen]

Collin, Brahie, anderen... Bedankt voor jullie inzet. Het probleem is gevonden en opgelost.

Zoals hierboven al geopperd, was dit de oplossing: we hebben het LAN in de reeks 192.168.1.0/255.255.255.0 gezet.

Dat kon eerst niet, omdat we niet zelf het adres van de router konden aanpassen, maar de tunnel-provider (Versatel) heeft een handje meegeholpen. Dit was ook de reden dat ik dit eerder niet kon testen.

Versatel had eerder gezegd dat het gebruik van de reeks 10.0.10.0/255.255.255.0 geen conflicten met hun tunnel zou geven, maar dit blijkt toch anders uit te pakken.

Nogmaals bedankt voor jullie hulp!