[Win7] domein inloggen zeer traag

[Verwijderd]

De situatie: groep gebruikers (10+) zijn sinds kort van workgroup overgeschakeld naar domeinstructuur. Vroeger werden bestanden gedeeld & georganiseerd via dropbox welke nu op een centrale dc/fileserver staan. Van in het begin zijn er al klachten dat het zeer traag gaat om in te loggen & bestanden te openen/op te slaan op de fileserver.

Ik heb dit nagekeken en het is inderdaad zo dat dit storend is. Ik vermoed dat de oorzaak ligt bij een netwerkprobleem. Beide servers staan "in de cloud" gehost.

Als ik een traceroute doe naar deze servers krijg ik pas bij de 5e poging een hit. Voorgaande pogingen geven een time-out. Ik ben niet de grootste netwerk expert en heb dergelijk probleem nog nooit moeten aanpakken.

Vandaar dat ik dit topic open. Uiteraard heb ik zitten rondkijken op google en daar worden tools als Xperf & Xbootmgr aangeraden om trage logintijden te troubleshooten. Ik heb helaas niet de ervaring/expertise om dit probleem correct aan te pakken.

[Daannn1987]

Eerst even wat facts omhoog krijgen alvoor we verder gaan

Waar staan de Servers "in de cloud" in een DC?
Hoeveel Mbit verbinding heb je bij de servers liggen ? Wat is de overboeking
Hoeveel Mbit verbinding heeft deze groep gebruikers?Wat is de overboeking
Wat zijn de ping-tijden naar de "cloud"
Wordt er gebruik gemaakt van roaming profiles?
Welk OS draaien de servers en de clients?
Die traceroute zegt niet veel, die 5 hops kunnen routers zijn die wellicht geen ICMP toestaan.

[ Voor 7% gewijzigd door Daannn1987 op 02-06-2014 22:38 ]

[sprankel]

Gezien de kleine groep gebruikers wil ik wel eens horen hoeveel Mbit upload die hebben van kantoor naar buiten toe.

[Verwijderd]

Daannn1987 schreef op maandag 02 juni 2014 @ 22:37:
Eerst even wat facts omhoog krijgen alvoor we verder gaan

Waar staan de Servers "in de cloud" in een DC?
Hoeveel Mbit verbinding heb je bij de servers liggen ? Wat is de overboeking
Hoeveel Mbit verbinding heeft deze groep gebruikers?Wat is de overboeking
Wat zijn de ping-tijden naar de "cloud"
Wordt er gebruik gemaakt van roaming profiles?
Welk OS draaien de servers en de clients?
Die traceroute zegt niet veel, die 5 hops kunnen routers zijn die wellicht geen ICMP toestaan.

Geen roaming profiles.
OS servers zijn allemaal W2K8 R2 SP2's en clients allemaal Win7's.
Speedtest vanop client geeft 90 Mbps download & 7 upload.
De connectie vanop hun netwerk naar de gehoste servers wordt dmv een VPN opgezet.
De snelheid hiertussen moet ik nog nagaan.
Ik heb niet genoeg rechten om de snelheid na te gaan waar de servers gehost staan.

Deze opdracht is als het ware beetje onterecht in mijn voeten geschoven maar ik zie het als een uitdaging en tracht hieruit redelijk veel te leren. Ik ben niet van het principe om een topic te openen en "tweakers-het-maar-laten-oplossen". Probleem is dat ik geen methodologie heb om dergelijk probleem aan te pakken waardoor ik niet goed weet waar eerst te beginnen kijken.

[Daannn1987]

90 om 7 is niet slecht... klinkt als Ziggo zakelijk

Word de VPN opgezet, voordat er wordt ingelogd? Of daarna pas?
Wanneer het daarna pas is, is de traagheid verklaarbaar

Anyhow, begin eens met een grote file te uploaden naar de cloud en vervolgens weer te downloaden en kijk eens welke snelheid je hierbij haalt.
Test dit eens s'avonds wanneer er niemand aan het werke is.
En eens during the day..

Gezien je een VPN connectie opzet, zou je de fileserver gewoon moeten kunnen pingen..
Kijk dus ook even naar de pingtijden.

er zijn genoeg tool in omloop warmee je network tests kunt uitvoeren.. such as LAN Speed Test

Key is altijd, begin bij de basis, en deel je incident in deelincidenten

[ Voor 15% gewijzigd door Daannn1987 op 02-06-2014 23:00 ]

[Verwijderd]

Daannn1987 schreef op maandag 02 juni 2014 @ 22:58:
90 om 7 is niet slecht... klinkt als Ziggo zakelijk

Word de VPN opgezet, voordat er wordt ingelogd? Of daarna pas?
Wanneer het daarna pas is, is de traagheid verklaarbaar

Anyhow, begin eens met een grote file te uploaden naar de cloud en vervolgens weer te downloaden en kijk eens welke snelheid je hierbij haalt.
Test dit eens s'avonds wanneer er niemand aan het werke is.
En eens during the day..

Gezien je een VPN connectie opzet, zou je de fileserver gewoon moeten kunnen pingen..
Kijk dus ook even naar de pingtijden.

er zijn genoeg tool in omloop warmee je network tests kunt uitvoeren.. such as LAN Speed Test

Key is altijd, begin bij de basis, en deel je incident in deelincidenten

Pingresultaten zijn allemaal <1ms
Downloaden van een groot bestand van de fileserver naar de client gaat aan 940 kB per seconden.
Straks start ik hoeveel de upload is. Echt al zeer bedankt voor de tips, zet mij zeer goed op weg.

Ook nog belangrij: folder redirection wordt niet gedaan. Loginscript doet niet meer dan een share mounten aan driveletter. GPO's zijn ook minimaal dus denk ook niet dat daar de oorzaak ligt. The saga continues!

[ Voor 9% gewijzigd door Verwijderd op 02-06-2014 23:46 ]

[Daannn1987]

940 KB per seconden is niet echt snel...

Hoe zit het nou met de VPN Wordt die opgezet, na het inloggen? Of ervoor?

[Question Mark]

Hoe zijn de clients en servers ingesteld qua ip-configuratie?

Traag inloggen klinkt als een fout in de dns-configuratie nl. Kun je eens de output van "ipconfig /all" posten van zowel een client als je Domain Controller? En geef even aan welk apparaat de dns-service host.

[Verwijderd]

Via GPO heb ik verbose logging gepushed naar mijn clients zodat ik precies kan zien over welk deel hij het langste doet. Het langst blijft hij staan op "bureaublad voorbereiden". Via GPO wordt alleen ingesteld dat elke gebruiker hetzelfde bureaublad krijgt toegewezen. Deze achtergrond staat in de netlogon folder op de domaincontroller. Ik ga vanavond eens deze policy disablen om te zien of het zoveel snelheidswinst uitmaakt, zou toch niet mogen?

[CAP-Team]

Wat Question Mark ook al zegt, traagte binnen een NT domein duidt meestal op (interne) DNS problemen.

[Verwijderd]

ipconfig /all vanop client:


vanop server:

[sprankel]

wanneer legt de computer de VPN verbinding? Dit dient te gebeuren voor de user begint aan te melden. Anders is het inderdaad normaal dat het aanloggen trager is. Dat is hetzelfde effect bij iemand die thuis werkt, omdat de DC niet beschikbaar is op het moment dat hij aanlogt (kan enkele minuten duren).

Er zijn meerdere manieren om VPN voor het inloggen beschikbaar te maken. Je kan een task aanmaken om de connectie te openen bij opstart. Of je maakt gebruik van DirectAcces. Je gaat echter wel server 2012 nodig hebben, op 2008 is DirectAcces IPV6 only.

En je zit duidelijk met een vertraging naar de file server. Kan je een test opzetten waarbij je niet over VPN gaat?

[Verwijderd]

sprankel schreef op dinsdag 03 juni 2014 @ 20:30:
wanneer legt de computer de VPN verbinding? Dit dient te gebeuren voor de user begint aan te melden. Anders is het inderdaad normaal dat het aanloggen trager is. Dat is hetzelfde effect bij iemand die thuis werkt, omdat de DC niet beschikbaar is op het moment dat hij aanlogt (kan enkele minuten duren).

Er zijn meerdere manieren om VPN voor het inloggen beschikbaar te maken. Je kan een task aanmaken om de connectie te openen bij opstart. Of je maakt gebruik van DirectAcces. Je gaat echter wel server 2012 nodig hebben, op 2008 is DirectAcces IPV6 only.

En je zit duidelijk met een vertraging naar de file server. Kan je een test opzetten waarbij je niet over VPN gaat?

Die VPN wordt geregeld via de FW (Cisco ASA) en deze tunnel staat altijd op. Ik kan eens proberen om van dc -> fs bestand up te loaden en zien welke snelheid hiermee wordt bereikt.

[sprankel]

Doe anders ook eens een pings onderling tussen de servers en een tussen de clients.
Om je achtergrond te geven: ik heb meermaals geweten dat eindgebruikers simpele switches bij plaatsen omdat ze aan bureau x te weinig netwerkaansluitingen hadden.
Als je van centraal naar kantoor een ping deed leek alles ok. Omgekeerd ook. Maar deed je een ping van host a naar host b in het kantoor en plots liep alles in de soep.

Eventueel kan je verschillende pings laten doorlopen en dan een bestand overzetten naar de fileserver.
(ping van server naar host en omgekeerd + ping onderling in kantoor + ping gewoon naar buiten toe op je telenet lijn + ping onderling tussen DC en Fileserver)
Dan zou je met de filetransfer mooi moeten zien waar het probleem zit. Eventueel ook zwaarder packet size sturen (standaard is 32)

Geen idee hoe het met je commands zit maar ik zet dit er gewoon voor de zekerheid bij:
ping -t -l 3000 => t laat hem doorlopen, met l zet je hem op een andere packet size (in dit geval 3000 ipv 32)
Om meerdere pings te doen kan je volgende command gebruiken
psexec \\host cmd
Dit zal een command prompt op de host openen maar de prompt staat op jouw pc open. Zo kan je dus gemmakelijk een remote prompt openen zonder de end user te storen.
Let op, deze is standaard niet beschikbaar, je moet hiervoor sysinternals installeren. Je hoeft het enkel op jouw pc te installeren. (admin rechten wel vereist uiteraard)


Voor de rest elimineren. Doe een test van DC naar Fileserver en omgekeerd. Als daar de snelheid gevoelig hoger ligt zit je ofwel met VPN performance problemen of is de upload/download aan server kant ontoereikend.

[ Voor 44% gewijzigd door sprankel op 04-06-2014 16:04 ]

[Daannn1987]

@Sprankel, Psexec staat niet standaard op elke pc he
Is onderdeel van PStools, desalniettemin is het een top tool, gebruik hem meerdere keren per dag om middels commandline remote executies uit te voeren. Een nog leukere tool is Owexec

Anyhow, dat vpn zaakje zit dus wel snor...
Maar de transferspeed van 1mbit vindt ik wel verontrustend..

Heb je al grote download / upload acties uitgevoerd?

Doe zoals sprankel zegt ook even wat pings met een grotere package size.

[sprankel]

PSTools is onderdeel van sysinternals

[Daannn1987]

Wat tegenwoordig weer onderdeel is van Microsoft

[Verwijderd]

Even een update uitgevoerd met een aantal testen. Voor de duidelijkheid: vanop Site A wordt via een CISCO ASA 5505 een S2S VPN-tunnel opgezet naar site B. In site A bevinden zich alle clients. In site B bevinden zich alle servers. Er is ook nog een 3e site (Site C) die ook via een ASA een VPN opzet naar server in site B

* Speedtest vanop client site A: 92 Mbps down / 7.43 Mbps up
* Speedtest vanop server site B: 50 Mpbs down / 4.05 Mbps up
* Speedtest vanop client in site C: 44 Mbps down / 4.02 Mbps up
* Download van bestand op server in site B naar client in site A: 500 - 800 Kbps
* Download van bestand op server in site B naar client in site C: 500 Kbps
* Upload van bestand van client in site A naar server in site B: 500 - 800 Kbps
* Download van bestand op servers onderling in site B: 30 MB/second

Update, ik denk dat ik er ben.
In Site A zitten ze bij momenten met een achttal users. De ASA die daar staat heeft een basis licence die maximum 10 inside hosts ondersteunt. Ik weet niet precies hoe een host wordt gezien maar tijdens uren kan het makkelijk zijn dat die 10 overschreden wordt waardoor gebruikers niet meer op internet kunnen. Die lange logintijden heb ik net nog getest en als gebruiker al eens ingelogd is op pc is het nog geen 10 seconden. Eerste maal aanloggen duurt ongeveer 1min. Ik vind dit persoonlijk aanvaardbare waarden.

[ Voor 25% gewijzigd door Verwijderd op 05-06-2014 00:40 ]

[sprankel]

routed mode, hosts on the inside (Business and Home VLANs) count towards the limit when they communicate with the outside (Internet VLAN), including when the inside initiates a connection to the outside as well as when the outside initiates a connection to the inside. Note that even when the outside initiates a connection to the inside, outside hosts are not counted towards the limit; only the inside hosts count. Hosts that initiate traffic between Business and Home are also not counted towards the limit. The interface associated with the default route is considered to be the outside Internet interface. If there is no default route, hosts on all interfaces are counted toward the limit. In transparent mode, the interface with the lowest number of hosts is counted towards the host limit. See the show local-host command to view host limits.

bron: http://www.cisco.com/c/en...82/license/license82.html

Ieder device dat connectie maakt naar buiten is dus een host. Printer, scanners, gsm devices, etc moet je dus ook meetellen als die naar de centrale file server/DC communiceren. Ook al is het maar voor iets stom zoals een MFP die PDF's naar een shared locatie zet.

Onderling in de servers vindt ik tegenvallen, normaal verwacht ik daar hogere snelheden maar gezien dit maar om een kleine groep gaat. Wat geeft een transfer nu vanaf client naar fileserver?

[_H_G_]

Verwijderd schreef op maandag 02 juni 2014 @ 22:31:
Vandaar dat ik dit topic open. Uiteraard heb ik zitten rondkijken op google en daar worden tools als Xperf & Xbootmgr aangeraden om trage logintijden te troubleshooten. Ik heb helaas niet de ervaring/expertise om dit probleem correct aan te pakken.

Ik krijg een beetje het gevoel dat je met een stopwatch zit te meten Je bent nu toch wel aan het meten met bijv. performance monitor van de server in kwestie? En in een gecontroleerde situatie (dat er niet vanalles langs je tests draait)?

En als je snelheid tussen servers test, gebruik dan bijvoorbeeld iperf of netio. 30MB is inderdaad opvallend laag. Waarschijnlijk test je je opslagsnelheid nu mee (dan is het nog traag, maar wellicht verklaarbaar).