[Win2K] "Computers Near Me" erg traag

[Mr. B.]

Goed, om te beginnen ff een overzicht van de setup hier:

Server:
• Pentium 233 MMX, 128 MB
• NetBIOS naam: SPITFIRE
• IP: 192.168.0.1
• Debian Linux (woody, kernelversie 2.2.19) met Samba 2.2.3a-12 (standaard Debian package)
• Standaard Farallon kaartje (DEC 21041 chipset) van @Home
• 3Com 3C905TX-M NIC voor het interne netwerk

Client 1: (familiebak)
• Athlon XP 1600+, 256 MB
• NetBIOS naam: HURRICANE
• IP: 192.168.0.2
• Windows 98 Second Edition
• Realtek 8139 NIC

Client 2: (laptop)
• Celeron 1.33 GHz, 256 MB
• NetBIOS naam: THUNDERBOLT
• IP: 192.168.0.3
• Windows 2000 Pro SP3
• Intel PRO/100 Mobile NIC

Client 3: (mijn workstation)
• Athlon XP 1800+, 768 MB
• NetBIOS naam: MUSTANG
• IP: 192.168.0.4
• Windows 2000 Pro SP3
• Intel PRO/100 S NIC

Het netwerk hangt aan elkaar met CAT5 kabels en een Enermax 100 MBit hub.
Beide Win2000 machines en de Win98 bak zijn volgens WindowsUpdate helemaal bijgewerkt, en ook de Debian bak is helemaal up-to-date qua geïnstalleerde packages.

Het probleem: op beide Windows 2000 machines werkt het openen van Computers Near Me onder My Network Places, dus het opvragen van de beschikbare pc's binnen het netwerk, erg traag. Het werkt wel, maar het duurt een hele tijd voor de pc's zichtbaar zijn. In die tijd "hangt" het venster gewoon.

Enkele feiten:
• Op de Windows 98 machine werkt het openen van Network Neighborhood wel goed, alle pc's zijn daar meteen zichtbaar.
• In Win2000 SP3 draaiend onder VMware (met als host machine m'n workstation) werkt het ook probleemloos.
• De pc's direct benaderen en de beschikbare shares opvragen (dus bv. door direct \\MUSTANG of \\192.168.0.4 te openen) werkt ook prima.
• Files kopiëren en het gebruik van de beschikbare shares: eveneens geen enkel probleem.
• Ik heb even geprobeerd de laptop in safe mode met netwerksupport te booten: zelfs dan treedt het probleem op.

Het gaat dus alleen fout bij beide Win2000 installaties, maar ik heb erg weinig zin in het rewinnen van 2 machines die verder prima werken.

Ik heb dit probleem al een tijdje, maar geen flauw idee wat de oorzaak is... iemand een idee waar het aan kan liggen?
Alvast bedankt

[Verwijderd]

misschien omdat je een isa geluidskaart hebt met condensatoren die een soort magnetisch veld ontwikkeld om je netwerkkaart

[Mr. B.]

Verwijderd schreef op 17 januari 2003 @ 18:08:
misschien omdat je een isa geluidskaart hebt met condensatoren die een soort magnetisch veld ontwikkeld om je netwerkkaart

Misschien moet ik je voortaan IRL vragen om naar zo'n topic te kijken en niet op IRC... dan kan ik tenminste vantevoren zien dat je gezopen hebt

[maratropa]

helpt dit:

Here's a great tip (a bug actually) to speed up your browsing of Windows 2000 machines. Its actually a fix to a bug that by default of a normal Windows 2000 setup that scans for shared files for Scheduled Tasks. And its turns out that you can experience a delay as long as 30 seconds when you try to view shared files across a network from as Windows 2000 is using the extra time to search the remote computer. Note that though the fix is originally intended for only those affected, Windows 2000 users will experience that actual browsing speed of both the Internet & Windows Explorers improving significantly after applying it since it doesnt search for the Scheduled Tasks anymore. Here's how :

Open up the Registry and go to :

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/Current Version/Explorer/RemoteComputer/NameSpace

Under that branch, select the key :

{D6277990-4C6A-11CF-8D87-00AA0060F5BF}

and delete it.


This is key that instructs Windows to search for Scheduled Tasks. If you like you may want to export the exact branch so that you can restore the key if necessary. This fix is so effective that it doesn't require a reboot and you can almost immediately determine yourself how much it speeds up your browsing processes

[Mr. B.]

gladiool schreef op 17 January 2003 @ 18:09:
helpt dit:

Here's a great tip (a bug actually) to speed up your browsing of Windows 2000 machines. Its actually a fix to a bug that by default of a normal Windows 2000 setup that scans for shared files for Scheduled Tasks. And its turns out that you can experience a delay as long as 30 seconds when you try to view shared files across a network from as Windows 2000 is using the extra time to search the remote computer. Note that though the fix is originally intended for only those affected, Windows 2000 users will experience that actual browsing speed of both the Internet & Windows Explorers improving significantly after applying it since it doesnt search for the Scheduled Tasks anymore. Here's how :

Open up the Registry and go to :

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/Current Version/Explorer/RemoteComputer/NameSpace

Under that branch, select the key :

{D6277990-4C6A-11CF-8D87-00AA0060F5BF}

and delete it.


This is key that instructs Windows to search for Scheduled Tasks. If you like you may want to export the exact branch so that you can restore the key if necessary. This fix is so effective that it doesn't require a reboot and you can almost immediately determine yourself how much it speeds up your browsing processes

Tnx, maar die key is op beide machines al verwijderd Ik kende die tip al, maar die heeft niks met mijn probleem te maken... die is van toepassing op het weergeven van de shares op een pc, niet op het weergeven van de pc's zelf.

[Verwijderd]

Er is iets mis dus met de netwerkbrowsing.

Op de W2K CD staan ook de support tools.
Hierin zit ook een tool genaamd browstat.exe in.
Voer deze eens uit met de juiste parameter.


In de resource kit zit ook nog een andere tool genaamd browmon.exe, voer deze tool ook eens uit. ?

En post de ouput hier

[Angelfire]

Wellicht helpt het installeren van een WINS service?? Of je NETBIOS broadcast op 0x4 zetten. Ik weet niet uit mijn hoofd hoe, als je DHCP gebruikt kan je meestal optie: 046 WINS?NBT node type instellen.

[Mr. B.]

Verwijderd schreef op 17 januari 2003 @ 18:18:
Er is iets mis dus met de netwerkbrowsing.

Op de W2K CD staan ook de support tools.
Hierin zit ook een tool genaamd browstat.exe in.
Voer deze eens uit met de juiste parameter.


In de resource kit zit ook nog een andere tool genaamd browmon.exe, voer deze tool ook eens uit. ?

En post de ouput hier

Ik neem aan dat je wilt kijken welke pc de master browser is?
Dat heb ik al gecheckt mbv nbtstat en nmblookup; die rol heeft de Linux bak keurig op zich genomen.
Maar ik zal ff die tooltjes opsnorren

[Mr. B.]

De output van "browstat.exe status":

code:

[Win2K]C:\PROGRA~1\SUPPOR~1>browstat status


Status for domain WW2PLANES on transport \Device\Nbf_NdisWanNbfOut{20C08518-7BA5
-4C3B-B6CD-9E64982FD97E}
    Browsing is NOT active on domain.
    Master name cannot be determined from GetAdapterStatus.


Status for domain WW2PLANES on transport \Device\Nbf_NdisWanNbfOut{0F50930E-352C
-4E57-9163-43C87F1D18D1}
    Browsing is NOT active on domain.
    Master name cannot be determined from GetAdapterStatus.


Status for domain WW2PLANES on transport \Device\Nbf_NdisWanNbfOut{7FC7E806-115F
-41AB-B6EF-51C497AA6A60}
    Browsing is NOT active on domain.
    Master name cannot be determined from GetAdapterStatus.


Status for domain WW2PLANES on transport \Device\Nbf_NdisWanNbfIn{19561F82-DBBA-
4C2C-B208-AFB5396DD790}
    Browsing is NOT active on domain.
    Master name cannot be determined from GetAdapterStatus.


Status for domain WW2PLANES on transport \Device\Nbf_NdisWanNbfIn{1B3481BF-3567-
45B6-B3DB-FFC7590B65EE}
    Browsing is NOT active on domain.
    Master name cannot be determined from GetAdapterStatus.


Status for domain WW2PLANES on transport \Device\Nbf_NdisWanNbfIn{3A101ADB-0EC7-
4E09-94AD-6C692621F1F9}
    Browsing is NOT active on domain.
    Master name cannot be determined from GetAdapterStatus.


Status for domain WW2PLANES on transport \Device\NetBT_Tcpip_{5B5CA991-E856-4926
-B66A-76E437763EB7}
    Browsing is active on domain.
    Master browser name is: MUSTANG
Could not connect to registry, error = 53        Unable to determine build of br
owser master: 53
    \\\\MUSTANG       .  Version:05.00  Flags: 51003 NT POTENTIAL MASTER
    1 backup servers retrieved from master MUSTANG
        \\SPITFIRE
    Unable to retrieve server list from MUSTANG: 71


Status for domain WW2PLANES on transport \Device\NetBT_Tcpip_{D698E0B8-B9EB-4D2C
-85E6-53001BEBFC15}
    Browsing is active on domain.
    Master browser name is: MUSTANG
Could not connect to registry, error = 53        Unable to determine build of br
owser master: 53
    \\\\MUSTANG       .  Version:05.00  Flags: 51003 NT POTENTIAL MASTER
    1 backup servers retrieved from master MUSTANG
        \\MUSTANG
    There are 1 servers in domain WW2PLANES on transport \Device\NetBT_Tcpip_{D6
98E0B8-B9EB-4D2C-85E6-53001BEBFC15}
    There are 1 domains in domain WW2PLANES on transport \Device\NetBT_Tcpip_{D6
98E0B8-B9EB-4D2C-85E6-53001BEBFC15}


Status for domain WW2PLANES on transport \Device\NetBT_Tcpip_{CA0FB1C8-715F-4371
-8803-2F73308E39C1}
    Browsing is active on domain.
    Master browser name is: MUSTANG
Could not connect to registry, error = 53        Unable to determine build of br
owser master: 53
    \\\\MUSTANG       .  Version:05.00  Flags: 51003 NT POTENTIAL MASTER
    1 backup servers retrieved from master MUSTANG
        \\MUSTANG
    There are 1 servers in domain WW2PLANES on transport \Device\NetBT_Tcpip_{CA
0FB1C8-715F-4371-8803-2F73308E39C1}
    There are 1 domains in domain WW2PLANES on transport \Device\NetBT_Tcpip_{CA
0FB1C8-715F-4371-8803-2F73308E39C1}

De resource kit heb ik niet, dus browmon.exe heb ik niet kunnen proberen.

[Mr. B.]

Angelfire schreef op 17 January 2003 @ 18:19:
Wellicht helpt het installeren van een WINS service?? Of je NETBIOS broadcast op 0x4 zetten. Ik weet niet uit mijn hoofd hoe, als je DHCP gebruikt kan je meestal optie: 046 WINS?NBT node type instellen.

Waarom zou ik een WINS service nodig hebben... het hoort zo ook te werken (en dat doet het ook, behalve op beide Win2000 machines).

Op de Windows machines zijn trouwens alleen TCP/IP, Client for MS Networks en Windows File/Printer sharing in gebruik, het toevoegen van NetBEUI heeft geen effect. De familiebak en m'n workstation hebben een vast IP, de laptop krijgt het via de DHCP server op de linux bak (wat probleemloos werkt).

[Angelfire]

Het installeren van WINS was maar een idee, al zegt MS dat Wins niet meer nodig is met W2K, de praktijk heeft mij anders geleerd.
Even ter duidelijkheid NetBEUI is niet hetzelfde als NETBIOS. NetBEUI is een appart protocol, NETBIOS draait over TCP/IP heen.
Vaak wil het wel helpen om de manier waarop NETBIOS broadcast verstuurt aan te passen, default staat dit op 0x1 wat puur broadcast is. Dit kan vertragend werken, zelf werk ik altijk met 0x4, welke eerst een WINS server benaderd, en als die het niet weet, dan pas een broadcast doet.

[GeeMoney]

Volgens mij heeft het ook deels te maken met encrypted password checking en dergelijke, kan het mis hebben maar ik heb eens gelezen dat het daarmee te maken had.

[Mr. B.]

OK... na een hoop gepruts en geprobeer is het eindelijk opgelost

Toen ik nog eens kritisch naar de output van "browstat status" en "nbtstat -n" keek zag ik ineens de oorzaak: de virtuele netwerkkaarten die VMware aanmaakt.

Ik draai VMware op beide Win2000 machines waar het probleem speelde, en bij het zoeken naar pc's kijkt ie natuurlijk naar alle netwerkverbinden, dus ook verbindingen die op het moment niet actief zijn en waar dus niks te vinden is.

Oplossing: Client for MS Networks uitschakelen voor beide virtuele VMware NICs en het werkt weer op normale snelheid

[Verwijderd]

aahzo
dat was dus de software-kant
ik bekeek het vanuit mijn oude ervaringen

[Verwijderd]

Zoek eens in NOS, er staat een prima beschrijving van het 'probleem' wanneer je een Samba server in een windows domain hangt. De traagheid wordt veroorzaakt door de verschillende werkwijzen/stacks. Je zult dus je debian machine moeten aanpassen.

[Mr. B.]

Verwijderd schreef op 20 januari 2003 @ 14:15:
aahzo
dat was dus de software-kant
ik bekeek het vanuit mijn oude ervaringen

Ga slapen man, je bent nog steeds zat

[Mr. B.]

Verwijderd schreef op 20 januari 2003 @ 14:18:
Zoek eens in NOS, er staat een prima beschrijving van het 'probleem' wanneer je een Samba server in een windows domain hangt. De traagheid wordt veroorzaakt door de verschillende werkwijzen/stacks. Je zult dus je debian machine moeten aanpassen.

Ehm, lees het topic eens... het is al opgelost, de oorzaak lag dus niet bij Samba

[Verwijderd]

Ik had het zelfde probleem op mijn Win2000 PC, ik heb het opgelost door NetBEUI te uninstallen. Werkt nu probleemloos.

[Mr. B.]

Verwijderd schreef op 20 januari 2003 @ 21:14:
Ik had het zelfde probleem op mijn Win2000 PC, ik heb het opgelost door NetBEUI te uninstallen. Werkt nu probleemloos.

Ik gebruikte al geen NetBEUI
Met of zonder maakte in dit geval niet uit... het lag echt puur aan die virtuele NICs die VMware aanmaakt.

[Verwijderd]

Computers near ME zijn traag ja..........
ME sucks

[Mr. B.]

Verwijderd schreef op 21 januari 2003 @ 14:55:
Computers near ME zijn traag ja..........
ME sucks

Je zit op je werk... ga es wat nuttigs doen

[Verwijderd]

Das nogal ingewikkeld aangezien ik op de gemeente werk
/gaapmode

[Mr. B.]

Verwijderd schreef op 21 januari 2003 @ 15:00:
Das nogal ingewikkeld aangezien ik op de gemeente werk
/gaapmode

Ga koffie halen dan... da's relatief gezien erg nuttig voor een ambtenaar

Edit: of stamp een paar pc's in elkaar, dan heeft de sysop (jij dus ) weer wat te doen

[ Voor 20% gewijzigd door Mr. B. op 21-01-2003 15:02 ]