Das Notes Forum
Domino 9 und frühere Versionen => ND6: Administration & Userprobleme => Thema gestartet von: vman am 18.08.06 - 10:00:21
-
Hallo.
Habe folgendes Problem.
Wenn grosse Daten über unser Netzwerk kopiert bzw. verschoben werden (meist unabsichtlich), dann hängt das komplette Netzwerk.
Wie auch Notes.
Nach dem diese fälschliche Kopiererei fertig ist, funktioniert Notes nicht mehr, weil er den Pfad nicht mehr findet.
Jedesmal wenn kleine Netzausfälle sind (auch nur 2 Millisekunden), spinnt das Notes und ich kann es nur mehr mit KILLNOTES beenden. ---> kann doch nicht sein, oder ?
-
Wenn Notes über das Netzwerk gestartet wird, dann schon. Dann ist aber das SMB Protokoll von MS schuld, das keinen sauberen Reconnect ermöglicht.
-
OK, das sagt mir gar nichts.
Kennst Du da auch eine Lösung od. Lösungsansatz ?
Danke
Bernhard
-
Ja, Notes lokal auf dem PC installieren und von der lokalen Festplatte starten.
BTW:
1) Du brauchst für ein Thema nicht zig Freds starten. Deine Fragen hättest Du alle in diesem Fred untergebracht.
2) Du hast meine Frage noch nicht beantwortet. Wird der Notes-Client nun von einem Server gestartet, oder von der lokalen Platte?
3) Wenn Euer Netzwerk zusammenbricht, wenn eine größere Datei kopiert wird, solltest Ihr dieses ev. von Profis anschauen und optimieren lassen.
-
Hey.
1) Sorry. Dachte weil es ansich unterschiedliche Themen sind.
2) Notes wird lokal installiert. Der DATA Pfad jedoch ist am Netzlaufwerk.
3) Da hast Du natürlich vollkommen recht.
Danke
Bernhard
-
Ich würde mal sagen Punkt 2 ist der Verursacher.
André
-
Jup, wenn die Daten auf einem Netzwerk liegen, dann ist das der Grund für die "Aussetzer". Also entweder das Netzwerk verbessern, oder die Daten auf der lokalen Festplatte ablegen.
-
Aloha,
habt ihr mir zufällig einen Tipp, wo ich weitere Informationen über dieses Netzwerk-Geraffel herbekommen kann?
Wir haben nämlich genau das gleiche Problem. Data-Verzeichnis auf einem Netzlaufwerk und bei manchen Usern stürtzt es immer wieder ab. Notes wieder komplett auf die Festplatte zu schieben ist nicht nur deshalb eine unbefriedigende Lösung, weil die User uns das übelnehmen könnten, sondern vor allem, weil auch noch andere Nicht-IBM-Anwendungen davon betroffen sind.
In welche Richtung müsste man denn da forschen, wenn man den komplizierteren "Netzwerk verbessern"-Weg gehen möchte?
-
Dienstleister holen und Netzwerk durchmessen lassen. Zumeist sind schlechte Stecker, defekte NICs oder hinige Switsches schuld. Ich hatte aber auch schon mal (elektrische) Potentialprobleme in einem großen Netzwerk.
-
Das war die Art von Antwort, die ich nicht erhofft hatte. Kann ich nicht einfach einen Treiber updaten oder irgendwas patchen? ;)
Trotzdem Danke für die (beeindruckend) schnelle Antwort.
Netzwerkmessungen hatte unser Netzwerkmensch afaik schon gemacht.
Hach ich liebe solche Probleme... Die User beschweren sich bei mind. 3 verschiedenen Systemadmins (weil verschiedene Programme betroffen) die Systemadmins finden nichts und gehen zum Netzwerkmenschen, der meint es tut alles und geht zu den Client-Verwaltern, die finden weder bei den Netzwerkkarten noch beim Windows was und gehen zum File-Server-Admin und der streitet sowieso grundsätzlich alles ab. ;)
Lustiges Fingerzeigen quer durch die IT-Abteilung. :D
-
Hey, wir müssen über 2 Management-Ebenen, bevor wir zu den OS- oder Netzwerkkollegen sprechen dürfen. Und das auch nur, nachdem wir ein Ticket aufgemacht haben. :-X
-
Hallo,
also das Problem ist mir auch bestens bekannt. Da auch bei uns das Data-Verzeichnis auf einem Server im Netz liegt. Zum Glück ist das Netz soweit ganz ok. ;D Dafür liegen die Server gerne mal auf der Nase. ::)
Aber nur so aus Neugierde: Ist das SMB-Protokoll schuld, daß Notes Probleme mit geöffneten Files auf dem Netz hat, wenn es dort Unterbrechungen gibt? Wenn ja, wäre ich an Details interessiert. ;D Wie sieht das aus sicht einer Anwendung aus? Ist evtl. etwas OT.
Gruß
Dirk
-
Der SMB ist für ne Menge sachen Schuld, wird deswegen bei uns auf allen LN Servern abgeschaltet. Aber das mit Netz ist noch eine andere Geschichte.
LN bestimmt Dateien/Datenbanken ständig geöffnet (CLP-Test Frage!!!), wird die Verbindung unterbrochen war's das gewesen.
Das Verhalten des LN Clients wird dann ziemlich chaotisch und das der Client dann anfängt auf irgendwelchen beliebigen Hub-Servern die Repliken zuöffnen ist noch das harmloseste, aber auch IBM weist darauf hin das man das nicht tun sollte und da Festplatten heute nicht mehr die Welt kosten ist hat es auch keinen realen Sinn. Die User danken es einem weil Lotus nicht mehr so häufig abstürzt.
KAI
-
Bei uns liegt nur die names.nsf im Netzwerk und da gab es früher auch vereinzelt Probleme. Da gibt es aber von Jens einen schönen Artikel und das hochsetzen von 5sec auf 20sec ist/war bei uns allerdings immer die Lösung...
http://atnotes.de/index.php?topic=14563.0
-
Die TCP-Einstellungen in den Benutzer-Einstellungen haben nichts mit den lokalen DB Zugriffen zu tun (z.B. lokale names.nsf), sondern nur mit der Server-Client Kommunikation per NRPC.
Filezugriffe ins Netzwerk ist Aufgabe von Windows und dem Windows IP-Stack und was sonst noch dazugehört.
KAI
-
Hive, das ist so nicht (mehr) richtig, da der SMB (http://de.wikipedia.org/wiki/Server_Message_Block)-Traffic mittlerweile auch über TCP/IP abgewickelt wird (SMB über TCP/IP (http://SMB über TCP/IP)).
Sowohl NRPC, als auch SMB laufen über den Windows-IP-Stack.
-
Ich kann nur von uns reden. Wir haben die names.nsf im Netzwerk liegen. DATA-Verzeichnis liegt bei uns lokal, und da kenne ich keinen User der nachdem ich von 5sec auf 20sec jemals bei uns im Helpdesk wieder angerufen hat.
Das einzige was ich noch mache, wenn ich eh per RemoteControl auf dem UserPC drauf bin, dass ich dann alle anderen Anschlüsse bis auf TCP-IP komplett lösche..
Gruss
Martin
-
jau gut stimmt wohl, alles was TCP/IP benutzt muss über den Windows IP Stack, aber die LN Timeout sind dem Windows ziemlich egal wenn die lokale Datenbank über Netzfreigaben zu erreichen sind. So in etwa wollte ich das gesagt haben..
Aber wenn es funktioniert dann interessiert keinen wieso .. insofern .. *glückahoi ;)
KAI