Alle Tipps zu älteren Produkten wie Netware 2.2, Windows 3.x oder OS/2 sammle ich hier, da manche gerade wegen des Alters dieser Produkte Tipps und Tricks wieder vergessen oder nie gehört haben. Manchmal braucht man sie dann aber doch.
Links
> Ich habe eine 1GB Platte von einem Rechner mit LBA-mode in > einen 386 mit IDE (bis 512 MB) eingebaut. > Das geht gut, bis jemand auf den Bereich über 512 MB zugreift.
Hatten Sie die Platte nach der Aktivierung des LBA-Modus neu partitioniert? Durch den LBA-Modus läuft die Platte evtl. mit anderen Parametern, die der IDE.DSK nicht erkennen kann und deshalb Fehler macht.
Viele Programme wie ältere Versionen von AutoCAD erlauben nur das Drucken bzw. Plotten auf serielle Schnittstellen. Diese können nicht gecaptured werden.
Allerdings gibt es hier einen Trick:
Man schreibt vom Programm aus in eine Datei mit dem Namen PRN (alternativ LPT1, LPT2, LPT3). Diese Schnittstelle muß zuvor entsprechend gecaptured sein.
Bei Autocad bleibt dieses Drucken in eine Datei inkl. "Dateiname" gespeichert.
Obiges kann z.B. passieren, wenn Sie das bei NW 3.11 mitgelieferte Syscon verwendet haben und ein Trustee auf sys:login vergeben wollten und beim Verzeichnisnamen "SYS:\LOGIN" eingetippt hatten. (Mit \ nach dem Doppelpunkt) Nach einer etwas komischen Warnung wird das Verzeichnis inklusive aller Dateien einfach gelöscht. Diese lassen sich auch mit SALVAGE nicht mehr zurückholen. Dieser Bug ist seit dem SYSCON Version 3.68 (aus der NW 3.12) beseitigt.
Man kann das SYS:LOGIN Verzeichnis dann einfach wieder per Hand neu einrichten. Danach muß der Server neu gebootet werden. Eventuell reicht es sogar, das Volume SYS: zu dismounten und wieder neu zu mounten, damit Netware das manuell erstellte LOGIN Verzeichnis erkennt.
Der Fehler "Synthetic time" oder "Synthetische Zeit", der bei NetWare 4.x vor allem bei manuellen Uhrzeitänderungen auftritt, erscheint bei der NetWare 5.0 ohne Service Pack 3 auch aufgrund eines Zeitzonenproblemes, das in der TID 10011030 (lokal) erklärt wird.
NetWare 5.0 Server mit einer Zeitzone östlich von GMT (UTC), d.h. Europa, Mittlerer Osten und Asien melden nach dem Neustart diesen "Synthetische Zeit" Fehler, bis der Unterschied zur GMT Zeit vorbei ist. In Europa handelt es sich dabei um eine Stunde.
Der Fehler ist rein kosmetischer Natur und sollte keinen Grund zur Besorgnis darstellen. Das "Reparieren" dieses Fehlers, wie er in dem Tip bei Netware 4.x beschrieben ist, sollte nicht durchgeführt werden! Installieren sie statt dessen den aktuellen Service Pack, der das Problem behebt.
Eine recht alte Lösung ist die Netware for MacIntosh. Bei NW 3.x und 4.x war eine 5-User Version enthalten. Diese Version muß nur soviele User unterstützen, wie man Macs ins Netz hängen will.
Wenn man in den Mac's bereits Ethernet-Karten (was gegenüber Appletalk performancemäßig deutlich überlegen ist) drinhat, braucht man auch nur eine Karte im Server und folgende Schritte:
Auf dem Mac die Netzwerksoftware installieren. (Bei System 7.5 geht das über den Installer.)
Im Apfel-Menue das Programm "Auswahl" anklicken. Dann "AppleShare" auswählen. Dann Ihren Server anklicken, Login-Name und Passwort eingeben. In der dann erscheinenden Dialogbox das/die Volumes anklicken, mit dem gearbeitet werden soll. (Es erscheinen alle Volumes, die Sie vorher mit ADD NAMESPACE MACINTOSH ... bearbeitet hatten.)
Wenn Sie möchten, daß beim nächsten Systemstart automatisch auf das NetWare Netz zugegriffen werden soll, einfach die gewünschten Volumes ankreuzen, das Feld "Name und Kennwort sichern" anwählen und fertig.
NW4MAC ist nicht für NW5 vorgesehen. Das Produkt war zwischendurch als "End of Life" eingestuft und ist daher nicht in NW5 enthalten. Novell hat für Mac-Clients ursprünglich den MacIPX-Client in NW5-Umgebungen vorgesehen.
Nur machen bei der Client-Version 5.11 nach wie vor diverse Bugs von Adobe-Programmen Ärger, so daß AFP für Macs sicher die bessere Wahl ist.
Für NW4.2, in der NW4MAC auch nicht mehr enthalten war, kann man es heute noch von Novell herunterladen: Novell Patch nwmac.exe.
Bei NW5 hat sich jedoch soviel geändert, daß NW4MAC nicht ohne Probleme zum Laufen zu bringen ist.
Unsere Kunden bekommen ein Windows auf's Netz - im Verzeichnis SYS:WIN31 (mit einem Search-Map versehen) wird mit SETUP /A alles installiert. Jeder Benutzer hat ein User-Verzeichnis (i. d. Regel mit MAP ROOT G:=SYS:USER/%LOGIN_NAME% gemappt). Hier richte ich mir in meinem eigenen G:-Laufwerk mit SETUP /N die erste Win-Version im Verzeichnis G:\WIN31 ein. Mein Ziel bei Win-Installationen ist immer folgendes: der Anwender soll zwar alles Nötige zur Verfügung gestellt bekommen, aber er soll so gut wie nichts verstellen können. Auf die Weise kann er davon ausgehen, daß er beim nächsten Start von Windows alle Fenster so vorfindet, wie er es gewohnt ist - wenn man weiß, welches Unheil unerfahrene "Maus-Klicker und -Schieber" so auf dem Desktop anrichten können, ist das immer gut zu wissen.
Jetzt installiere ich erstmal alle notwendigen Grafiktreiber. Auch werden alle Gruppen angelegt, die nötig sind. So schmeiße ich aus der Hauptgruppe fast alles 'raus, lege mir eine Gruppe "Supervisor" an und erstelle eine Gruppe "Programme", in die später alle Programme reinkommen.
Ich lege auf dem Server ein Verzeichnis SYS:INI an. In diesem Verzeichnis wird für jeden Grafiktreibertyp ein Verzeichnis angelegt. Bspw.: SS8X6 für SpeedSTAR 800x600 usw. In diese Verzeichnisse (darauf haben alle Lesezugriff), kommen die gemeinsam genutzten Gruppen-Dateien (*.GRP). Im Verzeichnis INI lege ich für jeden Benutzer eine PROGMAN.INI als %LOGIN_NAME%.PRG an.
Im Login-Script wird jetzt für jede Station - abhängig von der Grafikkarte - ein MAP ROOT J:=SYS:INI\<entsprechendes Verzeichnis> mit anschließendem COPY J:\*.GRP G:\WIN31 gemacht. In den *.PRG-Dateien in SYS:INI kann man wunderbar editieren, welcher Benutzer welche Gruppe sehen soll und wo die liegen soll (die PRG-Datei holt er sich beim Aufruf von Windows). Jeder Benutzer hat in G:\WIN31 eine AUTOSTART- und eine PRIVAT-Gruppe. Alle anderen kommen immer wieder von J: - so ist sichergestellt, daß auch die Gruppen immer gleich bleiben.
Wozu die GRP's für jede Grafikkarte? Weil Win sonst jedesmal die GRP-Dateien an den jeweiligen Treiber anpassen muß - das kostet Zeit.
Jetzt kommt die WIN.INI aus meinem Verzeichnis auch ins INI-Verzeichnis. Die SYSTEM.INI kommt als %STATION%.SYS ins INI-Verzeichnis, wobei im LOGIN-Script für jede Station mit SET STATION=P_STATION <<4 eine eindeutige Veriable gesetzt wurde (die enthält die letzten 8 Ziffern der Ethernet-ID). Die SPART.PAR-Datei (die den Verweis auf die stationsabhängige Auslagerungsdatei auf C: enthält, kommt ebenfalls als %STATION%.PAR ins INI-Verzeichnis.
Im INI-Verzeichnis liegen also demnach:
Die PROGMAN.INI für jeden Benutzer Die SYSTEM.INI für jede Station Die SPART.PAR für jede Station Die WIN.INI des Supervisors.
Jetzt wird erstmal der ganze Kram aus meinem G:\WIN31 für jeden Benutzer kopiert - jeder erhält also ein G:\WIN31. Natürlich ohne meine eigenen Gruppen. Nur mit der leeren AUTOSTART und PRIVAT-Gruppe.
Ab hier gibt es zwei Möglichkeiten: entweder legt man auch für jeden Benutzer eine eigene WIN.INI in INI ab (einfach...), oder man erzeugt eine, in der beim Start von Windows einige Stellen für den jeweiligen Benutzer ausgetauscht werden. Im ersteren Fall hat man den Nachteil, daß es Zeit kostet, Änderungen an den INI-Dateien für alle 120 Benutzer durchzuführen. Im letzteren Fall hat man das Problem, das es irre viel Gefummel ist, bis es läuft. Danach ist's aber sehr einfach, kurz mal was an der WIN.INI zu machen...
> Interessant wären die Batches, mit denen Windows aufgerufen wird.
Wenn man obiges gelesen hat, versteht man vielleicht auch dieses (die umfangreiche Version mit nur einer WIN.INI):
@echo off cls echo. ncopy H:\INI\WIN.INI I:\WIN31\WIN.INI >nul rem hier wird die WINI.INI nur erstmal kopiert ncopy H:\INI\%LOGIN_NAME%.PRG I:\WIN31\PROGMAN.INI >nul rem die eigene PROGMAN.INI ncopy H:\INI\%STATION%.SYS I:\WIN31\SYSTEM.INI >nul rem die stationsabhängige SYSTEM.INI ncopy H:\INI\%STATION%.PAR I:\WIN31\SPART.PAR >nul rem die stationsabhängige SPART.PAR ncopy H:\INI\%STATION%.CTR I:\WIN31\CONTROL.INI >nul rem auch die mußte ich bei einem Kunden variabel gestalten, rem da die Grafiktreiber unterschiedliche Farben machten ncopy J:\*.GRP I:\WIN31 >nul rem da kommen die Gruppen flag I:\WIN31\SPART.PAR RO >nul rem noch ein Schreibschutz drauf. Die SPART.PAR muß übrigens rem auf jedem PC einmalig unter Windows erstellt werden I: rem hier ist das Userverzeichnis I: und nicht G: wie oben if %STATION% == 12345678 goto WS01Config if %STATION% == yyyyyyyy goto WS02Config .... if %STATION% == xxxxxxxx goto WS07Config if %STATION% == zzzzzzzz goto WS08Config rem je nach Station gehts jetzt weiter rem (die Env.-Var %STATION% wird im LOGIN-Script gesetzt). :WS01Config rem USERNAME rem damit man später noch weiß, wer an dem Platz sitzt cd \win31 rem ins eigene Userverzeichnis wechseln QR Commit0 device= win.in* >nul QR Commit1 Panasonic win.in* >nul QR Commit2 KX-P4450i,PCL4X,LPT1: win.in* >nul QR Anschluss LPT1 win.in* >nul rem ich habe in der WIN.INI die Variablen "Commit0", "Commit1", rem "Commit2" und "Anschluss" gesetzt. Die werden vom Programm rem QR (ein Stringtauscher - mehr dazu weiter unten!) übersetzt in rem das, was hinter der Varible steht, also "Commit1" -> "Panasonic" rem - womit ich für jeden Benutzer unterschiedliche rem Druckervoreinstellungen machen kann. QR Col1 64 win.in* >nul QR Col2 128 win.in* >nul QR Col3 255 win.in* >nul QR Col4 224 win.in* >nul rem Hier noch ein paar Farbwerte... cd \ goto WindowsStart :WindowsStart rem Hier geht's dann los! win31 %1 rem Windows starten (die WIN.COM im userverzeichnis heißt WIN31.COM!) cls echo. i: cd\win31 copy SYSTEM.INI I:\WIN31\INI\%STATION%SYS.INI >nul copy CONTROL.INI I:\WIN31\INI\%STATION%CTR.INI >nul copy WIN.INI I:\WIN31\INI\%LOGIN_NAME%.INI >nul copy PROGMAN.INI I:\WIN31\INI\%LOGIN_NAME%.PRG >nul rem Damit man zur Not Änderungen an den INI-Dateien nicht einfach rem durch einen Windows-Neustart überschreibt... Da muß man aufpassen! dir J:\*.GRP /B >DELETE.IT xdel @DELETE.IT /N >nul rem Damit werden wieder alle GRP-Dateien gelöscht. del DELETE.IT >nul del SYSTEM.INI >nul del WIN.INI >nul del CONTROL.INI >nul del PROGMAN.INI >nul rem Damit ist das Verzeichnis beim User wieder total jungfräulich! cd.. flag I:\WIN31\SPART.PAR RW >nul del I:\WIN31\SPART.PAR >nul echo.
Die andere Veriante (mit vielen WIN.INI's) sähe etwa so aus:
@echo off cls echo Der Start von Windows 3.1 wird vorbereitet... echo. flag g:\windows\spart.par rw >nul ncopy f:\win31\ini\%LOGIN_NAME%.ini g:\windows\win.ini >nul ncopy f:\win31\ini\%LOGIN_NAME%.prg g:\windows\progman.ini >nul ncopy f:\win31\ini\%P_STATION%.ini g:\windows\system.ini >nul ncopy f:\win31\ini\%P_STATION%.par g:\windows\spart.par >nul ncopy j:\*.grp g:\windows >nul flag g:\windows\spart.par ro >nul win31 %1 cls echo Windows 3.1 wird beendet... echo. ncopy g:\windows\system.ini g:\windows\%P_STATION%.old >nul ncopy g:\windows\win.ini g:\windows\%LOGIN_NAME%.old >nul echo.
Windows kopiert bei Netzwerkinstallationen von Windows 3.x bei herkömmlicher Installation zwar die (Video-)Treiber, aber packt sie nicht aus. Windows kann diesen gepackten Treiber natürlich nicht laden und meldet, daß die Datei beschädigt sei.
Abhilfe:
Mit dem Utility EXPAND, das bei Windows dabei sein sollte, die Treiber von Diskette in ein temp Verzeichniss expandieren/kopieren. Rechte auf das gemeinsame Windows Verzeichnis bekommen und die Treiber reinkopieren. Die Datei OEMSETUP.INF in OEMx.INF, wobei x eine Zahl ist, umbenennen und ebenfalls reinkopieren.
Jetzt einfach einen OEM Treiber installieren und als Quelle das gemeinsame Windowsverzeichniss angeben. Damit klappt es.
Eigentlich ist Win 3.1x unter Netware kein Problem, man muß sich
nur vorher im klaren sein, was man auf dem Server und was an der Station
vorhanden sein soll.
Sollen die Nutzer an verschiedenen Stationen arbeiten können,
braucht Windows vom lokalen Rechner die entsprechenden Hardware-Infos (i.A.
System.Ini). Auf der anderen Seite sollten dann die User-abhängigen
Daten (so ziemlich alle anderen Inis, Group-Dateien usw.) nur für den
jeweiligen Nutzer verwendbar sein.
Mein Vorschlag wäre ein Server-basierter Betrieb mit ca. 100kB lokal, je ca. 1 MB auf dem User-Verzeichnis des Servers (pro User) und ca. 40-50 MB je nach Anzahl der Workstations und Konfigurationen (alle Treiber müssen dann zentral vorhanden sein) auf einem zentralen Serververzeichnis.
Nachteil:
geringfügig langsamer als bei Betrieb von der lokalen Platte (bei
486er egal), relativ großer Platzbedarf auf dem Server und ohne
zusätzlichen Aufwand kann der gleiche User sich mit Windows nur an einer
Station einloggen.
Vorteil:
Zentrale Wartung der Treiberdateien (OEMSETUP.INF muß allerdings
bearbeitet werden), zentrale Datensicherung, ausreichende Transparenz
für den Standard-User, zentrales Backup.
Wenn unter Windows 3.1x das Netzwerk (Novell Shell 3.26 und höher bzw. Netware 3.xx) im Windows-Setup nicht eingetragen ist oder uralte Treiber verwendet werden, sind in einen DOS-Task alle Environment-Variablen verschwunden (also z.b PATH etc.).
Die letzten Treiber für Windows 3.1x finden Sie unter NWDLLx.* und WINDRx.* im Internet oder bekannten Mailboxen, zur Not tun es auch die Versionen aus dem Archiv WINUP9.EXE.
1. Alle Win-Disketten wie im Handbuch beschrieben in ein Verzeichnis F:\WIN3x expandiert, alle Files auf RO gesetzt und das Verzeichnis im Login-Script mit MAP S1:=F:\WIN3x gemappt.
2. Für jeden Benutzer ein Homeverzeichnis F:\HOME\benutzername gesetzt und diese im Login-Script mit MAP ROOT G:=SYS:HOME\%LOGIN_NAME gemappt.
3. Die einzelnen Windows-Versionen mit SETUP USER installiert. Und zwar im Verzeichnis \HOME\benutzername\WINDOWS. Auf dieses Verzeichnis habe ich einen Pfad S2:=G:\WINDOWS gesetzt.
4. Ein Verzeichnis F:\USER angelegt. In dieses Verzeichnis kommen gesammelt die WIN.INI's aller Benutzer, jeweils mit dem Namen %LOGIN_NAME.INI versehen. Alle Benutzer haben nur Leserechte in diesem Verzeichnis. Im Login-Script DOS SET LOGIN = %LOGIN_NAME gesetzt. Wichtig: LOGIN_NAME darf max. 8 Zeichen lang sein, sonst muß der Name im Login-Script gekürzt werden (so nach dem Motto
IF LOGIN_NAME = "WAHNSINNSKOMIKER" DOS SET LOGIN = "KOMIKER" END
5. Ein Verzeichnis F:\STATION angelegt. Hier kommen die stationsabhängigen SYSTEM.INI's rein. Jeweils mit dem Namen %STATION_ID.INI versehen. Im Login-Script setze ich eine Variable über z. B.
IF P_STATION == "000884654673" THEN DOS SET STATION = "84654673" END
Über diese Variable kann später die entsprechende SYSTEM.INI beim Start von Windows aus F:\STATION geholt werden.
6. Auf jeder Station eine Swap-Datei von 10000 KB eingerichtet. Die SPART.PAR im Windows-Verzeichnis in "stationsnummer.PAR" umbenannt und dann auch ins F:\STATION kopiert. Da die schreibgeschützt im Windows-Verz. liegt, muß man damit etwas aufpassen.
7. Eine Batchdatei WINX.BAT geschrieben:
rem Die wichtigen Dateien holen ncopy F:\USER\%LOGIN%.INI G:\WINDOWS\WIN.INI >nul ncopy F:\STATION\%STATION%.INI G:\WINDOWS\SYSTEM.INI >nul flag G:\WINDOWS\SPART.PAR RW ncopy F:\STATION\%STATION%.INI G:\WINDOWS\SPART.PAR >nul flag G:\WINDOWS\SPART.PAR RO rem Windows starten win /3 rem Sicherheitshalber nach dem Beenden von Windows die jetzt eventl. rem geänderten INI's retten ncopy G:\WINDOWS\WIN.INI G:\WINDOWS\WIN.OLD ncopy G:\WINDOWS\SYSTEM.INI G:\WINDOWS\SYSTEM.OLD
8. Im Verzeichnis STATION habe ich noch für jede Grafikkarte/Auflösung ein Verzeichnis \GROUPS angelegt (also GROUPS1 für die Benutzer der SpeedSTAR in 800x600, GROUPS2 für SpeedSTAR in 600x400 und GROUPS3 für Paradis mit 800x600).
In diesen Verzeichnissen liegen die Gruppendatei der Gruppen, die von den Benutzern nicht geändert werden dürfen. Hier kommt nur der Supervisor ran.
9. Im Login-Script je nach Grafikkarte der Station ein Verzeichnis H:=SYS:\STATION\GROUPSx gemappt. Dann muß in der PROGMAN.INI jedes Benutzers der Pfad auf diese Gruppen natürlich noch per Hand gesetzt werden. Dieser ist dann aber unabhängig von der jeweiligen Grafikkarte, da die Gruppen über das gemappt Laufwerk H: gefunden werden. Aufpassen bei der Gruppe Zubehör. Wegem dem Umlaut sollte man den Gruppennamen umbenennen.
Der Vorteil, Gruppen, INI's etc. in jeweils einem Verzeichnis zentral zu lagern liegt auf der Hand: Änderungen, die überall durchzuführen sind, werden etwas vereinfacht, da man nicht durch 1000 Verzeichnisse huschen muß. Man kann dann ganz gut in allen INI's die Änderungen mit einem Editor durchführen.
Ich setze im System-Login-Script oder in der AUTOEXEC.BAT die DOS- Umgebungsvariable WINPMT auf [WIN] $P$G. Wenn ich unter Windows im DOS-Vollbild arbeite, erscheint dann [WIN] F:\> als Prompt.
Dadurch vergesse ich nicht, daß Windows noch im Hintergrund arbeitet.
Falls beim Starten von Windows 3.1x ein oder mehrere Fenster mit der Meldung "Restoring irgendwelche Devices" erscheint, sind permanente Captures oder Mappings mit NWUser.Exe oder dem Dateimanager eingetragen worden. Da diese Mappings die normalen Mappings aus dem Login Script überschreiben, sollten Sie diese löschen und Laufwerke und Drucker einheitlich im Login Script mappen und capturen.
Sie können diese mit NWUser oder in der Win.Ini im Abschnitt [Network] löschen.
In der PROGMAN.INI kann der Abschnitt [restrictions] hinzugefügt werden.
[restrictions] NoRun= NoClose= NoSaveSettings= NoFileMenu= EditLevel=
NoRun=1 schaltet den "Ausführen"-Befehl im Datei-Menue ab. Der "Ausführen" Befehl erscheint grau (d.h. nicht aufrufbar) im Datei-Menue und der Anwender kann vom Programmmanager nur Programme starten, die als Symbole in den Gruppen erscheinen.
NoClose=1 schaltet den "Windows beenden"-Befehl im Datei-Menue ab. Der Anwender kann den Programmmanager nicht über das Datei-Menue oder über das System-Menue oder mit ALT+F4 verlassen (der "Windows beenden"-Befehl und der "Schließen"- Befehl sind grau.
NoSaveSettings=1 schaltet den "Einstellungen beim Beenden speichern" Befehl im Optionen Menue ab. Der "Einstellungen beim Beenden speichern" Befehl ist im Optionen-Menue grau und alle Änderungen, die der Anwender bei der Darstellung von Windows und bei den Symbolen macht, werden nicht gespeichert. Diese Einstellung überschreibt die SaveSettings= Einstellung im [Settings] Abschnitt der PROGMAN.INI Datei.
NoFileMenu=1 entfernt das Datei-Menue aus dem Programmmanager. Alle Befehle dieses Menues sind nicht mehr verfügbar. Die Anwender können nur die Anwendungen aus den Gruppen mit Doppelklicken oder der EINGABETASTE starten. Wenn Sie den Befehl "Windows beenden" nicht zusätzlich abgeschaltet haben (NoClose=1), können die Anwender Windows über das System-Menue und über ALT+F4 immer noch verlassen.
EditLevel=n aktiviert Einschränkungen, was die Anwender im Programmmanager verändern dürfen. Sie können einen der folgenden Werte für n bestimmen:
Um die Befehle wieder einzuschalten oder die EditLevel=Einschränkungen wieder rückgängig zu machen, entfernen Sie die entsprechende Einstellung aus der PROGMAN.INI Datei oder setzen Sie den Wert auf 0.
Quelle: Microsoft Corporation, Microsoft Windows, Seiten: 227-229, Die technische Referenz
Windows 3.1x NetWare Troubleshooting Tips
network.drv=netware.drv
network=*vnetbios,vnetware.386,vipx.386
Compiled by Brett Warthen (Infinite Technologies) Fourth Edition: 8.7.94
Das Mailsystem FirstMail von Novell ist eine abgespeckte Version des Freewareprogramms Pegasus Mail!
Wichtiger Unterschied: Das Mailingsystem von Novell kann natürlich nur MHS ("Ist ja nicht schlimm; ein Basis-MHS wird ja mitgeliefert"). Doch man kann damit keine Mail an einen User auf einem anderen Server schicken. Dazu braucht man zusätzliche MHS-Versionen.
Pegasus Mail, das als DOS-, Windows- und Mac-Version erhältlich ist,
hat diese Einschränkungen nicht, wird dauernd weiterentwickelt und ist
zudem kostenlos. 
http://www.pmail.com
Faxware 4 HPCS läuft unter Netware 4.11 nicht.
Faxware 4 läuft mit dem letzten Service Pack recht problemlos, allerdings funktioniert der Runtime Modus mit Netware 4.x nicht korrekt.
Tobit unterstützt die Faxware 4 nicht mehr.
Ein Update auf Faxware 5 ist möglich, allerdings sollte beachtet werden, daß es bei der Faxware 5 keine Freilizenzen mehr gibt.
Wenn bei Faxware 4 die Meldung kommt, man sei kein eingetragener FaxWare Benutzer, kann man das oft durch Neustart von FWNDS lösen. Wenn dann aber auch an der Faxware Konsole (mit FWNDS gestartet) im entsprechenden Kontext keine NDS-Objekte mehr zu sehen sind, kann man das durch Löschen der Faxware NDS-Objekte lösen:
Es scheint so, als ob die FaxWare 5.11 und auch die Version 5.2 mit aktuellen Service Packs den folgenden Abend verursacht, wenn der Kommunikationsmonitor beim Postman und MAServer mitprotokolliert (DEB-Dateien):
"Free called with memory block that has an invalid resource tag; Running Process POP3000".
Die Unterstützung von remote-bootenden Workstations über Boot-ROM und Boot-Image ist in Win95 integriert. Auf der Win95-CD ist unter \admin\reskit\helpfile das file Win95rk.hlp zu finden. Hier können Sie recht detailliert auch Anweisungen zur Generierung eines entsprechenden Boot-Images für Netware entnehmen.
Man muß für den Win95 Printserver einen zusätzlichen Printserver einrichten. Den ersten Printer des neuen Printserver definierst Du mit Anschluss "Remote Parallel LPT1". Für diesen Printserver darfst du das PSERVER.NLM nicht laden. Dann gehst Du an dem gewünschten Win95 Rechner mit Printagent in die Druckereinstellungen und aktivierst den Remote Printer. Beim ersten Mal ist die Fehlermeldung "Druckerserverliste konnte nicht verarbeitet werden" normal. Wenn du die Pulldown Liste der Druckerserver aber nochmal anwählst, sollte der Druckerserver erscheinen. Daraufhin holst du dir den entsprechenden Printserver. Danach ist es am besten, den Rechner neu zu starten, denn das Einstellen des Printservers führt immer dazu, daß man aus dem Netz ausgeloggt wird.
Damit sollte das ganze funktionieren.
Der Printagent verbraucht allerdings eine zusätzliche Userconnection am Server.
Wer unter Netware 3.1x die VLMs benutzt und bei ARCserve 5.01 öfters Abstürze erlebt, muß den NDS.VLM laden, der bei Nutzung der Netware 3.1x standardmäßig in der NET.CFG mit ";" auskommentiert wird.
Beim Laden von ARCserve (5 User Version) auf einem Netware Server mit einer 100 User Lizenz erscheint folgende Meldung:
This Version of ARCserve runs only on a 5 User-System!
Auf der Platte stehen die Daten von 100 Usern. ARCserve möchte deshalb bei einer 100 User Lizenz von Netware auch mindestens eine 100 User Lizenz von ARCserve.
Beim Netware Client für NT 4.11a gibt es bei verschiedenen Novell Programmen in der DOS Box (z.B. FILER, NDIR und SYSCON) die Fehlermeldungen:
Kein Datenträger in Laufwerk A: und Kein Datenträger auf /Device/Harddisk1/Partition1/ .
Als Zwischenlösung gibt es von Novell die Patchdatei Novell Patch nt411f4.exe (Größe ca. 1 MB mit Fixes fuer 4.11+4.11a).
Des weiteren soll zumindest der erste Fehler durch eine Änderung der Registry behoben werden können:
HKLM\SYSTEM\CurrentControlSet\Control\Windows\ErrorMode
der Wert 0 steht für LW: A. Nach dem Setzen auf 2 (für Laufwerk C) war der Fehler verschwunden.
Der neue Client 4.3 sollte diesen Fehler übrigens nicht mehr aufweisen.
Client32 "Please wait while (process) retries request to (server)"
Bei Computern mit dem Client32 erscheint manchmal diese Meldung, die besagt, daß der File Server die Anfragen des Arbeitsplatzes (noch) nicht verarbeiten kann. Läßt man die Meldung einfach stehen, ist der File Server irgendwann wieder bereit und kann die nachfolgenden Anfragen wieder bearbeiten.
Neben Hardwaredefekten sind die Hauptursachen dieser Meldung fehlerhafte Treiber der Netzwerkkarten auf Client- oder Serverseite oder Verkabelungsprobleme, in manchen Fällen auch Routing bzw. Switching Probleme.
Diese Meldung erscheint hauptsächlich bei den Novell Clients, weil diese vor allem durch den Write Cache eine höhere Performance als die Microsoft Clients besitzen. Der Server ist dem Ansturm von Netzwerk Paketen einfach nicht gewachsen und macht kurze Pausen, bis er die Pakete wieder verarbeitet hat.
Auf der Workstationseite sollte man sich um die neuesten NDIS Treiber für den LAN Adapter kümmern und darauf achten, daß alle zusätzlichen Protokolle wie NETBEUI entfernt werden, wenn sie nicht wirklich benötigt werden.
Auf der File Server Seite sollte man die Patches aus der Minimum Patch List von Novell installiert haben und natürlich auch hier auf aktuelle LAN Treiber des Kartenherstellers achten. Dabei müssen Sie berücksichtigen, daß es zwei ODI-Spezifikationen 3.2 und 3.3 gibt. Je nachdem, welche ODI Version die Treiber der Netzwerkkarte(n) haben, müssen jeweils unterschiedliche Support-NLMs installiert werden (MSM, ETHERTSM und bei der neueren ODI 3.3 auch NBI). Beim Mischen der beiden ODI Spezifikationen treten meist Fehler mit undeklarierten Public Symbols auf.
Auf dem File Server kann man zusätzlich die Werte für die "PACKET RECEIVE BUFFERS" höhersetzen, außerdem die "MAXIMUM CONCURRENT DISK CACHE WRITES" und die "MAXIMUM CONCURRENT DIRECTORY CACHE WRITES".
Wenn die aktuellen Service Prozesse gleich der maximalen Service Prozesse sind, sollte man auch den Wert der "MAXIMUM SERVICE PROCESSES" verdoppeln.
LAN Adapter, die auf dem "Decchip 21x40 Ethernet Controller" basieren (z.B. Karten von DEC selbst, SMC bei einigen Modellen, Adaptec/Cogent, Kingston, Accton und viele NoName Karten), scheinen besonders anfällig für diese Fehler zu sein.
Richtwerte für die Fileserver-Resourcen:
Ganz wichtig ist auf jeden Fall der Wert der Cache Buffers, die sollten ca. 50% haben. Bei unter 20 % wird es da schon sehr knapp und auch gefährlich für die Stabilität.
Ich kenne die folgenden Werte:
Vor der Installation der Serverkomponenten sollten Sie einen Windows 9x (nicht NT!) Rechner mit dem ZENclient installieren (Dieser ist auf der CD enthalten und er bietet es auch in dem AutoRun-Programm an)
Falls noch alte Workstationmanager-Objekte für NT in dem Baum vorhanden sind, greifen diese beim neuen Client übrigens nicht mehr, da wird es notwendig, eine neue NT-Workstationkonfiguration zu erstellen.
Weitere Infos zu ZENworks gibt es von Alexander Lay unter
http://www.nwadmin.de/.
Eine sehr gute Seite mit Faq's, Artikeln, Einleitungen und Verweisen ist
die Seite http://www.novell.com/coolsolutions/zenworks/index.html
Nachrichten legt PMAIL im Netz im Verzeichnis SYS:MAIL/user_id ab.
Der Datei-Name setzt sich aus einer Zahl und der Extension .CNM zusammen. Das Datei-Format ist ASCII. Die Zeilen To: bis X-Mailer: werden von Pmail ausgefüllt. Sie können aber z.B. mit EDIT genausogut manuell geschrieben werden.
Setzt PMail I Schreibt der User ------------I------------------------- To: PETER From: "KLAUS Mueller " <SERVER1/PETER> Date: 28 Jan 96 15:56:25 Subject: Test Reply-to: KLAUS X-mailer: Pegasus Mail v3.0 ------------I-------------------------
Ausführliche Infos findet man im RFC 822.
Aus der deutschen Website von Cheyenne:
FAXServe 5 für NetWare & GroupWise ist die erste und bisher einzige Lösung, in der die integrierten Faxfunktionen von Groupwise und das einfache Faxen vom Desktop aus populären Windowsanwendungen heraus kombiniert werden.
Tobit Faxware kann das übrigens seit geraumer Zeit auch.
Allerdings hat das FAXserve diverse Haken. Windows NT wird nicht unterstützt. Der Bitwareclient zeigt empfangene Faxe nur Schwarz auf Schwarz an (mit mehreren Rechnern und unterschiedlichen Grafikkarten getestet). Versenden geht auch nicht. Ob die Zusammenarbeit mit Groupwise klappt, kann ich nicht sagen.
Außerdem war es (in einem Fall) nötig, das NLM zu patchen, das die Modembefehle "verwaltet". Obwohl FaxServe eigentlich mit Scripts arbeitet, sind einige Modembefehle fest in dem NLM hinterlegt.
Ansonsten läuft die Software sehr stabil, nur der Funktionsumfang ist deutlich geringer als bei der Faxware. Es ist z.B. nicht so einfach, Overlays zu benutzen (z.B. Firmenpapier als Hintergrund benutzen). Die Unterstützung von DOS Software ist ziemlich beschränkt, man muß fast zwangsweise ein großes TSR benutzen. Die Faxware Befehle, die man in den Text einbetten kann, fehlen fast völlig.
Wenn bei Benutzung der Faxware 5 oder David 5.11 der Abend General Protection Processor Exeption Error code / Running process: SystemScan Process auftritt, liegt der Fehler vermutlich an einer defekten Datei im Verzeichnis IMPORT\SYSTEM.
Diese sollten Sie sicheren und testweise löschen. Danach ist die Faxware oder David neu zu starten.
Bei Word gibt es im Netzwerk immer wieder Probleme mit temporären Dateien.
Für Winword 2.0 muß man den Pfad in der WIN.INI setzen:
[Microsoft Word 2.0] DOC-path=F:\DOKU\DOC AUTOSAVE-path=F:\irgendwo INI-path=W:\WINWORD programdir=W:\WINWORD
In WinWord 6.0 können diese Einstellungen alle in EXTRAS/OPTIONEN/DATEIABLAGE getätigt werden.
Außerdem sollten auch im Umgebungsbereich (SET) die Verzeichnisse, auf die TEMP und TMP zeigen, existieren und die richtigen Rechte haben.
Laut install.exe des OS/2 Requesters für den Eintrag "sessions=" im net.cfg sind bis zu 32 Serververbindungen konfigurierbar, der Defaultwert ist 8.
Auch unter DOS sind mehr als 8 Serververbindungen möglich, allerdings nur mit den VLMs und dem CLient32. Dort heißt der Parameter "connections=.." und erlaubt bis zu 50 Verbindungen.
Nur unter NETX sind maximal 8 Serverconnections möglich.
ODI (Open Datalink Interface) beschreibt eine (bzw. mehrere) Stufen des ISO-OSI- Modells.
Novells Konzept der ODI Treiber am Client wurde eingeführt, um mit mehreren Protokollen gleichzeitig arbeiten zu können, z.B. IPX und TCP/IP.
Außerdem wird die alte IPX.OBJ Version längst nicht mehr weitersupportet. Die alte IPX wurde aus der IPX.OBJ, einer OBJ-Datei des Kartenherstellers und den Einstellungswerten mit einem speziellen Novell- Linker zusammengefügt. Bei einer Jumperänderung oder Update von einer der OBJ-Dateien mußte man den Treiber jedesmal neu zusammenlinken.
Der Hauptvorteil von ODI ist aber der, daß hier die eine Datei IPX.COM in drei Teile gesplittet wird und eine zusätzliche ASCII-Datei die Konfiguration stark vereinfacht. Wenn jetzt z.B. der Kartentreiber erneuert werden soll, tauscht man einfach die COM oder EXE des Herstellers aus, das wars. Ändert man wegen einer andern Karte den IRQ der Netzwerkkarte, trägt man den neuen Wert einfach in die NET.CFG ein und startet den Rechner neu.
Diese drei Teile sind:
LSL.COM NE2000.COM (bzw. Dein Kartentreiber) IPXODI.COM
wobei in der NET.CFG Einstellungen für alle drei Teile stehen und mit jedem ASCII-Editor geändert werden können.
Diese drei Teile verbrauchen zusammen zwar mehr Speicherplatz als die alte IPX, haben aber eine erweiterte Funktionalität und können durch die jeweils geringere Größe evtl. doch besser in der hohen Speicher geladen werden. Außerdem kann man diese Treiber durch den Parameter -U wieder entladen, was bei der IPX.COM nicht möglich war.
Zusätzlich benötigt man für den Zugriff auf Netware oder PNW Server natürlich immer noch die NETX oder alternativ die VLMs.
Wenn Ihre NETX Version (3.32) anzeigt, daß sie unter MS-DOS 6.0 läuft, obwohl DOS 6.22 läuft, steht in der CONFIG.SYS die Zeile DEVICE=<pfad>SETVER.EXE.
Sie müssen entweder diesen Eintrag entfernen oder falls er tatsächlich für ein anderes Programm benötigt wird, den Eintrag der NETX.EXE aus SETVER entfernen.
CALL=C:\NETWARE\NWSTART.EXE CALL=C:\NETWARE\LOGIN.EXE
# LASTDRIVE = E # in DOS-Sessions: IDLE_SENSITIVITY = 25 (oder kleiner) # in WinOS/2-Sessions: IDLE_SECONDS = 10 # INT_DURING_IO *muß* auf OFF stehen bleiben
Wer nach dem Upgrade des Netware-Clients 4.6 mit SP2 Probleme mit dem Drucken mit TCP/IP hat, muss einfach die Datei DPRPCW32.DLL (08.01.1999/ 45.056 Bytes) vom SP1 verwenden. Danach hat man alle Vorteile vom SP2, aber keine Druckprobleme mehr.
Die neueren Clients haben dieses Problem übrigens nicht mehr.
"." und ".." auf einem Netware Volume werden von Netware Clients normalerweise nicht angezeigt.
Für NETX und VLM Clients kann man in der NET.CFG folgendes eintragen:
Netware DOS Requester Show Dots = On
Bei einem uralten Windows 95 Client32 stand diese Einstellung unter "Eigenschaften".
Seit dem Client32 2.2 gibt es diesen Eintrag allerdings nicht mehr, weil Novell die Optionen übersichtlich halten wollte und diese Einstellung als unwichtig erachtete. Nichtsdestotrotz können Sie diese Option über die Registry ändern (siehe TID 2930588 (lokal)):
HKey_local_machine \ Network \ Novell \ System Config \ Netware DOS Requester \
Erstellen Sie einen Key namens "Show Dots", wenn dieser noch nicht existiert. Fügen Sie nun diesem einen neuen String "0" (d.h. eine Null) hinzu.
VLM benutzt nicht den Eintrag "FILE HANDLES =" in der NET.CFG, sondern den Eintrag "FILES=" in der CONFIG.SYS. Dadurch wird dieser Wert von Netzwerk- und Nicht-Netzwerkanwendungen gemeinsam genutzt.
Unter NETX hatte man mit FILES=50 und FILE HANDLES = 150 50 DOS-Handles und 150 Netzwerk-Handles. Um dieselbe Anzahl Handles unter VLMs zu bekommen, muß man FILES=200 setzen.
VLM benutzt eine andere Architektur als die NETX-Shell. NETX hing sich in den INT 21h und simulierte dort DOS-Funktionen. Die VLMs hingegen sind das, was Microsoft als "Redirector Interface" bezeichnet.
Die VLMs benutzen eine Backend-Schnittstelle, unter der DOS sie aufruft. Da die VLMs von DOS aufgerufen werden, nutzen sie dieselben internen Strukturen wie DOS selbst. Das ist auch der Grund, weshalb in der CONFIG.SYS LASTDRIVE auf Z gesetzt werden muß.
Um sich gleichzeitig an zwei oder mehr Servern anmelden zu können, verwendet man den Befehl ATTACH bzw. ab NetWare 4.x LOGIN ... /NS. Dabei wird man zwar Benutzer auf diesem Server und belegt auch eine Lizenz, es wird jedoch kein Login Script ausgeführt.
Man kann das Attachen an weitere Server automatisieren, in dem man ATTACH <servername> im Login Script als internen Befehl (d.h. ohne #) ausführt.
Bei Multiserver Netzen mit NDS spielt ATTACH kaum eine Rolle mehr, da man sich automatisch im Netz (sprich in der NDS) anmeldet und nicht an einem einzelnen Server. Beachten Sie aber, dass Sie an jedem Server, zu dem eine Verbindung besteht, auch eine Lizenz belegen.
Novell empfiehlt ganz dringend, einen Jahr2000 Test der NetWare 4.1x (d.h. die Umstellung der Uhrzeit auf den 31.12.1999 oder später) nicht in einer Produktionsumgebung zu machen, sondern nur auf speziellen Testservern.
Der bekannte Fehler mit der Konsolenmeldung: "Synthetische Zeit..." ist zwar prinzipiell mit DSREPAIR zu beheben, wenn der Test schon erfolgt ist, andererseits ist dies speziell in Multiserver Netzen nicht unkritisch. Teilweise wird sogar empfohlen, eine komplette Rücksicherung durchzuführen.
Novell stellt weitere Infos zum diesem Thema in seiner Knowledge Base zur Verfügung: TID 2943412 (lokal), TID 2937148 (lokal), TID 2941649 (lokal), TID 2936382 (lokal), TID 2938506 (lokal), TID 2944661 (lokal)
Sowohl der Novell Client32 2.2 als auch die Version 2.5 (beide für Win9x) als auch verschiedene Versionen für Windows NT haben mit Office 97 Probleme. Installieren Sie statt dessen die aktuellen Client32 Versionen von Novell (siehe "neue NetWare Clients")
Man kann sich mit den Client32 Versionen von Novell gleichzeitig an mehreren NDS-Bäumen anmelden.
Dazu muß man beachten, daß bei älteren Client Versionen der Marker im Feld "Clear current connections" auf der zweiten Karteikarte ausgeschaltet ist.
Man kann mit WHOAMI prüfen, ob man tatsächlich an beiden Trees als NDS-User angemeldet ist, was besonders bei der Administration der Trees wichtig ist.
Bei älteren SK-Treibern sollten Sie auf den Frame-Type achten, ist dort standardmäßig anders (IEEE 802.3) als z.B. bei NE2000 eingestellt.
Schalter W1 wie folgt:
1 BootProm On aktiv - Off inaktiv
2 IRQ3 On aktiv - Off inaktiv
3,4,5 Speicheradresse BootProm, default alle Off 000 = DC00h
100 = D800h 010 = D400h 110 = D000h 001 = CC00h
101 = C800h 011 = C400h 111 = C000h
6,7,8 I/O-Adresse des POS-Registers
000 = 390h default
100 = 328h
010 = 288h
110 = 220h
001 = 320h
101 = 208h
011 = 180h
111 = 100h
Interrupt, Shared Memory Adresse usw. ist alles am Treiber einzustellen.
| JP1: | open (default) |
| Close if you installed the LCS-8634 in a PC system with Suntac
chipset | |
| JP2: | Setting DMA channel |
| 5656 | |
| +-+- DMA 5 | |
| 5656 | |
| -+-+ DMA 6 | |
| all open (default) | |
| JP3: | Interrupt settings |
| JP4: | closed if Bootprom installed |
SW1 : Setting Base Memory and BASE I/O Addresses
(*=UP, -=DOWN)
Swiches Base Memory Address
12345
------- -------
***** C000H
****- C200H
***-* C400H
***-- C600H
**-** C800H (default)
**-*- CA00H
**--* CC00H
**--- CE00H
*-*** D000H
... usw.
Die Liste ist binär geordnet, d.h. der Bereich
ist bis F200H einstellbar und berechenbar.
Swiches Base I/O Setting
678
--- ------
*** 300H (default)
**- 320H
*-* 340H
*-- 360H
-** 380H
-*- 3A0H
--* 3C0H
--- 3E0H
Ältere Western Digital Netzwerkkarten haben meistens die Bezeichnung WD8003E bzw. WD8013* und eine Kartenadresse, die mit 0000C0 beginnt.
SMC hat diesen Geschäftsbereich von WD übernommen und bietet für alle WD und SMC Karten einen einheitlichen ODI Treiber namens SMC8000.COM an.
Die Jumper:
W1: I/O Addresse: gesetzt I/O Adresse: gesetzt
200: 4 6 8 10 300: 4 6 8
220: 6 8 10 320: 6 8
240: 4 8 10 340: 4 8
260: 8 10 360: 8
280: 4 6 10 380: 4 6
2A0: 6 10 3A0: 6
2C0: 4 10 3C0: 4
2E0: 10 3E0:
Jumper 2 wird für langsameres timing (XT 6MHz) gesetzt
W2: Interrupt request gesetzt
IRQ2: 11
IRQ3: 9
IRQ4: 7
IRQ5: 5
IRQ6: 3
IRQ7: 1
W3: Network type
Standard ist Thin Ethernet, alle Jumper gesetzt, für Thick Ethernet alle Jumper entfernen
W4: Frame type
Standard ist Ethernet Version 2, IEEE 802.3, Thin Ethernet: Jumper nicht gesetzt, für Ethernet Version 1 muß der Jumper gesetzt werden
W5: long distance feature
Standard ist Standard Thin Ethernet Segment: Jumper gesetzt.
Wenn nicht gesetzt, wird das Segment auf 300m Länge gesetzt. Alle
Netzwerkkarten im Segment müssen diese Funktion unterstützen. Das
geht jedoch nur, wenn das Netz aus nur einem Segment besteht. Dann
funktioniert auch IEEE 802.3 nicht mehr. Wenn W3 nicht gesetzt ist, wird W5
ignoriert.
Hier die Jumperbelegung der AHA - 1542 B / 1540 B (mit und ohne Floppy): (Auszug aus "adaptec AHA - 1540B / 1542B Installation Guide")
Jumpers installed at the factory are shown as "(x)" Those not installed are shown os "o" It should not be necessary to change the jumper settings.
J5 - General Controll
o 1 - Synchronous Transfer negotiation enable
o 2 - Diagnostics (used only at Adaptec)
o 3 - SCSI Parity disable
o 4 o x o x o x o x | SCSI Address ID
o 5 o o x x o o x x | (SCSI disks should be set
o 6 o o o o x x x x | for ID 0 and 1)
--------------- |
7 6 5 4 3 2 1 0 <?
o 7 o x o x | DMA Channel Select
(x) 8 o o x x | (see also Jumper J9)
------- |
7 6 5 0 <?
o 9 o x o x o x | Interrupt Channel
(x) 10 o o x x o o | Select
o 11 o o o o x x |
---------------- |
9 10 11 12 14 15 <?
o 12 o x o x | DMA Transfer Speed
o 13 o o x x | In MBytes/sec
--------------- |
5.0 5.7 6.7 8.0 <?
J6 - BIOS/Auto Sense Control
(x) 1 - BIOS Enable
o 2 - not used
o 3 - not used
o 4 - not used
o 5 - Auto Sense disable
J7 - Address Selection
o 1 - Floppy Secondary Address select (AHA-1542B only)
(x) 2 o x o x o x | AT I/O Port Address
o 3 o o x x o o | select in hexadecimal
o 4 o o o o x x |
----------------------- |
334 330 234 230 134 130 <?
o 5 o x o x | BIOS Wait State
o 6 o o x x | Select in nanoseconds
--------------- |
0 100 200 300 <?
o 7 o x o x | BIOS Base Address
o 8 o o x x | Select in hexadecimal
----------------------- |
DC000 CC000 D8000 C8000 <?
J8 - Floppy Disk Selection (AHA-1542B only)
(x) 1 - Floppy enable ?-----------------------------™
(x) 2 - DMA Request 2 select | Note: On 1542BS100 series. |
o 3 - DMA Request 3 select | If the floppy enable jumper |
(x) 4 - DMA ACK 2 select | is removed, remove all |
o 5 - DMA ACK 3 select | jumpers from J8 |
(x) 6 - INT Request 6 select ?-----------------------------?
o 7 - INT Request 10 select
o 8 - Dual Speed enable
J9 - DMA/Interrupt Selection
o 1 - DMA Request 0 select
(x) 2 - DMA Request 5 select
o 3 - DMA Request 6 select
o 4 - DMA Request 7 select
o 5 - DMA ACK 0 select
(x) 6 - DMA ACK 5 select
o 7 - DMA ACK 6 select
o 8 - DMA ACK 7 select
o 9 - INT Request 9 select
o 10 - INT Request 10 select
(x) 11 - INT Request 11 select
o 12 - INT Request 12 select
o 13 - INT Request 14 select
o 14 - INT Request 15 select
Die W12-W15 geben den Interrupt an:
W12 = IRQ 2 W13 = IRQ 3
W14 = IRQ 4 W15 = IRQ 5
Die W9-W10 geben die Portadresse an:
W9+W10 = 300h (C800h)
Nur W10 = 320h (CC00h)
Nur W9 = 340h
Keiner = 360h (D400h)
Falls W11 gesetzt ist, wird die Memoryadresse in Klammern für ein optionales Bootrom verwendet.
W1-W8 ist ein ganzer Jumperblock und gibt an, welcher der beiden Anschlüsse verwendet wird:
W1-W8 oben (= 1-2): DIX-Connector W1-W9 unten (= 2-3): BNC-Connector
W16 darf nicht gesetzt sein bei folgenden (uralten) Rechnern:
Es scheint etwas mit dem Timing zu tun haben. Über Details schweigt sich das Novell-Handbuch aus.
seit Kurzem gibt es von Adaptec eine neues BIOS für alle Controller der Serien 2940UW und 2940U2W. Mir scheint seit dem Update mein Server wesentlich flotter zugange zu sein. Sogar die uralten DCAS scheinen zu neuem Leben erwacht zu sein.
Es gibt einen neuen Parameter im Setup: Enable Hardware Write Back
Mehrere positive Rückmeldungen dürften auch in anderen Systemumgebungen ein problemloses Update erwarten lassen.
Unter NetWare 5.1 mit installiertem SP3 gibt es teilweise Probleme mit Windows 2000 Clients, wenn TCP/IP benutzt wird.
Bei der Anmeldung des Clients erscheint ein Error Code 8819.
Dazu gibt es mehrere Lösungsansätze, jeder scheint das Problem etwas besser zu machen, abhängig von der Umgebung:
Installieren Sie diese Möglichkeiten in dieser Reihenfolge, bis das Problem weg ist.
Legato Networker funktioniert unter SP3 nicht mehr. Novell nutzt hier einen Pointer, den Legato bereits seit geraumer Zeit nutzt, obwohl sie das nicht sollten. Eine Lösung ist noch nicht in Sicht, sollte aber von Legato kommen.
Auch Netshield von NAI hat mit dem SP3 Probleme. Der Server stürzt beim Scannen von Dateien mit erweiterten Zeichen ab, wobei der Fehler wohl bei NAI liegt. Ein Beta-Patch der CLIB von Novell sollte das Problem umschiffen, hat sich aber als instabil herausgestellt.
Erfahrungen zu ferrariFax:
ferrariFax mag zwar nichts besonderes sein, aber es läuft bei diversen Anwendern jetzt über Jahre hindurch ohne jede Macke - über System-, Server-, und Client-Wechsel hinweg (vielleicht ist das ja die Besonderheit!?)
Der ferrariFax Client für den Zugriff auf ferrariFax serverPro 2.6 läuft ohne Anpassungen nicht mit dem Novell Client32 3.x zusammen.
Novell hat eine Peer-To-Peer-Funktion des Clients, die zur Kommunikation mit dem Faxserver benötigt wird, entfernt. Laut Ferrari Hotline gibt es aber scheinbar Client32 Releases, bei denen diese Funktion noch aktiv ist.
Der Zugriff auf den Faxserver ist aber auch per TCP/IP möglich. Dazu installieren Sie am Client einfach zusätzlich TCP/IP, wenn es nicht schon vorhanden ist. Auch auf dem Server muß TCP/IP korrekt installiert sein. Am ferrariFax Client stellen Sie das Protokoll auf TCP/IP um und schon klappt die Kommunikation mit dem Faxserver wieder.
Die korrekte Reihenfolge zum Herunterfahren des SFTIII Servers:
Wenn dagegen die sekundäre Engine zuvor mit HALT gestoppt wird, muß die primäre IO-Engine davon ausgehen, daß die sekundäre Engine ausgefallen ist, daher wird beim nächsten Start das ganze System neu synchronisiert.
ARCserve 4 geht bei heutigen Servern mit mehr als 16MB nur dann, wenn man es folgendermaßen lädt:
load tapebd above16 load tapedrv above16 load arcserve
Normalerweise lädt Tapedrv den Tapebd automatisch, wobei der Parameter "above16" dann nicht verwendet wird. Dies frißt den Speicher innerhalb kurzer Zeit bis zum Abend auf. Deshalb laden Sie Tapebd einfach vor dem Aufruf von Tapedrv manuell mit dem Parameter "above16".
Nachdem die NetWare 2.x mittlerweile fast 15 Jahre alt ist, etliche Einschränkungen aufweist und auch nicht Jahr2000 fest (oder zumindest nicht getestet), wurden alle Tipps zu diesen Versionen hier zusammengefaßt:
Wenn Sie einen NW 2.x Server nachträglich erweitern möchten, sei es mit neuen (größeren) Platten oder anderen Netzwerkkarten, werden unbedingt die Original-Disketten bzw. die Disketten benötigt, mit denen das System gelinkt worden ist. Ohne die Originaldisketten und ohne die gelinkten Systemdisktten haben Sie keine Chance. Wenn Ihnen nur die gelinkten Systemdisketten fehlen, bedeutet es "nur" erheblich erhöhten Aufwand, da Sie die Konfiguration und das Linken nachholen müssen, um die Install-Tools zu bekommen. Das Serverprogramm heißt net$os.exe und wird während der Installation und Konfiguration aus diversen Object-Files zusammengelinkt, ebenso die Installprogramme und Zusatztools.
Mit Hilfe dieser gelinkten Disketten können Sie mit dem Setup-Programm die Platte eines neuen Rechners mit einer Novell-Partition formatieren.
Sie müssen bei Plattentausch bzw. -erweiterung übrigens eine Platte nehmen, die wie eine MFM-Platte angesprochen wird, d.h. IDE, oder eben eine alte noch funktionierende MFM. Die Platte darf nicht als user Typ 47 angesprochen werden, fast immer rächt sich das System mit der Meldung "Abend: improper ROM parameter table" beim Start.
Bei Problemen mit dem Mounten von installierten Platten gibt es auch bei der NW 2.2 das Programm VREPAIR, das aber hier ohne speziellen Patch nur mit DOS 3.3 zusammenläuft.
Ein Win95 PC kann (in Anwesenheit eines echten NetWare Servers) einen weiteren NetWare Server emulieren. Der Win95 PC taucht dann mit SLIST in der Serverliste auf. Sie können sich ganz normal einloggen und sich Laufwerke und CDROM des Win95 PC mappen - ganz normal, wie unter echtem Netware 3.1x.
Das Ganze erfordert einen Netware 3.x oder 4.x Server mit Bindery Emulation, der im Netz verfügbar sein muß. Von diesem Server liest der Win95 PC die User aus der Bindery ein. Für diese User kann man dann getrennt festlegen, was die auf dem Win95 PC nutzen dürfen und was nicht.
Zur Installation dieses Dienstes wählen Sie in der Systemsteuerung
unter Netzwerk "hinzufügen" und "DIENST" -
"DATEI UND DRUCKERFREIGABE FÜR NETWARE NETZE". Unter
Eigenschaften muß nun noch die "SAP ANZEIGE" auf AKTIVIERT
gestellt werden, sonst taucht der neue Server nicht auf. Der Computername,
den eingetragen ist, wird übrigens der Servername. Dieser Name sollte
nicht bereits von einem Netware Server benutzt werden, sonst ist dieser
eventuell nicht mehr zu sehen.
Unter ZUGRIFFSSTEUERUNG muß man nun noch "ZUGRIFFSSTEUERUNG
AUF BENUTZEREBENE" aktivieren. Jetzt den Novell Server angeben, dessen
Userdatenbank verwendet werden soll.
Das IPX/SPX von Microsoft muß natürlich installiert sein und
die Kommunikation zu anderen WfW Clients geht dabei verloren.
Das Ganze funktioniert allerdings nur mit dem MS Client und nicht mit dem Client32 von Novell. Der "NetWare Server" von Win95 bietet auch nicht den vollen Umfang eines NW 3.x Servers, obwohl er sich als solcher zu erkennen gibt. OS/2 Clients können zum Beispiel nicht darauf zugreifen.
IEEE 802.5 - Token-Ring
Alle eingesetzten PCs, Mainframes (über Steuereinheiten oder direkt) und Workstations (UNIX...) erhalten eine Token-Ring-Adapterkarte. Ähnlich den bekannten NE2000etc.-Karten.
Die Verkabelung geschieht über ein spezielles verdrilltes Kabel, welches sich 'TYP-1 Kabel' nennt. Die verwendeten Stecker heißen sinnvollerweise auch 'TYP-1 Stecker'. Die Spezifikationen dafür sind von der IBM vorgeschrieben (genormt?). Natürlich gibt es davon auch noch eine Menge Unterarten und Kompatible...
Die Verkabelung wird im Ring geschaltet, also nicht mit zwei Enden und den 50-Ohm-Abschlußwiderständen wie bei Ethernet.
Auf dem Ring sieht es nun so aus, daß ein Bitmuster (Token) ständig bei den einzelnen Karten nachfragt, ob etwas zum Senden vorliegt. Eine neue Nachricht wird an den Token angehängt und zum Empfänger geleitet.
Die Adressierung geschieht über die Token-Ring-Adresse, die weltweit für eine Adapterkarte eindeutig vergeben und 'eingebrannt' wird. (Burned-In). Diese Adresse kann über Software jedoch überschrieben werden.
Der Token-Ring arbeitet mit dem Token-Passing-Zugriffsverfahren. Die Datenübertragung erfolgt jedoch auf einem Übertragungsweg, der im Sinne eines Ringes physikalisch geschlossen ist. Die Teilnehmerstationen selbst sind Teile des Übertragungsweges - im Gegensatz zum CSMA/CD-oder Token-Bus-Netz: Ein Leitungssegment beginnt an jeweils einer Station und endet an der jeweils nächsten Station:
Jede Station regeneriert in einem Repeater die von der vorausgehenden Station eintreffenden Daten und übergibt sie an die weiterführende Leitung.
Das Token-Ring- Zugriffsverfahren basiert darauf, daß das Token als besonderes Steuerpaket im Ring kreist, d.h. daß die Datenstation erst dann Daten abschickt, wenn das Token vorbeikommt, es aus dem Ring herausnimmt, ein adressiertes Datenpaket einspeist und dann das Token wieder hinter dem Paket in den Ring einspeist. Dann wartet sie ab bis das Telegramm wieder bei ihr eingetroffen ist, vernichtet es und setzt wieder ein freies Token auf den Ring (Abb. 24). Im Unterschied zum Token-Bus werden bei der Funktionsweise des Tokens eines Tokenringes die Eigenschaften der Ringtopologie ausgenutzt (Token ist also nicht gleich Token!).
Vorteile
Nachteile
Redundanz-Mechanismen bei Ring-LANs
Einfache Ringe sind sehr störanfällig, denn ein Kabelbruch oder ein loser Stecker führt im Normalfall zum Ausfall des Netzes. Um diesen Gefahren zu begegnen, werden meist Doppelringe eingesetzt. In den Netzwerkstationen sind Mechanismen implementiert, die diese Doppelringe sinnvoll nutzen und die Störanfälligkeit auf ein Minimum reduzieren. So wird z.B. bei einer Störung auf beiden Seiten der Störstelle eine Schleife gelegt. Der Nachrichtenverkehr läuft auf dem bisher nicht genutzten inneren Ring in entgegengesetzter Richtung wieder zurück. Dieser Mechanismus wird "Selbstheilung" genannt.
Ein weiterer Fehlerbehebungsmechanismus ist der Bypass. Im Fall einer Störung wird das beschädigte Ringsegment umgangen, indem die Nachricht auf den der doppelt verlegten Leitung gelegt wird, der unbeschädigt ist. Mehrere Fehlerstellen lassen sich somit umgehen, es sei denn, daß beide Leitungen gestört sind. Die Netzwerkstationen beginnen bei der Fehlerbehebung zunächst mit dem Bypass und schalten dann, wenn beide Leitungen unterbrochen sind, die Selbstheilung ein.
Um Ringe noch fehlertoleranter zu gestalten, wird meist noch ein drittes Verfahren, die physikalische Sternanordnug, eingesetzt. Durch diesen verlegungstechnischen Kniff läßt sich der Nachrichtenverkehr beim Totalausfall einer Station oder deren Zuleitung durch die Überbrückung der Schadensstelle am zentralen Knotenpunkt der Leitungen umleiten. Es handelt sich hier um eine Sterntopologie, bei der sich die Nachricht auf einem Ring bewegt. Im Unterschied zur Sterntopologie ist der zentrale Knotenpunkt eine passive Einheit. Dieser sogenannte Ringverteiler übernimmt keine Verteilerfunktion, er überwacht lediglich die Funktionalität des Kabels und der angeschlossenen Stationen und trennt diese bei Störung einfach ab. Erst wenn durch Bypass und Selbstheilung kein Erfolg mehr erzielt werden kann, wird das beschädigte Segment vollständig vom Ring abgetrennt. Bei Ringtopologien ist auf Grund dieser Mechanismen die Fehlertoleranz am größten.
IEEE 802.4 - Token-Bus
Ein Token-Bus-Netz ist ein LAN, welches mit dem Token-Passing als Zugriffsverfahren arbeitet. Die Spezifikationen von optischen Token-Bus-Netzen sind in IEEE 802.4 vollständig festgelegt worden und sind auch ISO-Standard. Im Gegensatz eines Ethernets mit CSMA/CD-Verfahren, das Beschränkungen in seiner Bandbreite und Teilnehmerzahl aufgrund ihres Zugriffsverfahrens aufweist und Token-Bus-Netzen mit elektrischer Übertragungstechnik, die wegen ihrer geringen Bandbreite von 5 Mbit/s nur ein Reichweite von 700 m erlauben, würde eine Erhöhung der Datenrate nur zu einer Reichweiteneinbuße führen, so ist dieses bei Token-Bus-Netzen auf LWL-Basis nicht der Fall. Durch den Einsatz von LWL ist eine erhebliche Reichweitenerhöhung von bis zu ca. 20 km bei einer Datenrate von 20 Mbit/s möglich, d.h. bei Token-Bus-Netzen ergibt sich die Reichweiteneinbuße lediglich auf der Grundlage des Übertragungsmediums, wobei es beim CSMA/CD- Verfahren es sich aus dem Zugriffsverfahren begründet.
Außerdem besteht bei optischen Token-Bus-Netzen prinzipiell die Möglichkeit, beliebig viele aktive Sternkoppler und nicht nur eine begrenzte Zahl - wie bei CSMA/CD - verwenden zu können.
Die einzelnen Stationen bilden eine "logische zirkuläre, ringförmige Anordnung", d.h. nach dem letzten Teilnehmer ist automatisch wieder der erste dran. Dazu muß der Teilnehmer lediglich seinen Vorgänger und Nachfolger im Netz kennen und haben somit in der Regel keine Informationen über den gesamten Ring. Die betreffende Station hat nur für eine befristete Zeit das Senderecht, sie muß es nach Ablauf dieser Zeit an die nächste per Projektierung festgelegte Station weitergeben. Aus dieser maximalen "Token-holding-time" resultiert für jede einzelne Teilnehmerstation eine determinierbare maximale Wartezeit, mit der sie auf den Bus zugreifen kann.
Aufgrund der Tatsache, daß die Stationen nicht Bestandteil des Ringes sind, ist es nicht möglich, daß das LAN durch den Ausfall einer einzigen Station ausfällt. Deswegen sind auch keine Vorsichtsmaßnahmen wie "Selbstheilung" oder Bypass-Schaltungen notwendig.
Die Möglichkeit, bei Token-Bus-Mischaufbauten aktive und passive Sternkoppler zu verwenden, bietet zwei Vorteile:
Es besteht weiterhin die Möglichkeit, ein Netz aus LWL und Koaxialkabeln aufzubauen, d.h. bestehende Netzwerke auf Koaxial-Basis werden nicht entwertet, sondern durch optische Komponenten erweitert. Mit der Vielzahl auf dem Markt erhältlichen Sternkopplern lassen sich einige modulare Systeme aufbauen.
Im Unterschied zum ebenfalls deterministisch und fairen Token-Ring sind beim Token-Bus also alle Teilnehmer nicht Bestandteil des Ringes, sondern mit Hilfe von Buskopplern an das Übertragungsmedium angeschlossen. Dadurch wird verhindert, daß beim Ausfall einer einzigen Station nicht das gesamte Netz unterbrochen wird. Es ist jedoch auch offensichtlich, daß die zum Betrieb eines Token-Bus notwendigen Kontrollaktionen sehr komplex und kompliziert sind.
Vorteile
Nachteile
Redundanz-Mechanismen bei Bus-LANs
Bei Bus-LANs besteht die Möglichkeit, anstatt einer Busleitung eine zweite redundante Busleitung zu verwenden. Dabei wird jeder Rechner mit dem doppelten linearen Bus verbunden, so daß im Falle des Ausfalls eines Controllers, Transceivers oder Busses, die Funktion des Rechners sichergestellt ist. Es können hiermit jedoch nur Einzelfehler korrigiert werden, Doppelfehler führen zum Ausfall des Rechners.
Wir hatten das Problem, daß eine ISDN-Verbindung (mit einer AVM-B1 Karte) nicht mehr funktioniert hat.
Wir haben die AVM Karte einfach mal aus dem Slot gezogen, wieder reingesteckt und... siehe da: alles lief wieder wunderbar.
Gestern mit einem anderen Router wieder genau das gleiche Problem: Consolen Meldung ISDN: No user responding" -
mit "Karte raus - Karte rein" und... alles lief wieder.
Erklärung haben wir dafür keine, aber einen Versuch ist es bei Fehlern mit der Karte wert.
IRQ 15 sollte man bei NetWare Servern nicht verwenden, wenn es sich vermeiden läßt. Neben der banalen Erklärung, daß eventuell der zweite Port des EIDE-Controllers - auf neueren Computern direkt auf dem Motherboard - nicht (vollständig) deaktiviert wurde, gibt es eine recht komplexe Antwort von Novell unter der TID 10024783 (lokal), die diese Aussage etwas relativiert:
IRQ 7 und 15 belegen die jeweils hochwertigste IRQ Leitung der beiden IRQ Controller und fungieren als Platzhalter, wenn der Urheber eines IRQ Requests nicht gefunden wurde.
Daher stammen auch die Fehler der "Lost hardware interrupts", die bei der NetWare öfters auftauchen (können).
Geräte mit "edge triggered Interrupts" haben mit diesen "Lost Interrupts" erheblich mehr Probleme als solche, die mit "level triggered interrupts" arbeiten und auch IRQ-Sharing beherrschen. Deren Treiber sind nämlich "gewohnt", mit lost interrupts umzugehen.
In Versionen vor NetWare 4.11 gab es zusätzlich einen Bug, der einen reellen IRQ auf IRQ 7 oder 15 als "lost hardware interrupt" deklarierte und ihn einfach verwarf.
Diverse ISA Treiber mit "edge triggered interrupts" können nicht unterscheiden, ob es um einen lost interrupt oder einen reellen IRQ handelt, der für sie gedacht war, wenn sie mit IRQ 7 oder 15 betrieben werden und beantworten diesen auf gut Glück. Und das kann genau dann schief gehen, wenn es ein "Lost Interrupt" war.
Deshalb gilt die Empfehlung, IRQ 7 und IRQ 15 zu vermeiden, vor allem für Karten, die kein Interruptsharing beherrschen. Das sind vor allem ISA Karten, kann aber auch bei PCI Karten mit schlecht programmierten Treibern passieren.
Als Faustregel gilt: *.dsk Treiber können in der Mehrheit kein Interruptsharing, *.ham Treiber können es. Analoges gilt für *.lan Treiber, die nicht mit ODI3.31 arbeiten.
Die IBM DFRS 4GB Platte macht alle 72 Std. einen Service Check von 30sec. einlegt und ist deshalb nicht für Netware geeignet.
Das ist so auch in der c't 2/96, Seite 220f erläutert.
Spätestens alle 72 Stunden schaltet die Platte den Motor ab und parkt
die Köpfe auf einer speziellen Zone.
IBM rät vom Einsatz in Servern ab, der c't Test mit Windows NT
lief hingegen unproblematisch, es erfolgte nur ein Eintrag in's Logbuch.
[weiterer Kommentar:]
Hier läuft eine 2GB ohne Probleme. Die Platte meldet sich offenbar ganz ordnungsgemäß ab. Sowie ich das bisher gesehen habe, ist der Check auch immer problemlos. Ansonsten ist das Teil echt super....
Mehrere Anwender berichten von Problemen mit folgenden Produkten: (z.T. nur in speziellen Kombinationen)
3COM
3C509(B)* (Etherlink III) BNC, AUI 3C509(B)*-TP TP, AUI 3C509(B)*-TPO TP 3C509-COMBO TP, BNC, AUI 3C579 EISA nicht Busmasterfähig 3C590 10 Combo 3C595 10/100 TP 3C900 ?? 3C905 ??
* Neu gegenüber der vorherigen Generation der EtherLink III Karten (im Namen kein B) ist die "Auto Select Media Type function".
Novell/Eagle
NE1000 Ethernet 8 bit ISA AUI/BNC 10Mb/s PIO
NE1500T Ethernet 16 bit Bus Master ISA RJ45 10Mb/s
NE2000 Ethernet 16 bit ISA AUI/BNC 10Mb/s PIO
NE2000T Ethernet 16 bit ISA RJ45 10Mb/s
NE2000Tplus Ethernet 16 bit ISA RJ45 10Mb/s, SW Config.
NE2000plus3 Ethernet 16 bit ISA 10Mb/s RJ45, AUI, BNC
NE2100 Ethernet 16 bit Busmaster-DMA ISA AUI/BNC 10Mb/s
NE/2 Ethernet MCA AUI/BNC 10Mb/s
NE/2T Ethernet MCA RJ45 10Mb/s
NE/2-32 Ethernet 32 bit MCA AUI/BNC 10Mb/s
NE3200-TPA Ethernet 32 bit EISA AUI/BNC, 10Mb/s, Bus Master
TPA=Twisted Pair Adapter (extern)
NE3210 Ethernet 32 bit EISA AUI/BNC,RJ45 10Mb/s (WS-Karte)
NTR2000 TokenRing 16 bit 16/4 (Tropic Chip) STP
NE200T Ethernet PCMCIA Typ II RJ45 10Mb/s
NE200XC Ethernet PCMCIA Typ II BNC
NE4000 PCMCIA
Diese Meldung erhalten Sie nicht nur im Zusammenhang mit dem Novell Client32. Grund für dieses Verhalten, bei dem auch WINIPCFG unsinnige Werte zurückgibt, ist eine defekte Winsock2 Installation, da der Client32 dieses benötigt und von der Original Win95 CD installiert. Diese Version ist aber bei Win95 eben nicht fehlerfrei und erzeugt manchmal den obigen Fehler.
Von Microsoft gibt es den Patch W95ws2setup.exe:
http://www.microsoft.com/windows95/downloads/contents/wuadmintools/ s_wunetworkingtools/w95sockets2/default.asp (alles an einem Stück)
Sie können auch im Client32- Installationsverzeichnis die Datei ws2setup.exe starten. Es gibt keine Meldung. Starten Sie danach Ihren Computer neu.
Sie sollten möglichst bereits vor der Installation des Client32 TCP/IP auf dem Rechner installiert und eventuell auch gepatcht haben.
Als Alternative empfiehlt die MS-Knowledgebase im MS-Article ID Q191064 folgendes, um auf Winsock1 zurückzukehren:
Am DOS-Prompt:
cd windows\ws2bakup ws2bakup.bat exit
Sie sollten diesen Vorgang im DOS-Modus ausführen, das heißt nicht in einem DOS-Fenster, damit keine Dateien offen sind.
Ohne Winsock2 können Sie allerdings weder Native IP, noch SLP oder IP Gateway Services benutzen.
Bei den Client32 4.7x Versionen kommt es sowohl unter NT 4.0 (mit aktuellen Service Packs) als auch Win2000 zu dem Effekt, dass bei der "Anschluss"-Konfiguration des Druckers keine Auswahl der Queue mehr möglich ist. Für den Client 4.7 soll der Fix im SP1 enthalten sein. Es funktioniert aber auch durch einen einfachen Registry Eintrag:
[HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Print] "EnumAllPorts"=dword:00000001
Wenn ein Win9x Arbeitsplatz mit einem aktuellen Client32 ARCserve 6.1 administriert, stürzt der Computer beim Herunterfahren ab. Der Client32 installiert WinSock2, mit dem sich ARCserve 6.1 nicht verträgt. Es gibt verschiedene Lösungen dieses Problems:
[IP-Clients]
Disable=1
Dieser alte Manager läuft auf Rechnern mit Win200 oder XP sehr problematisch. Verwenden Sie am besten eine alte Win98 Station, die den Manager ausführt.
Seit einiger Zeit bietet Novell die Möglichkeit seinen Abend online "einzusenden". Es wird dann geprüft, ob es bereits eine Lösung für das Abendproblem gibt. Wenn nicht, wird der Abend gespeichert und man bekommt eine Mail, sobald eine Lösung für den Abend gefunden wird.
Das Ganze lief bis Ende September 2001 in einer Beta-Phase. Ab sofort ist der freie Zugriff nur Premium und PartnerNet Kunden erlaubt. Alle anderen dürfen max. vier Analysen pro Jahr durchführen.
Deutschsprachig eingestellte Server erzeugen allerdings auch Datumsangaben auf deutsch, die von dem System nicht erkannt werden. Stellen Sie (nicht nur deshalb) den Server mit dem Konsolenbefehl LANGUAGE 4 auf englisch um.
Diskless Client32 Bootdisk FAQ V1.0 (von 100141.155@compuserve.com)
Es gibt einige Haken und Ösen, um den DOS Client32 zum Booten per Bootprom zu bewegen:
Der Computer sollte mindestens 8 MB RAM haben. Sonst gibt es Probleme mit den gepackten Dateien.
Die Dateien passen nicht auf eine 1,44MB Diskette. Benutzen Sie NLMPACKR.EXE (im Root der Client32 Installationsdisketten), um "self-extracting" NLMs zu erzeugen
Während dem Windows Start wird nach Laufwerk A: oder B: gesucht. Das wird von der NIOS.EXE verursacht, die im demjenigen Verzeichnis nach NIOS.DRV sucht, in dem es sich auch beim ersten Laden befand.
Lösung: Legen Sie auf der Diskette ein Unterverzeichnis an und erzeugen Sie mit Hilfe des SUBST Befehls das gleiche Laufwerk, das das Programm auch später beim normalen Arbeiten im Netzwerk vorfindet.
Beispiel: NIOS.EXE und NIOS.DRV liegen im Netzwerk auf O:\windows
Dann erstellen Sie auf der Diskette ein Unterverzeichnis
"windows" und kopieren NIOS.* und die NET.CFG dort hinein.
In der AUTOEXEC.BAT tragen Sie nun ein:
subst O: A: o:\windows\nios.EXE subst O: /D
> Beim Laden mehrerer Frames erscheint die Frage: > "Do you
want to load=another frame type for a previously ..."
Verwenden Sie den Parameter
und hier Beispiel Konfigdateien:
CONFIG.SYS
DEVICE = HIMEM.SYS /TESTMEM:OFF install = bwloadhi.com DEVICE = EMM386.EXE NOEMS RAM /NOVCPI /Y=W:\EMM386.EXE DOS = HIGH,UMB COUNTRY = 049,850,\COUNTRY.SYS SET COMSPEC=W:\COMMAND.COM SHELL = \COMMAND.COM /P /E:1024 SWITCHES = /W FILES = 60 BUFFERS = 20 LASTDRIVE = Z STACKS = 9,256
AUTOEXEC.BAT:
@ECHO OFF CLS REM Default Umgebungvariablen setzen SET PS=BUERO SET NWLANGUAGE=ENGLISH REM An dieser Umgebungsvariablen kann in anderen Batches erkannt REM werden, ob der Client32 verfügbar ist (z.B. in TCPSTART etc.) SET CL32=1 REM COMSPEC setzen, sonst schlägt DEL *.CFG fehl! SET COMSPEC=A:\COMMAND.COM REM NIOS.EXE aus einem virtuellen Laufwerk O:\windows laden REM WICHTIG, sonst läuft's später nicht beim Windows-Start subst O: A:\ O:\windows\nios.exe REM alte NBI Konfig-Datei löschen, sonst gibt's falsche REM SLOT-Zuordnungen del nbihw.cfg LOAD NBic32 REM Standard NLMs laden (LSL etc.) load lslc32 load cmsm load ethertsm REM jetzt LAN Karte ermitteln und laden checkpci.exe REM folgende environment Variablen brauchen wir nicht SET GRAPHIC= SET MOD= if %NETWORK%==8086 SET NIC=e100b if %NETWORK%==10B7 SET NIC=3c90x REM Slot-Nr. der Netzwerkkarte ermitteln findslot REM LAN Kartentreiber und Rahmentypen laden REM Achtung: IP Frame zuerst laden, sonst erfolgt die IP REM Bindung nicht load %NIC% frame=ethernet_II name=ip load %NIC% %LANBOARD% frame=ethernet_802.2 name=ipx REM nicht mehr benötigte Environment Variablen löschen SET NETWORK= SET NIC= SET LANBOARD= SET PCI= load trannta load ipx REM COMSPEC wieder auf den späteren LAN Wert setzen SET COMSPEC=W:\COMMAND.COM REM CLIENT32.NLM laden. hier CL32.NLM weil mit REM NLMPACKX gepackt (sonst ist zu wenig Platz auf der Diskette) load cl32 REM temporäres O: Laufwerk auflösen subst o: /D REM auf das LAN Laufwerk wechseln M: REM Boot Image aus der lokalen RAM-Disk entfernen, REM diese auflösen und die normale Bootfolge REM fortsetzen (CX, LOGIN BOOTPROM, etc.)
BWREMOVE.BAT:
@echo off bwloadhi /u anmeld.bat
NET.CFG:
protocol IPX
net bind ethernet_802.2 e100b 1
net bind ethernet_802.2 3C90x 1
IPX SOCKETS 40
Protocol TCPIP
net bind ETHERNET_II E100B
net bind ETHERNET_II 3C90X
IF_configuration dhcp
; PATH TCP_CFG C:\NOVELL\CLIENT32\TCP
; IP_ADDRESS
; IP_ROUTER
; IP_NETMASK
NIOS
REM geändert, weil sonst Probleme beim Windows verlassen
MEM POOL SIZE 384
NetWare DOS Requester
REM geändert, weil sonst viel CACHE MEM geklaut wird
REM Wert in KB
MAX CACHE SIZE=8192
File Cache Level 3
SEARCH DIRS FIRST = ON
FIRST NETWORK DRIVE = M
FORCE FIRST NETWORK DRIVE ON
NETWORK PRINTERS = 9
SHOW DOTS = ON
; Read Only Compatibility=on
; wird für SAA-Router benötigt,
; da sonst keine Umsetzungstabellen gefunden werden
READ ONLY COMPATIBILITY = ON
CONNECTIONS = 16
AUTO RETRY = 10
und die komplette Disk:
Verzeichnis von A:\
WINDOWS <DIR> 13.10.98 13:01
COMMAND COM 57.377 31.05.94 6:22
3C90X LAN 34.385 14.08.98 14:46
AUTOEXEC BAT 2.079 03.01.99 16:58
BWLOADHI COM 1.610 08.11.96 14:01
CHECKPCI EXE 18.176 13.10.98 15:51
CL32 NLM 271.810 18.11.98 11:04
CMSM NLM 71.826 13.05.98 13:09
CONFIG SYS 347 31.08.98 15:54
COUNTRY SYS 26.945 31.05.94 6:22
E100B LAN 52.700 10.07.98 18:23
EMM386 EXE 120.926 31.05.94 5:22
ETHERTSM NLM 16.020 07.01.98 16:09
FINDSLOT EXE 16.144 12.08.98 13:14
HIMEM SYS 29.408 31.05.94 6:22
IPX NLM 57.995 12.02.98 11:18
LSLC32 NLM 20.043 07.01.98 15:37
NBIC32 NLM 47.953 12.05.98 16:44
SUBST EXE 18.606 31.05.94 6:22
TRANNTA NLM 37.044 14.09.98 11:14
20 Datei(en) 901.394 Byte
Verzeichnis von A:\WINDOWS
. <DIR> 13.10.98 13:01
.. <DIR> 13.10.98 13:01
NIOS DRV 7.680 21.12.95 7:03
NIOS EXE 239.942 16.06.98 16:54
NET CFG 819 12.10.98 17:23
5 Datei(en) 248.441 Byte
Anzahl angezeigter Dateien:
25 Datei(en) 1.149.835 Byte
221.184 Byte frei
Wer NetWare 5.0 mit dem Support Pack 2 einsetzt, braucht unbedingt den
aktuellen Netscape Enterprise Server (NES), Novell Patch nesn451a.exe mit 80 MB
Größe. Das sollte (zumindest) die Version vom 29.04.99 sein.
Alle anderen Versionen von FastTrack oder Enterprise Server bringen
einen Netware 5.0 File Server genau dann zum Absturz, wenn der Admin Server
beendet wird.