Datenbankanwendungen, die die Jet-Engine benutzen, wie z.B. MS-Access und sehr viele Record Locks produzieren, bringen einen Netware 3.11 Fileserver zum Abend mit der Meldung:
Station 1: Record Lock Treshold exceeded
und erzeugen bei neueren Netware Versionen Fehler, weil nicht alle Records verarbeitet werden können.
Das ist vor allem bei Access ein bekanntes Problem, aber auch durchaus mit anderen Programmen denkbar. Dafür gibt es folgende Lösungen:
Folgende Settings auf maximale oder zumindest deutlich höhere Werte stellen:
set maximum record locks per connection = 10.000
set maximum file locks per connection = 1.000
set maximum record locks = 20.000
set maximum file locks = 100.000
Bei Netware 3.11 sollten Sie zusätzlich den Fix ttsfix.nlm aus Novell Patch 311ptg.exe einspielen. Dieser Fix schaltet einen Trigger ab, der bei einer Überschreitung der maximalen Locks pro Connection den Server mit einem Abend abwürgt.
Wenn man sich unter WIN9x am Server anmeldet, öffnet sich evtl. ein (oder mehrere) Fenster, die man jedesmal mit ALT-F4 schließen muß, damit es weiter geht.
Das ist jedoch ein Windows "Problem" und hat mit dem NetWare Loginvorgang eigentlich nichts zu tun.
Wenn das Fenster wieder einmal auf dem Schirm zu sehen ist, dann schließen Sie es nicht, sondern klicken das System-Menue links oben mit der rechten Maus-Taste an und wählen den Menue-Punkt 'Eigenschaften'. Dort können Sie u.a. einstellen, daß das Fenster (ab dem nächsten Aufruf) automatisch geschlossen werden soll.
Probleme beim Drucken von Rechnern unter Win95 und dem Novell oder MS 32bit-Client:
Die DOS-Umgebungsvariablen TEMP und TMP dürfen keinesfalls innerhalb eines innerhalb von Windows gestarteten Login-Scripts oder Batchfiles gesetzt bzw. verändert werden; tut man es doch, dann weiß Win95 offenbar nicht mehr, wo es bei der Erstellung der Druckdaten diese zwischenlagern soll... je nachdem wie es der Zufall dann so will, findet Windows seine Sachen wieder oder auch nicht...
Beim Login unter dem VLM-Client wird der Login-Script ja noch im DOS-Abschnitt des Windows-Starts, also vor dem Hochfahren der Windows-Oberfläche ausgeführt, so daß die o.g. Probleme nicht auftreten. Mit den 32bit-Clients jedoch läuft auch die Abarbeitung des Login-Scripts bereits innerhalb der 32bit-Umgebung.
Also: Falls es überhaupt notwendig sein sollte, TEMP oder TMP zu ändern, dann sollte das sicherheitshalber innerhalb der AUTOEXEC.BAT geschehen.
(Bei Verwendung des Novell 16bit VLM-Clients trat dieser seltsame Effekt übrigens nicht auf.)
Bei einer Arbeitsplatzinstallation von Access 2.0 lassen sich nicht alle Assistenten nutzen, vor allem nicht von mehreren Benutzern gleichzeitig.
Ein Schreibrecht auf das Workdirverzeichnis bewirkt, daß man die Assistenten überhaupt benutzen kann.
Das Attribut SH bewirkt, daß mehrere die Assistenten gleichzeitig nutzen können. Allerdings werden die Voreinstellungen des Users gespeichert, der den Assistent zuletzt beendet. Keine akzeptable LÖsung.
Erst das lokale Anlegen des Workdirverzeichnisses für jeden User einzeln ermöglicht ein reibungsloses Arbeiten. INI-Datei anpassen und es geht.
Wenn Speicherprobleme bei Winword oder Excel im Netzwerk auftreten, sind es meistens diese Ursachen:
zu wenig Rechte im gewählten Verzeichnis
Viele Programme löschen die alten Dateien und schreiben eine neue Version anstatt sie zu ändern.
Makroviren
Diese verändern die Speichern Dialoge, um sich weiterverbreiten zu können und verzweigen zum Beispiel immer auf "Speichern unter..."
serverbasierte Virenscanner mit Online Scan
Ironischerweise sorgen gerade die Virenscanner dafür, daß Dateien nicht mehr unter ihrem alten Namen zurückgespeichert werden können, wenn der Scanner die Datei beim Wegschreiben online scannt und der Client dadurch keinen vollen Zugriff mehr darauf hat.
Diese Speicherprobleme sind bei McAfee Netshield, Norton Antivirus for NetWare, Intel Landesk bei verschiedenen Clientbetriebssystemen aufgetreten.
Dieses Verhalten läßt sich umgehen, wenn man den Online Scan (Echtzeitcheck) von *.DO* und *.XL* Dateien gänzlich ausschließt oder zumindest auf den nächtlichen Check beschränkt.
Das Banner vor dem eigentlichen Ausdruck und auch das Notify läßt sich je nach Client und Betriebssystem unterschiedlich abstellen:
Microsoft Client Services for NetWare unter Windows NT
Start -> Einstellungen -> Systemsteuerung -> CSNW ->
Vorspann drucken: deaktivieren
Novell 32-Bit Client
Drucker -> Eigenschaften -> NetWare Settings -> Banner bzw.
Notify deaktivieren
Bei einem NT4 Rechner mit Microsoft Client können Sie diese Einstellungen so vornehmen:
Start -> Einstellungen -> Systemsteuerung -> CSNW: die jeweiligen Häkchen wegnehmen
Bei NT 4.0 mit dem SP5 läßt übrigens der Ausdruck
des Banners aufgrund eines Bugs nicht ausschalten. Verwenden Sie einfach den
aktuellen SP6a.
MS Office Programme wie Excel und Winword haben eine netzwerktechnisch sehr ungünstige Methode zur Speicherung von Dateiänderungen:
Die geänderten Daten werden in einer temporären Datei fortgeführt. Beim Speichervorgang wird nun die ursprüngliche Datei gelöscht und die temporäre in diese ursprüngliche umbenannt.
Aus diesem Grund reicht es nicht aus, das (W)rite Recht zu vergeben, sondern man muß dem Verzeichnis auch (M)odify, (D)elete und (C)reate zuordnen, damit es keine Probleme gibt.
Auch die Methode, ein Trustee Assignment diekt auf eine Datei zu legen, greift hier ine Leere, weil das Trustee durch das Löschen der Ursprungsdatei mit gelöscht wird.
Übrigens bekommen Sie beim Einsatz von Macrovirenscannern, die Dateien im Hintergrund automatisch scannen, eventuell Fehler beim Speichern von Dateien. Dann ist es auch möglich, daß die Datei nicht umbenannt werden kann und bleibt nur mit dem Temporärnamen erhalten.
Wenn bei einem Win9x Rechner ein Netzwerkclient (sei es ein Novell Client32 oder ein Microsoft Client) installiert wird, bleibt der Rechner unter Umständen minutenlang beim Herunterfahren hängen oder hängt sich ganz auf.
Das kann unter Win95 mit installiertem Internet Explorer 4.01 an einer defekten shell.dll des IE 4.01 liegen. Besorgen Sie sich bei Microsoft den IE 4.01 SP1 oder den IE 5.0.
Bei Win98 ist bereits eine neuere Version des IE 4.x enthalten. Bei Win98 SE gibt es dagegen ein allgemeines Problem mit dem Herunterfahren, dessen Lösung im folgenden Tip beschrieben wird.
Andere Möglichkeiten sind:
Vor allem das vorherige Abmelden vom Server hilft fast immer die Hänger zu vermeiden. Wenn der Login Screen wieder erscheint, kann man einfach die Anmeldung durch Abbrechen umgehen und den Rechner dann problemlos herunterfahren.
Von Microsoft gibt es einen aktualisierten Patch, der das Shutdown
Problem von Windows 98 SE in den meisten Fällen löst. Lesen Sie
dazu in der Microsoft Knowledge Base: 
http://support.microsoft.com/support/kb/articles/Q260/0/67.ASP
Download unter http://www.microsoft.com/windows98/downloads/contents/WUCritical/q260067/
Mit dem USB Network Interface 3C19250 von 3COM und wohl auch mit anderen USB Netzerkkarten gibt es mit Novell Clients, die neuer als Version 3.1 sind, übrigens auch Hänger, hier allerdings schon beim Starten des Rechners.
Zieht man das USB-Kabel vom Notebook ab und startet den Rechner dann erst, startet Windows normal. Man kann dann während Windows läuft das USB-Kabel wieder einstecken und wird sofort automatisch am Server angemeldet. Doch auch beim Shutdown hängt Windows wieder.
Scheinbar ist USB beim Start des Clients noch nicht voll initialisiert.
Wer bei Benutzung von langen Dateinamen unter NW 4.11 Probleme bei Zugriffen auf Dateien über Word und Excel hat und den Client32 3.1 einsetzt, sollte den Novell Patch mixmod6.exe einsetzen.
Wer dagegen - auch bei anderen Programmen - mit der Meldung konfrontiert wird, dass Dateien noch offen sind, obwohl der Benutzer sie bereits geschlossen hat, sollte einen aktuellen Service Pack installieren bzw. dafür sorgen, dass der Patch revfhrft.nlm (auch einzeln aus dem Novell Patch revfhrft.exe) installiert ist. Dieser Fehler kann sogar zu Abstürzen des Servers führen, weil diesem dadurch immer weniger Speicherplatz zur Verfügung steht.
Sobald ein neuer Benutzername bei einem NetWare Login an einem Windows 9x Rechner auftaucht, fragt Windows nach dem Passwort. Dieses Passwort wird lokal in der Datei WINDOWS\username.PWL gespeichert und ist recht einfach zu knacken. Damit Windows dieses Passwort nicht mehr speichert, gibt es einen Registry Eintrag:
[HKEY_L_M\Software\Microsoft\Windows\CurrentVersion\Policies\Network] "DisablePwdCaching"="1" "HideSharePwds"=hex:01,00,00,00,
Alternativ können Sie auch mit Poledit unter lokaler Computer, Netzwerk, Kennwörter "disable password caching" bzw. "Kennwortverschlüsselung deaktivieren" einstellen und "remote updates" deaktivieren.
Ausserdem sollte man aus Sicherheitsgründen die bisherigen *.pwl Dateien im lokalen Windows Verzeichnis löschen, wobei dadruch auch Passwörter für DFÜ-Verbindungen gelöscht werden.
Wenn bei einer DFÜ-Verbindung unter Win9x die Verbindung zum NetWare Server beendet wird oder dies vom DFÜ-Netzwerk angedroht wird, muss man unter den Eigenschaften des jeweiligen DFÜ-Netzwerk-Symbols das IPX Protokoll deaktivieren.
Win9x kann IPX nämlich nicht routen bzw. IPX nicht an zwei Netzwerkkarten gleichzeitig binden. Eine Verbindung zweier NetWare Server ist also über Windows 9x nicht möglich.
Wenn allerdings nur eine TCP/IP Verbindung mit dem Internet oder einer anderen Stelle erforderlich ist, sollte man IPX und möglichst auch NETBEUI einfach abschalten. Auch die Option "Am Netzwerk anmelden" ist normalerweise nicht notwendig und verlangsamt nur den Verbindungsaufbau.
Zuallererst sollten Sie beim Einsatz von Access diverse SET Einstellungen auf Maximum bringen (siehe "Server Probleme bei Datenbankanwendungen").
Egal, ob es sich um Access 2.0 oder eine der neueren Versionen handelt, sollten sie beachten, dass Access mit einer sehr grossen Datei arbeitet, die alle Informationen beinhaltet und zur Aktualisierung und Synchronisierung dieser Datei sehr viele Locks und auch Datenverkehr auf dem Netz erzeugt.
Auch wenn die Formulare nicht lokal liegen, ist der Zugriff zumindest unter Access 97 langsamer.
Wenn Access trotz der angegebenen SET Befehle und anderer Performanceeinstellungen nicht schneller wird, sollten Sie überlegen, einen SQL-Server einzusetzen und Access - wenn überhaupt - nur als Frontend dafür zu benutzen.
Die häufigste Ursache, warum Windows Benutzer Verzeichnisse versehentlich verschieben, liegt im Verhalten des Explorers, der bereits winzige Mausbewegungen bei gedrückter Taste als Verschieben interpretiert.
Man kann nun in der Registry die Anzahl der Pixel erhöhen, ab denen der Explorer ein Drag erkennt.
HKEY_CURRENT_USER\Control Panel\Desktop\DragHeight und HKEY_CURRENT_USER\Control Panel\Desktop\DragWidth
Sie sollten die Standardgröße von 2 auf etwa 15 hochsetzen und werden feststellen, dass diese Fehler drastisch reduziert werden. Eine Einschränkung der Rechte wäre nur theoretisch möglich. In der Praxis scheitert dies allerdings an den Applikationen wie MS Office, die fast alle Rechte brauchen.
Troubleshooting von CIFS Anmeldungen an einen NetWare Server:
TID mit Errorcodes: TID 10098783 (lokal)
