Links
http://www.novell.com/documentation/lg/nwec/index.htmlEin Netware Server 'piepst' (fast) immer, wenn an der Serverkonsole eine Meldung ausgegeben wird. Diese Meldungen werden normalerweise (wenn das noch möglich ist) in das File Server Error-Log geschrieben und können von dort aus wieder abgerufen werden.
Das File Server Error-Log kann man sich wie folgt anschauen:
1.1.10 Device #0 (5B010) xxxxxxxxx-deactivated due to drive failure.
Diese Fehlermeldung deutet auf ein Hardware-Problem hin. Die NetWare konnte nicht mehr auf die Platte zugreifen und hat sie deshalb deaktiviert. Wenn die Platte auch das SYS-Volume enthält, geht danach auf dem Server überhaupt nichts mehr.
Mögliche Ursachen für die Deaktivierung sind:
Lösungsvorschläge:
Nach dem Installieren eines neuen Volumes und anschließendem Kopieren von größeren Datenmengen auf dieses Volume kam folgende Meldung:
6/30/95 4:33:20 pm Severity = 5. 1.1.39 Cache memory allocator out of available memory.
Da gibt es zwei Möglichkeiten:
Viele Programme (NLMs) nutzen die Routinen, die von dem Modul CLIB.NLM zur Verfügung gestellt werden. Da dieses Modul mit der Zeit immer wieder erweitert wird, verursachen Anwendungen, die diese neuen Routinen ansprechen wollen, bei älteren Versionen der CLIB obigen Fehler.
Abhilfe: die neueste CLIB.NLM benutzen.
Manchmal kann es auch daran liegen, daß NLMs für NW 4.x programmiert wurden. Diese Versionen haben zusätzliche Routinen, die aber bei der NW 3.1x über die Module AFTER311.NLM/A3112.NLM zur Verfügung gestellt werden. Das Modul AFTER311.NLM muß deshalb bei manchen Programmen zuvor manuell geladen werden, A3112.NLM wird dann automatisch nachgeladen.
Das (recht alte) A3112.NLM vom 10.10.95 ist übrigens fehlerhaft und erzeugt (vor allem bei ARCserve) den Fehler 1.1.38 Cache memory allocator exceeded minimum cache buffer left limit.
Für die NetWare 4.x sind die Module in dem Novell-Patch LIBUP?.EXE bzw. in den kompletten Service Packs enthalten, bei der NetWare 3.1x in einem eigenen Patchkit LIB312?.EXE.
Primary (Secondary) interrupt controller detected a lost hardware interrupt
Grob gesagt entsteht diese Meldung immer dann, wenn das anfragende Device
seinen Interrupt verliert, bevor der Interrupt-Controller ein OK von der CPU
bekommt.
Stehen Daten an, die das Interrupt-Device (z.B. eine Netzwerkkarte oder
der HD-Controller) versenden muß, so gibt dieses Device eine
Interrupt-Anfrage, einen Event, an den Interrupt-Controller PIC (Programmable
Interrupt Controller) weiter.
Der PIC sammelt alle Events. Die CPU wird ihre derzeitige Aufgabe so
bald als möglich zwischenspeichern und für diesen Service
unterbrechen und fragt die Unterbrechung beim PIC an. Findet nun der PIC die
Interrupt-Anfrage (EVENT) des Devices nicht mehr, erhalten wir einen
"....lost hardware interrupt".
In einem 16-Bit-Rechner werden 2 PIC's eingesetzt: Primary (Int. 0-7) und Secondary = (Int. 8-15). Abhängig davon, welcher Interrupt verloren geht, bekommen wir entweder "Primary controller..." oder "Secondary ...".
Da das Interrupt-Device aber noch immer Daten zu versenden hat, wird es eine erneute Anfrage an den PIC senden ...., der wiederum erfragt bei der CPU einen Interrupt-Service ...., und so weiter ..., und so weiter. Damit erklärt sich auch, warum die Meldung eines verlorenen Interrupt durchaus mehrmals hintereinander am Monitor erscheinen kann.
Im nahen Zusammenhang steht auch die Meldung "Spurious hardware interrupt XX detected", die bei Systemen mit Shared-Interupt vorkommen kann.
Da im rechnerinternen Ablauf durchaus ein Int.-Request verloren geht, ist
nicht immer ein Fehler vorhanden. Sollte die Meldung jedoch öfter
erscheinen und der Datendurchsatz erheblich verlangsamt werden, müssen
wir auf Ursachenforschung gehen.
Warum kann eine Interrupt-Anfrage verloren gehen?
Lösungsmöglichkeiten:
Vor allem die Original Netware 3.x ohne Patches hat Probleme, Arbeitsspeicher über 16 MB richtig zu erkennen. Auch die einfache Registrierung mit REGISTER MEMORY löst die Problematik nicht. Es treten gehäuft Speicherprobleme auf, obwohl noch sehr viel freie Cache Buffers frei sind: Cache Memory Allocator...
Man kann sich bei der Netware 3.1x seit den Patchkits 311PTF.EXE bzw. 312PT8.EXE (oder neuer) mit Hilfe des LOADER Patches das REGISTER MEMORY sparen, da durch ein Patchen der Server.exe der komplette Speicher erkannt wird. Das klappt mit den meisten neueren Rechnern, Probleme bei ASUS Boards diesbezüglich wurden durch BIOS-Updates gelöst.
Dazu sollten nach dem Entpacken von 31xPTx in PATCHES\START die drei
Dateien Loader.exe, Lswap.exe und Lswap.nlm vorhanden sein. Diese kopiert man
in das Verzeichnis C:\NWSERVER und kopiert auch die Server.exe dazu.
Danach erfolgt der Aufruf von LSWAP. Daraufhin gibt es eine Server.old
und eine neue gepatchte Server.exe mit dem aktuellen Datum, die in das
Startverzeichnis des File Servers kopiert werden muß.
Bei Netware 4.xx wird der Speicher normalerweise komplett erkannt. Falls nicht, ist es dort aber problemlos möglich, REGISTER MEMORY auch in der STARTUP.NCF (vor den Plattentreibern!) einzutragen.
Bei EISA-Boards muß bzw. sollte REGISTER MEMORY nicht angeben werden, wenn der Speicher im EISA-Setup richtig angemeldet ist. Es gibt allerdings EISA-Rechner, bei denen der Speicher scheinbar nicht korrekt angemeldet wird. Für diese gilt der Vorgang wie für die anderen Systeme.
Falls der LOADER Patch nicht funktioniert, hilft bei NetWare 3.1x folgendes Vorgehen:
Der nachfolgende Text bezieht sich nur auf ISA-Rechner, auf denen Novell Netware nur bis zu 16 MB installierten Arbeitsspeicher selbständig erkennt und jeder weitere Arbeitsspeicher mittels dem Befehl "Register Memory" angemeldet werden muß. Hierbei sollte jedoch beachtet werden, daß viele (vor allem ältere) Mainboards mit VLB- oder PCI-Bussystem ebenfalls ISA-Rechner in diesem Sinne bleiben.
Sollte man unsicher sein, ob dieser Fall auf das eigene System zutrifft, so kann man dies auf folgende Art und Weise feststellen:
Sollten nun nur 16 MB (von z.B. 32MB) als "erkannt" gemeldet werden, so wird der nachfolgend beschriebene Weg notwendig werden.
Prinzipielles:
Netware 3.x lädt beim Mounten der Volumes die Verzeichnisinformationen dieser physikalischen Gebilde nach einer "Top/Down" Methode in den aktuell verfügbaren Arbeitsspeicher - also immer von der maximal verfügbaren Speicherobergrenze an abwärts. Da das Mounten des SYS-Volumes jedoch beim Laden des Festplattentreibers vollautomatisch erfolgt, kann dies unter Netware 3.x zu massiven Speicherproblemen führen. Denn - wie jeder Systembetreiber wissen sollte - läßt sich unter Netware 3.x der Arbeitsspeicher oberhalb 16MB erst in der AUTOEXEC.NCF (also nach Mounten des Volumes SYS) anmelden.
Lösung:
Sämtlicher verfügbarer Arbeitsspeicher muß bereits vor Laden des Plattentreibers (bzw. vor dem Mounten des Volumes SYS) dem System bekannt sein.
Dazu geht man nach folgendem Schema vor:
FILE SERVER NAME xxxx IPX INTERNAL NET yyyy REGISTER MEMORY 1000000 xxxxxxx (xxxxxxx => siehe unten) LOAD <PLATTENTREIBER> MOUNT SYS SYS:SYSTEM\AUTOEXEC.NCF
Resultat:
Durch den oben beschriebenen Weg erreicht man, daß vor dem Laden aller NLMs in den Arbeitsspeicher des Servers der gesamte verfügbare Speicher der Maschine dem System bekannt ist. Man vermeidet somit die normalerweise entstehenden Zerklüftungen des Speichers, welche unter Umständen zu massiven Problemen führen können.
Alle weiteren serverbasierenden Programme (Datensicherung usw.) können jedoch weiterhin (gemäß deren Standard-Prozeduren) mittels der AUTOEXEC.NCF im Verzeichnis "SYS:SYSTEM" geladen werden.
Parameter von REGISTER MEMORY:
register memory <startadress> <Länge> (beide Zahlen in hex) decimal 16777216/1048576/65536/4096/256/16/1 16Meg = 1 0 0 0 0 0 0 =1'000'000 Gesamtspeicher: Befehl: 24 MB register memory 1'000'000 800'000 32 MB register memory 1'000'000 1'000'000 48 MB register memory 1'000'000 2'000'000 64 MB register memory 1'000'000 3'000'000 128 MB register memory 1'000'000 7'000'000 192 MB register memory 1'000'000 B'000'000 256 MB register memory 1'000'000 F'000'000 usw.
(Eingabe jeweils ohne ')
Falls der File Server mit einer der beiden Methoden trotzdem
nicht ehr als 64 MB Arbeitsspeicher anzeigt, ist wahrscheinlich im BIOS die
OS/2-kompatible Registrierung des Speichers eingestellt, die unter Netware
Probleme bereitet.
Bei (E)IDE-Servern kommt es immer wieder vor, daß die Meldung can't write to FAT erscheint, zum Teil mit anschließendem Dismounten des betreffenden Volumes.
Der Fehler tritt oft nur bei starkem Zugriff in Verbindung mit vielen Schreib- und Lesevorgängen auf.
Zuerst sollt geprüft werden, welcher Plattentreiber geladen ist. Der ISADISK.DSK ist bei (E)IDE-Platten nicht zu empfehlen, aber auch vom IDE.DSK gibt es einen (mittlerweile schon älteren) Patch, der Probleme mit großen EIDE-Platten behebt. Einige Hersteller liefern auch einen eigenen Plattentreiber zum Controller/Board mit. Auch hier sollte nach aktuellen Versionen gesucht werden.
Eine andere Lösung ist das Ausschalten des Blockmodus im Rechner BIOS. Durch diesen Blockmodus schreibt der Controller blockweise auf die Platte. Dadurch gibt es unter Netware Timeouts, die obiges Fehlerverhalten hervorrufen.
Wenn die Installation der Netware mit der Meldung Fehler beim Kopieren der Datei cdrom.nlm abbricht, liegt das nicht an einer defekten CD-ROM, sondern (siehe TID 2906932 (lokal)) daran, daß der DOS-CD-ROM- Treiber mit dem Namen "cdrom" geladen wurde. Nach dem Umbenennen auf "cdrom001" oder irgendetwas anderes und dem Anpassen von MSCDEX in der AUTOEXEC.BAT funktioniert die Installation auch wieder.
Auch ASPICD oder andere Namen, die es auch als Dateinamen gibt (egal, welche Endung sie haben), sollten nicht als Devicename verwendet werden.
Devicenamen darf man nicht als normale Dateinamen verwenden. So wird es normalerweise nie eine Datei LPT1.TXT geben oder eine COM1.EXE.
Diese Fehlermeldung beim Start eines aktuell gepatchten NW 4.11 oder NW 5 Servers tritt beim Laden von CPUCHECK.NLM bei einigen Systemen auf. Da dieses Modul aber nicht essentiell für die Funktionalität des Servers ist, kann man die Meldung einfach ignorieren.
In 100 MBit Netzen gibt es den Fehler "NETWORK STATUS ERROR ...... Client versucht reconnect !" häufiger als bei 10 MBit Netzen, weil die eingestellten Packet Receive Buffers des Servers oft nicht ausreichen.
Es gibt die zwei Parameter "minimum packet receive buffer" und "maximum packet receive buffer" mit den Standardwerten 50/100. Das bedeutet, daß der Server Platz für 50 (und bei Bedarf ausbaubar auf 100) Pakete hat, die ihrer weiteren Bearbeitung harren. Das reicht für ein 10 MBit aus, für ein 100 MBit-Netz eben nicht. Da braucht man zwischen 100 und 500 solcher Puffer, wieviele genau hängt von der Anzahl der Stationen, deren Netzwerkkarten und der Art des Datenverkehrs ab.
Setzen Sie das Minimum auf 100 und das Maximum auf 500, dann sind sie normalerweise auf der sicheren Seite. Wenn die 100 nicht ausreichen, wird es unmittelbar nach dem Serverstart an den Arbeitsplätzen ein paar kurzfristige (aber wirklich nur Sekunden) Pausen geben, während sich der Server im erlaubten Umfang die notwendigen Puffer reserviert. Wieviele es dann tatsächlich sind, können sie auf der ersten Seite des monitor.nlm nachlesen und im SERVMAN oder manuell in der AUTOEXEC.NCF anpassen. Wenn die Puffer nicht ausreichen, gehen u.U. massiv Datenpakete verloren und das führt zu den oben beschriebenen Effekten.
Die Online-Dokumentation beschreibt die Werte von "Send OK but deferred", die im MONITOR.NLM in der LAN Information angezeigt werden, folgendermaßen:
"Die Anzahl der Rahmen, deren Übertragung wegen eines belegten Mediums verzögert wurde. Dies ist der Fall, wenn zu dem Zeitpunkt, an dem der Adapter den Befehl zum Übertragen des Pakets empfängt, eine andere Station auf der Leitung überträgt."
Mit anderen Worten: Dieser Fehler ist eigentlich gar kein Fehler, sondern soll die Anzahl der Pakete anzeigen, die nicht sofort gesendet wurden, sondern etwas verzögert wurden, um eine Kollision, die bei Ethernet (CSMA/CD) zwangsläufig auftritt, zu verhindern.
Der Server sagt der NIC, sie soll ein Paket wegschicken, die NIC stellt aber fest, daß die Leitung gerade blockiert ist und sendet überhaupt nicht. Sie wartet und schickt das Paket los, wenn die Leitung frei ist.
Eine Kollision im Sinne von CSMA/CD tritt erst auf, wenn das Paket bereits gesendet wurde, während der Signallaufzeit des ersten Paketes von der NIC aber noch ein weiteres Paket von einer anderen NIC empfangen wird. Gemäß CSMA/CD ist das der Kollisionsfall und das Paket ist erneut zu senden.
In der Praxis ist dieser Wert unabhängig von der Verkabelungsart (sowohl bei BNC als auch einer strukturierten TP Verkabelung mit CAT5) immer höher als der von Single oder Multiple Collision und darf durchaus bei 0,15% bis 1,5% der gesamten Paketanzahl liegen.
Wenn der Zähler der nicht verfügbaren ECBs (Event Control blocks) sehr schnell hochläuft, könnte irgendeine Netzwerkkarte defekt sein oder Treiberprobleme der Netzwerkkarte im Server bestehen. Außerdem tritt der Fehler bei vielen Karten auf, für die am Server Treiber geladen sind, aber kein Netzwerkkabel angeschlossen haben.
Höchstwahrscheinlich sind jedoch die Packet Receive Buffers am Anschlag und sollten erhöht werden. (siehe auch SET Befehle)
Es ist nicht weiter verwunderlich, daß ein knapp mit Speicher
ausgerüsteter Server erst einige Zeit läuft, bevor er Fehler zeigt
oder sogar mit einem Abend abstürzt.
Wie aus der Dokumentation zu entnehmen ist, wird von den file cache
buffers neben den für cache nonmovable- (NLMs), cache movable- (hash
Tables, FATs und Directory- Einträge), permanent- (communication- und
directory cache buffers) und semi-permanent-memory-pool (LAN- und
disk-driver) auch noch Speicher für alloc short term memory entnommen.
Diese kurzfristigen Zuordnungen werden für drive mappings, SAP-
und RIP-Tabellen, Druckerwarteschlangen und Informationen über die user
connections benötigt und bei Freigabe nicht wieder an die file cache
buffers zurückgegeben (nicht mehr benötigter Speicher kann hierbei
nur noch innerhalb des alloc short term memory weiterverwendet werden).
Es ist leicht nachzuvollziehen, wie sich das im Laufe der Zeit auf die
Speicherbereiche des Servers auswirkt und welche Folgen es hat, wenn die file
cache buffers sehr knapp bemessen sind.
You exceeded your outstanding NCP Directory Search Limit
Maximum Outstanding NCP Suchläufe
DOS erlaubt höchstens 32K an Verzeichniseinträgen pro Datenträger. Dies gilt auch für Netware 2.x. Der Grund dafür ist der verwendete 16-Bit File Handle (16 Bits mit Vorzeichen ergeben nur 32K). Netware v3.x bietet jedoch eine Höchstzahl von 2 Millionen Verzeichniseinträgen pro Datenträger.
Es ist deshalb erforderlich, daß das v3.x Betriebssystem die 16-Bit DOS-Anforderungen in einer Tabelle den Netware v3.x 32-Bit Verzeichniseinträgen zuordnet. Diese Tabelle wird bei "Find First's", "Find Next's", "File Open's" und bei Verzeichnissuchläufen nach Dateiinformationen verwendet.
Wenn einer dieser Suchvorgänge von einem Programm der Arbeitsstation gestartet wird, erscheint der entsprechende Eintrag in dieser Tabelle. Dieser Eintrag wird nur dann freigegeben, wenn der Dateiname genau angegeben wird, wenn die Arbeitsstation eine Meldung "End of Job" ausgibt oder wenn die "Find Next's" Suchvorgänge am Ende des Verzeichnisses beendet.
Wenn eine Arbeitsstation einen "Find First" einleitet, wird der entsprechende Eintrag in diese Netware-Tabelle eingefügt.
Sollte die Tabelle voll sein, gibt der Server die Meldung "File Not Found" zurück, obwohl die Datei existiert.
Standardmäßig kann diese Tabelle bis zu 51 Einträge enthalten. Ihre Anzahl kann mit Hilfe des einstellbaren Consolen SET Parameters "Maximum Outstanding NCP Searches" erhöht werden.
Diese Erweiterung beansprucht Serverspeicher, da jeder Eintrag 24 Byte beträgt und es eine Tabelle für jeden Anschluß gibt. Wenn demnach die Tabellengröße auf 100 eingestellt ist und 250 Arbeitsstationen angemeldet sind, muß der Server einen Speicherplatz von 600K für die NCP-Suchtabellen bereitstellen.
Nach ca. 4-5 Stunden kommt manchmal folgendes auf der Serverkonsole:
Abend: Kernel detected process going to sleep when it was not allowed
Eventuell sind in diesem Fall Stromsparfunktionen im File Server BIOS aktiviert, die muß man auf jeden Fall deaktivieren.
Diese Meldung eines Netware 3.x File Server weist nicht auf einen Virus, sondern auf eine kleine Schlampigkeit des Novell Programmierers Richard Kiel hin. Dieser hatte wohl bei der Programmierung zum Abfangen dieses Abends keinen geeigneten Namen gefunden und ihn zwischenzeitlich Richard Kiel Memorial Abend 27 genannt. Vor der Auslieferung wurde es allerdings versäumt, diese Meldung zu ersetzen.
Es gibt im Patchkit zu NetWare 3.12 einen Patch, der diese Meldung in "Invalid entry in message list" ändert, den Abend selbst allerdings nicht behebt. Dieser rührt von einem Problem mit Festplattencontroller oder Netzwerkkarte her und kann durch einen Novell Patch nicht verhindert werden.
Aktuelle Treiber oder ein Austausch der Hardware sollten dieses Problem beheben.
Laut NAI führt das Benutzen der Version 3.x DAT-Files beim Version 4.x Netshield und umgekehrt zum Server-Absturz.
Abends treten auch bei falsch konfigurierten On-Access-Jobs auf (Server läuft dann auf 99%) und bei Scan-All-Volumes (ABEND). Die Fehler lassen sich normalerweise durch Umkonfigurieren beheben.
Bei Netware 4.11 und allen neueren Netware Versionen macht sich ein Abend folgendermaßen bemerkbar:
Wenn der Server z.B. SERVER heißt, steht an der Console statt des normalen Prompts
SERVER:
ein
SERVER<x>:
wobei das "x" die Anzahl der Abends darstellt.
Um den Grund des Absturzes zu erfahren, kann man die Logdatei SYS:SYSTEM/ABEND.LOG zu Rate ziehen, wenn das System noch soweit intakt war, um in die Datei überhaupt schreiben zu können. Diese darf auch nicht auf Read-Only stehen, da sonst das Anhängen neuer Meldungen unmöglich gemacht wird.
Wirklich wichtig für die Analyse ist allerdings nur der erste Abend nach einem Neustart des Servers, weil alle anderen Abstürze wahrscheinlich nur Folgefehler des ersten sind. Wenn Sie in der ABEND.LOG keinen ersten Abend sehen, setzen Sie"set auto restart after abend=0". Damit bleibt der Server nach einem Abend stehen und Sie können diesen feststellen. Für die Benutzer heißt dies aber auch, dass kein Zugriff auf den Server mehr möglich ist.
Neuer Rekord war in einer Anfrage in einer englischen Newsgroup übrigens die eine Anzahl von 7689 Abends seit dem letzten Neustart des Servers!
siehe auch Tipp "Online Abend Analysis"
WARNING! Volume BIG last segment (0) ends at x instead of y
hier der passende Auszug aus der NSEPro:
| Explanation: | The segment ends at a block which is incorrect based on the
operating system's calculation of where the segment begins and how
large it is. |
| Action: | None. This message is for information only. |
Diese Meldung erhalten Sie oft beim Laden von NLMs, die auf unterschiedlichen Netware Versionen laufen (müssen).
Auch wenn der Server meint: "You should upgrade to a newer module when it becomes available", besteht kein Grund zur Sorge. NW 3.x, 4.x, 5.x und 6.x Server benutzen unterschiedliche API Funktionen (Programmierschnittstellen) und ein Programm, das es jeder Version recht machen will, erzeugt obigen Fehler.
Wer unter Netware 4.x Probleme mit einem "Memory Allocation Memory" (vor allem im Zusammenhang mit der Kompression von Dateien) hat, kann sich bei Novell ein Update herunterladen: Novell Patch pk411it3.exe.
Dieses Archiv enthält unter anderem den Patch decrenfx.nlm, der eine Schleife behebt, während eine komprimierte Datei umbenannt wird. Diese Schleife verbraucht sehr schnell Arbeitsspeicher und erzeugt die erwähnten Speicherfehler und kann der Server damit zum Absturz bringen.
Das Problem wird durch den SP8(a) allein noch nicht behoben.
Wenn beim Netware Server die Konsole nicht mehr zugänglich ist, der Server selbst aber noch weiterläuft, kann man bei NetWare 5.1 über STRG-ALT-ESC eine neue Konsole öffnen und bei allen älteren Netware Versionen über einen Client den Server herunterfahren, solange der Zugriff auf den Server überhaupt noch möglich ist.
Wenn das auch nicht mehr klappt, können Sie auch versuchen, den Server in den Debugger (siehe dort) zu bringen, um das verursachende Programm herauszufinden.
Bei NW 3.x wird der Server über FCONSOLE.EXE heruntergefahren. Dieses Programm gibt es auch für neuere Netware Versionen im Novell Patch tabnd2a.exe.
Alternativ gibt es bei Netware-Server.de unter Tools diverse Kommandozeilenprogramme zum Herunterfahren des Servers.
Allocated Disk Block allocated a block that was not really available
Dieser Abend tritt öfters auf, wenn sehr viele Dateien nicht gepurgt wurden. Gemeldet wurden diese Abends bei unterschiedlichsten Systemen und Konfigurationen, aber meist mit viel Dateibewegungen.
Um den Fehler mittelfristig zu beheben, sollten Sie versuchen, einen anderen Treiber für SCSI Controller zu verwenden und auf jeden Fall ein PURGE /A auf allen Volumes oder alternativ ein VREPAIR mit der Purge Option durchzuführen.
In der Knowledgebase steht als Tip zu dieser Abend-Meldung, bei Adaptec
Controllern das Mapping bei Platten > 1 GB auszuschalten und die Platten
anschliessend neu zu formatieren.
Das hat aber in einem konkreten Fall nicht geholfen, diese Einstellung
gefährdet sogar ein mögliches Update auf NW 4.x oder 5.x, weil die
HAM Treiber damit nicht klarkommen.
SLP UA WARNING: Unable to contact directory agent, Verify DA availability, IP connectivity, DA discovery options and configuration.
Diese Warnung, die auf der Konsole von Netware 5.x erscheinen kann, "erschlägt" man am einfachsten, indem man am Server "LOAD SLPDA" eingibt - das lädt den Directory Agent mit den Default Einstellungen. Das reicht fürs erste.
Zur Erklärung:
Im Gegensatz zu IPX, wo die Serverdienste ihre Existenz mittels Broadcasts im Netz bekanntgeben (die SAP (Service Advertising Protocol)-Broadcasts), fragt bei TCP/IP der Client, der einen Dienst sucht, per SLP (Service Location Protocol) -Multicast im Netz nach entsprechenden Diensten.
Das Problem ist nun, dass bei den meisten Routern Multicasts deaktiviert sind und auf WAN-Strecken oft auch keine erwünscht sind. Ein Directory Agent macht jetzt nichts anderes als alle ihm bekannten Services in einer Liste zu sammeln und auf Anfrage weiterzugeben.
TID 10027163 (lokal) mit Infos zu Konfiguration und weiteren Links
Wenn bei einem NT 4.0 oder Windows 2000 Rechner auch mit aktuellen Client 32 Versionen bei bestimmten Netzwerkoperationen die Taschenlampe beim Suchen von Netware Komponenten sehr lange "an" ist, d.h. der Vorgang der lange dauert, kann das am installierten Internet Explorer liegen.
TID 2936379 (lokal) http://support.microsoft.com/support/kb/articles/Q226/3/70.ASP
Bei auf deutsch installierten Netware Servern erzeugt der DHCP Server bei Start und Ende einen ASCII Buchstabensalat auf der Konsole.
Wenn Sie zusätzlich auch die englische Sprache auf dem Server installiert haben, gibt es folgenden Workaround:
[AUTOEXEC.NCF] LANGUAGE 4 LOAD DHCPSRVR LANGUAGE 7
ASUS P2B Boards mit BIOS Rev. 1008 - 1009 im Netware Server verursachen seit einiger Zeit plötzliche Sprünge in die Jahre 2018, 2037 oder anderen Daten weit in der Zukunft. Die NDS reagiert darauf recht unwillig mit synthetischen Zeiten. Laut Novell Knowledge Base ist das Problem mit einem BIOS Ver. 1010 oder höher behoben, aber es gab mittlerweile auch vereinzelte Meldungen mit diesen BIOS Versionen. Momentan scheint der Wechsel auf ein anderes Board oder gleich einen anderen Mainboard Hersteller die einzige Lösung zu sein. P3B Boards von ASUS haben das Problem aber wohl nicht.
Unter Umständen kann auch der Befehl SET TIMESYNC HARDWARE CLOCK=OFF bewirken, dass der Server sich die Uhrzeit nicht von der Hardwareuhr holt und deshalb die Sprünge einfach nicht mitmacht. Bei einem Neustart des Servers muss dann allerdings wieder manuell nachgestellt werden.
Ein unangenehmer Nebeneffekt ist ein Bug in der MPREXE.EXE von Windows 9x, die dieses Datum nicht akzeptiert und den Client zum Absturz bringt. Nach der Rückstellung der Serveruhrzeit sollte ein Zugriff wieder möglich sein.
Backup Exec für Windows hat eine Sicherheitslücke, im Moment massivst von einem Virus oder Trojaner attackiert wird. Wenn nun BE auf Netware läuft, führt der besagte Angriff zu einem Abend in BackupExec, genauer in NRLTLI.NLM.
Allerdings sollte der BackupDienst eines Servers aus dem Internet gar nicht zu sehen sein. Durch Filterregeln der Firewall sollte man den Port 6101 von außen blocken.
Zumindest ein Update für BE 9.x ist von Veritas verfügbar:
http://seer.support.veritas.com/docs/274645.htm