Blog Home  Home Feed your aggregator (RSS 2.0)  
LDAP://Yusufs.Directory.Blog/ - Networking
Wieviele Sprachen sprechen Sie? Ich spreche bloß eine: 0011101010010
 
 Sunday, November 05, 2006

Was kann man tun, wenn die Netzwerkverbindung zwischen einem Client und dem Server "träge" ist?

Das läßt sich leider so pauschal nicht beantworten, denn das kann viele Ursachen haben und kommt auch auf die vor Ort existierenden Gegebenheiten an.

 

Die folgenden Punkte sollen einen Ansatz liefern, die man in solch einem Fall überprüfen sollte:

·         Zuallererst sollte die Netzwerkverkabelung überprüft werden (OSI Layer 1). Wenn ein Meßgerät verfügbar ist, sollte die Leitung durchgemessen werden, von der Client-Dose bis zum Patchfeld (bei einer neuen Netzwerk-Verkabelung, sollte man stets ein Meßprotokoll fordern).

·         Die Patchkabel sollten ausgetauscht werden (evtl. gegen ein STP-CAT6/7-Patchkabel) und die bereits verwendeten,
sollten in jedem Fall mindestens STP-CAT5e Patchkabel sein.
http://de.wikipedia.org/wiki/Twisted-Pair-Kabel

·         Existiert im Server-Raum ein Potentialausgleich (Erdung) und sind die aktiven Komponenten (Switch/Router) daran angebunden?

·         Es sollte zum Testen ein anderer Switch-Port oder besser, ein anderer Switch verwendet werden.

·         HUBs sollten in den heutigen Netzwerken nicht mehr verwendet werden.
http://de.wikipedia.org/wiki/Hub_%28Netzwerk%29

·         Die Routingtabelle des Routers sollte überprüft werden, evtl. besteht eine Schleife.

·         Ist das STP (Spanning Tree Protokoll) auf dem Switch aktiviert, so sollte es zum Test deaktiviert werden.

·         Die Netzwerkkartentreiber des Client sowie Server sollten aktualisiert werden. Im Idealfall existiert im Server eine Gigabit-Netzwerkkarte.

·         Falls der Server zwei Netzwerkkarten besitzt, sollte eine zum Testen ausgebaut werden.

·         Das Netzwerk sollte auf alle Fälle mit einem Sniffer überprüft werden, ob z.B. eine defekte Netzwerkkarte einen Broadcaststorm verursacht.
Ethereal: http://www.ethereal.com/

·         Auf beiden Seiten (Netzwerkkarte des Client/Server sowie Switch) sollte die Verhandlung der Übertragungsrate auf „Autonegotiation“ (Automatische Aushandlung) stehen.
Zum Testen kann man auf allen Geräten 100 M/Bit Fullduplex einstellen.
Aber Vorsicht: http://support.microsoft.com/kb/247609/en-us

·         Das BIOS (Mainboard) vom Client/Server sowie die Firmware des Switch`s sollten auf dem aktuellsten Stand sein.

·         Evtl. hat der TCP/IP-Stack einen Schaden. Das TCP/IP-Protokoll kann unter Windows 2000 Professional/Server in den
Netzwerkeigenschaften deinstalliert- und erneut installiert werden. Unter Windows XP/Server 2003 reicht es i.d.R. aus,
dass TCP/IP-Protokoll zu reseten,  mit dem Befehl „netsh int ip reset C:\resetlog.txt“.
Zurücksetzen von "Internetprotokoll (TCP/IP)" in Windows XP http://support.microsoft.com/kb/299357/de
Zurücksetzen der Komponente "Internetprotokoll (TCP/IP)" in Windows Server 2003
http://support.microsoft.com/kb/317518
Entfernen und Neuinstallieren von TCP/IP auf einem Windows Server 2003-Domänencontroller
http://support.microsoft.com/kb/325356/de
ACHTUNG: Danach stehen die Netzwerkeinstellungen auf „automatisch beziehen“!

·         Der Arbeitsspeicher und die Festplatten sollten auf dem Client/Server nach Fehlern
(auf den HDD`s nach Grown Defects/zu vielen Bad Sectore`s) untersucht werden:
http://www.memtest86.com/

·         Ein Indiz für eine langsame Anmeldung ist oftmals das DNS. Es sollte geprüft werden, ob der DNS-Server erreichbar ist und ordnungsgemäß funktioniert. Dem Client muss die IP-Adresse eines DNS-Server`s bekannt sein. Die Namensauflösung ist wichtig, deshalb sollte auch heute noch ein WINS-Server in der Domäne existieren:
Wie sollte WINS konfiguriert werden?

·         Eine andere mögliche Fehlerquelle, könnte eine „verkonfigurierte“ Gruppenrichtlinie darstellen (z.B. eine fehlerhafte Ordnerumleitung etc.).
Mit RSOP (Resultant Set of Policy - Richtlinienergebnissatz) kann auf dem Client geprüft werden,
welche Benutzer- sowie Computerrichtlinien angewendet werden.
Anschließend sollten die Einstellungen der angewendeten GPOs überprüft werden:
Resultant Set of Policy http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/rspintro.mspx?mfr=true
Das ganze gilt es ebenfalls auf dem Server zu überprüfen:
Welche Verfahrensweise zu Installation und Anwendungsrichtlinienergebnissatz in Windows Server 2003
http://support.microsoft.com/kb/323276
Oder man überprüft welche Richtlinien auf dem Client/Server wirken mit GPRESULT.
Behandlung von Problemen bei der Anwendung von Gruppenrichtlinien
http://support.microsoft.com/kb/250842/de

·         Das SMB-Signing sollte so eingestellt werden:
http://www.gruppenrichtlinien.de/index.html?/HowTo/SMB_Signing.htm
http://www.gruppenrichtlinien.de/index.html?/HowTo/DOS_Clients_an_Windows_2003_Server.htm

·         Mit PING sollte die Latenz und mit TRACERT der Weg den die Netzwerk-Pakete nehmen, überprüft werden:
Problembehandlung bei TCP/IP-Verbindungen in Windows XP
http://support.microsoft.com/kb/314067/de
How to Use TRACERT to Troubleshoot TCP/IP Problems in Windows
http://support.microsoft.com/kb/314868/en-us

·         Der Virenscanner/lokale Firewall sollte zum Testen auf dem Client sowie Server deaktiviert (besser deinstalliert) werden.

·         Alle Dienste/Programme (Filesharing) die zusätzlich die Netzwerkverbindung bzw. die Systeme belasten, sollten deaktiviert werden. Hilfreich wären hier die Programme: Taskmanager/Systemmonitor/Netzwerkmonitor:
Aufzeichnen von Netzverkehr mit dem Netzwerkmonitor
http://support.microsoft.com/kb/148942/de
Systemmonitor (Übersicht)
http://technet2.microsoft.com/WindowsServer/de/Library/9aa3769d-f7b0-4c7e-bafe-5d3e57f089a81031.mspx?mfr=true
Verwalten der Leistungsindikatoren des Systemmonitors in Windows XP
http://support.microsoft.com/kb/305610

·         Falls die Clients geimaget wurden, ist das SYSPREP angewendet worden?

  •   Auf dem Client sowie Server sollte die Ereignisanzeige nach Fehlern durchsucht werden.

 

Weitere Informationen:
Verbindung zwischen zugeordnetem Laufwerk und Netzwerkfreigabe geht eventuell verloren
http://support.microsoft.com/kb/297684/de
Niedrige Netzwerkleistung beim Kopieren von Dateien auf einen Domänencontroller,
auf dem Windows 2000 oder Windows Server 2003 ausgeführt wird

http://support.microsoft.com/kb/321098/de
Das Öffnen von Word-Dokumenten dauert sehr lange
http://support.microsoft.com/kb/D43829/de
Dateien auf Netzwerkfreigaben werden langsam oder schreibgeschützt geöffnet, oder eine Fehlermeldung wird angezeigt
http://support.microsoft.com/kb/814112/de
Die Installation des Sicherheitsupdates MS05-019 oder von Windows Server 2003 Service Pack 1 kann dazu führen,
dass die Netzwerkverbindungen zwischen Clients und Servern fehlschlagen
http://support.microsoft.com/kb/898060/de
Bei dem Arbeiten auf einem Windows Server 2003- oder einem Windows 2000 Server-Computer über das Netzwerk
mit Dateien können verschiedene Probleme auftreten
http://support.microsoft.com/kb/923360/de
Ein Domänencontroller, auf dem Microsoft Windows Server 2003 ausgeführt wird, reagiert möglicherweise
für einen Zeitraum von 2 bis 15 Minuten mehrmals am Tag nicht mehr
http://support.microsoft.com/kb/908370/de
Dateifreigabe in dem Netzwerk ist langsamer als erwartet in Windows Server 2003 SP1
http://support.microsoft.com/kb/904160/de
Langsame Netzwerkverbindung beim Öffnen einer Datei in einem freigegebenen Ordner auf einem Remotecomputer im Netzwerk
http://support.microsoft.com/kb/829700/de
Erwartetes Verhalten von mehreren Adaptern im gleichen Netzwerk
http://support.microsoft.com/kb/175767/de
TRACERT zum Beheben von TCP/IP-Problemen
http://support.microsoft.com/kb/162326/de
Diagnose und Behandlung von Black-Hole-Routern
http://support.microsoft.com/kb/q159211/
DNS-Abfrageantworten durchlaufen Firewall in Windows Server 2003 nicht
http://support.microsoft.com/kb/828263/de

Sunday, November 05, 2006 1:42:54 PM (W. Europe Standard Time, UTC+01:00)  #      Networking  | 
 Friday, September 22, 2006
  1. Zuerst gilt es die IP-Informationen der eingebauten NIC zu notieren (IP-Adresse+SubnetMaske+Gateway+DNS+WINS)
  2. Dann fährt man den DC/Server herunter und baut die neue Netzwerkkarte ein
  3. Nach dem Einbau der NIC fährt man den DC/Server erneut hoch und deinstalliert die alte Netzwerkkarte im Gerätemanager (zu finden unter "Start - Einstellungen - Systemsteuerung - System")
  4. Nun konfiguriert man die "neue" Netzwerkkarte mit den notierten IP-Informationen (von der "alten" NIC) und fährt erneut den DC/Server herunter und baut die "alte" Netzwerkkarte aus
  5. Zum Schluss gilt es den DC/Server zu starten und sicherheitshalber das DNS, WINS und Eventlog zu kontrollieren
Friday, September 22, 2006 11:28:40 AM (W. Europe Standard Time, UTC+01:00)  #      Networking  | 
 Sunday, September 17, 2006

Auf NT/2000/2003 Mitgliedsservern/Standaloneserver sowie NT/2000/XP Clients ist es möglich, den Systemen mehrere NetBIOS-Namen zu vergeben.

 

Das funktioniert nicht auf Domänencontrollern sowie auf NT-Printservern !

 


Durch folgenden Registry-Key, kann man einem Server mehrere Alias-Namen vergeben.
Dazu trägt man jeden zusätzlichen NetBIOS-Namen in einer eigenen Zeile in den „MULTI_SZ-Variable“-Wert ein:


Key: HKEY_Local_Machine\System\CurrentControlSet\Services\LanmanServer\Parameters

Name: "OptionalNames"

Typ: REG_MULTI_SZ

 

 

Desweiteren sollte das „StrictNameChecking“ deaktiviert werden. Das funktioniert aber erst mit Windows 2000 ab Service Pack 3 sowie mit Windows Server 2003.
Mit diesem (gesetzten) Schlüssel wird dem Serverdienst (SMB) ermöglicht, dass er eine Verbindung, die nicht mit seinem echten Computernamen versucht wird, zulässt:

 

Key: HKEY_Local_Machine\System\CurrentControlSet\Services\LanmanServer\Parameters

Name: "DisableStrictNameChecking"

Typ: REG_DWORD

Wert: 1

 

Normalerweise wird das nicht unterstützt:

http://support.microsoft.com/kb/254210/en-us

Damit der Serverdienst dieses unterstützt, setzt man den „DisableStrictNameChecking“-Schlüssel: http://support.microsoft.com/kb/281308/en-us

 

Nach der Registry-Änderung muss der Serverdienst beendet und neu gestartet werden, mit (in der Kommandozeile des Server`s) „net stop server && net start server“.

Danach (oder nach einem Reboot) werden die eingetragenen Alias-Namen „auch“ dynamisch in der WINS-Datenbank als „03h [Nachrichtendienst]“ eingetragen.
Die beiden fehlenden Einträge 00h [Arbeitsstationsnamen] und 20h [Serverdienst] sind noch statisch hinzuzufügen.

 

Ab Windows Server 2003 ist es auch möglich, einem Server mehrere DNS-Namen per Registry-Schlüssel zu geben.
Diese werden als A-Resource Records (A-RR) im DNS registriert. Dadurch bleiben einem die CNAME-Einträge im DNS erspart
(wer die CNAME-Einträge bevorzugt, kann diese natürlich setzen).

 

Die DNS-Alias-Namen werden in einer REG_MULTI_SZ-Variable mit dem Namen "AlternateComputerNames" gespeichert:

 

Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dnscache\Parameters

Name: "AlternateComputerNames"

Typ: REG_MULTI_SZ

 

Dazu muss der jeweilige DNS-Name als FQDN <Clientname.DNS-Domänenname> in einer Zeile eingegeben werden.
Die Änderung wird mit einem „ipconfig /registerdns“ (oder Serverneustart) wirksam.

 

Weiterführende Informationen:

http://www.jsifaq.com/SF/Tips/Tip.aspx?id=0062

http://www.jsifaq.com/SF/Tips/Tip.aspx?id=8062

Servermigration mit Netbios-Aliases

Sunday, September 17, 2006 12:28:16 PM (W. Europe Standard Time, UTC+01:00)  #      Networking  | 
 Friday, September 15, 2006

Was passiert eigentlich im Hintergrund, wenn man die LAN-Verbindung "repariert" ?

 

Falls Kommunikationsprobleme, die nicht mit der Infrastruktur (Verkabelung, Switch) zusammenhängen auftreten, gestattet Windows XP sowie Windows Server 2003 das "Reparieren der LAN-Verbindung". Hierbei passiert folgendes :

  • Der Computer-interne Cache von ARP wird geleert
  • Der Computer-interne Cache von NetBIOS wird geleert
  • Der Computer-interne Cache von DNS wird geleert

Anschließend wird veranlasst, dass die TCP/IP-Konfiguration durch versenden einer DHCP-Anfrage (DHCPDISCOVER) an einen DHCP-Server erneuert wird.
Dieses Vorgehen wird desweiteren ergänzt von einer erneuten Registrierung beim DNS-Server und falls vorhanden WINS-Server und falls die Verbindung die 802.1x-Authentifizierung verwendet, findet zudem auch hier eine dementsprechende Re-Authentifizierung statt.

Die Reparier-Funktion ist keine neue Funktion die Microsoft erfunden hat, vielmehr handelt es sich hierbei um eine Reihe von Befehlen (samt spezieller Parameter) die ansonsten in einer Kommandozeile händisch eingegeben werden müssten. Die Befehle lauten:

  • IPCONFIG /Renew (zum erneuern der IP-Adresse)
  • NBTSTATT -RR (zum registrieren im WINS) 
  • IPCONFIG /REGISTERDNS (zum registrieren im DNS)

Eine weitere Möglichkeit wäre noch, dass das TCP/IP - Stack einen Schaden hätte.
Diesen kann man zwar nicht mehr deinstallieren (wie zu Windows 2000 Zeiten), sondern nur noch deaktivieren, aber man kann ihn resetten.
Der Befehl hierzu lautet: "netsh int ip reset C:\resetlog.txt".
Was genau der Vorgang gemacht hat, kann man sich in der Datei C:\resetlog.txt anzeigen lassen.

 

Zum reparieren der LAN-Verbindung klickt man mit rechts auf die Netzwerkverbindung (sei es rechts unten in der Taskleise oder über die Systemsteuerung - Netzwerkverbindungen) und wählt "Reparieren" aus.

Friday, September 15, 2006 11:03:31 AM (W. Europe Standard Time, UTC+01:00)  #      Networking  | 
 Friday, September 08, 2006

Prinzipiell ist es möglich, die IP - Adresse eines Domänencontrollers (DC) zu ändern.

 

Allerdings gibt es ein paar Grundregeln, die zu beachten wären:

  1. Die IP - Adresse des DCs ist den Namensservern WINS und DNS bekannt
    bzw. eingetragen und steht ebenfalls im lokalen NetBIOS- und DNS - Cache eines jeden Member - Servers sowie Clients drin.
    Deshalb ist es empfehlenswert, die Änderung der IP - Adresse nur in einer "ruhigen Minute" zu erledigen,
    idealerweise wenn die Clients nicht online sind.

  2. Nach der Änderung der IP - Adresse, sollte in den WINS- und DNS - Servern,
    der alte IP-Eintrag des DCs gelöscht und überprüft werden, ob sich der DC mit der neuen IP dort eingetragen hat.
    Dieses kann man durch die Befehle mit "NBTSTAT -RR" (für WINS) und "IPCONFIG /Registerdns" (für DNS) manuell anstoßen.
    Die DNS-Einträge aus der "_msdcs-Zone" lassen sich mit dem folgenden NLTEST-Befehl entfernen:
    Nltest /DSDEREGDNS:DC01.Domäne.TLD

  3. Falls der DC das DNS installiert hat, gilt es zu kontrollieren, ob von einer übergeordneten DNS-Zone eine Zonen Delegierung auf diesen
    DC/DNS-Server existiert. Wenn dies der Fall ist, so gilt es die IP-Adresse für diese Delegierung zu aktualisieren. 


  4. Anschließend gilt es, auf allen anderen Servern (Memberserver und DCs) manuell die lokalen Namenscaches zu löschen,
    damit diese Server erneut die Namensserver abfragen um die neue IP - Adresse des geänderten DCs zu erhalten:
    "NBTSTAT -R" für den NetBIOS - Namenscache (WINS).
    Achtung auf die Gross- und Kleinschreibung des Schalters !  
    "IPCONFIG /Flushdns" für zum löschen des DNS - Namenscaches.
    Bei Arbeitsplätzen die rund um die Uhr laufen müssen, wäre dies auch notwendig.

Das ganze kann man sich auch ersparen, wenn die Systeme neu gestartet werden, denn dabei werden die lokalen Caches ebenfalls gelöscht.

Nach der IP - Adressänderung des DCs kann es kurzzeitig vorkommen, dass diverse Fehlermeldungen in den Ereignisprotokollen der Systeme
temporär auftreten, da die Systeme es nicht sofort "merken", dass sich die IP - Information des DCs geändert hat.

 

Dieses kann man aber vernachlässigen, denn das regelt sich von alleine in dem Moment, in dem die neue IP-Adresse überall bekannt ist.

Es wäre ebenfalls die gleiche Vorgehensweise, wenn ein Microsoft Exchange- oder Terminal Server darauf installiert wäre.
Ich möchte aber daran erinnern, dass Microsoft es nicht empfiehlt einen Exchange Server auf einem DC zu installieren.

Zum Schluss gilt es noch zu überprüfen, ob nicht die alte IP - Adresse vielleicht irgendwo manuell in die lokale Lmhosts- bzw. Hosts -
Datei eines Systems eingetragen wurde, um natürlich diese dann auch zu ändern.

 

 

Weitere Informationen:

The Internet Protocol (TCP/IP) Properties dialog box displays the default IP address settings after you manually configure a static IP address in Windows 2000 Server or in Windows Server 2003

Change the static IP address of a domain controller

 

Friday, September 08, 2006 3:04:13 PM (W. Europe Standard Time, UTC+01:00)  #      Administration | Networking  | 
 Saturday, August 19, 2006

Wie kann man den Namen der LAN-Verbindung umbenennen ?
Z.B. wenn man sich als Administrator anmeldet und mit einem rechts-klick auf das Icon der LAN-Verbindung klickt und den Punkt "umbennen" auswählt. Dazu braucht mal allerdings Admin-Rechte.
 
Geht das auch als ein normaler Benutzer ?
Die Antwort lautet - Ja es geht. Dazu gibt es schliesslich die Gruppenrichtlinien.
Benutzerkonfiguration - Administrative Vorlagen - Netzwerk - Netzwerkverbindungen - "Umbennen von LAN-Verbindungen zulassen".
Mit dieser aktivierten Policy kann der Benutzer die Verbindung umbenennen.
 
Gibt es auch eine Script basierte Möglichkeit ?
Auch hier lautet die Antwort - Ja, die gibt es.
Das Zauberwort lautet: NETSH
"netsh interface set interface /?"
Damit kann mit der Option "newname" und einer zusätzlichen Option der Name vergeben werden.
Bei der weiteren Option gilt es herauszufinden, welche am sinnvollsten wäre.
 
 
Yusuf

Saturday, August 19, 2006 8:08:34 PM (W. Europe Standard Time, UTC+01:00)  #      Networking  | 
Copyright © 2010 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: