Hier finden Sie Tipps zu Client Fragen. Beachten Sie dabei auch die Kapitel "Fehlermeldungen (Client)" und "Windows".
Links
http://www.novell.com/coolsolutions/appnote/620.html: AppNote: Novell Client 4.9 SP2 :
Initialization, Login and SettingsDie alten VLMs erhalten Sie u.a. bei http://www.vobis.de/bbs/support/brett08/index.htm oder
http://www.bham.ac.uk/is/novell/
Viele Einstellungen sind über die Systemsteuerung - Netzwerk - Novell Netware Client - Advanced Settings möglich:
Show Novell System Tray Icon = OFF deaktiviert das rote N im System Tray rechts unten
Use Extended File Handles = ON erlaubt die gleichzeitige Öffnung von Dateien, deren Anzahl nur durch die Maximum Locks per Connection am Server beschränkt sind. Bei OFF können max. 170 Dateien parallel geöffnet werden.
Sie sollten die IPX-Nummer auf dem Client nicht fest einstellen, sondern auf 000000 stehen lassen. Damit besorgt sich der Client die richtige Adresse vom Server. Auch Frames und Geschwindigkeit sollten nicht fest eingestellt werden.
Wenn man ältere ARCserve Versionen administriert, sollte man auch die SPX Sessions erhöhen.
Mit dem Release von NetWare 6.5 ist eine neue Generation von Clients erscheinen, welche alle NetWare Versionen unterstützen und zumindest für Netware Versionen ab Netware 4.x zu empfehlen sind.
Bei Windows 95 und 98 handelt es sich um den Client32 3.4, bei Windows NT 4.0, Windows 2000 und Windows XP professional gibt es bereits eine neuere Version 4.91, die jeweils auf englisch, deutsch, französisch und für andere Sprachen erschienen sind.
Bei dem Client 4.91 sind auch bereits Support Packs erhältlich.
Windows Me und Windows XP home werden offiziell von Novell nicht supported! Auch Microsoft selbst hat diese Versionen nur zum Heimeinsatz bzw. Peer-to-Peer Betrieb entwickelt. Laut diversen Berichten scheinen aber beide Windows Versionen mit den aktuellen Clients (z.T. mit Kniffen) zu laufen.
Sobald eine Verbindung mit einem NetWare 3.x oder ungepatchten 4.x Server besteht (z.B. um sich zu authentisieren), wird diese Verbindung als "not-logged-in" angezeigt. Diese Art der Verbindung nennt man "attachment". Bei Netware 3.x werden diese "attachments" als lizenzierte Connections geführt, was unter den Novellusern zu großen Unmutsäußerungen führte. Daraufhin wurde das nlm "nliclear.nlm" eingeführt, welches diese Art Connections nach gewisser Zeit cancelte.
Ab der Version 4.x gelten attachments nicht mehr als lizensierte Connections. Das Entfernen hat hier eher kosmetischen Charakter. Nur wenn mehr als 250 Connections (lizensiert oder nicht) bestehen, könnte es bei manchen Programmen Probleme geben. Dann kann man die Not-Logged-Ins im MONITOR.NLM bei User Information manuell mit F6 entfernen.
Bei den aktuellen Client32 Versionen wird nun jeder Benutzer gleich zweimal am File Server angemeldet. Diese zusätzliche Verbindung belegt aber keine Lizenz. Die eine Verbindung ist "licensed", die andere "authenticated" (zu erkennen an dem * vor dem Namen in MONITOR.NLM)
Als Nebeneffekt erscheinen allerdings bei älteren Clients alle Broadcasts doppelt.
Wegen der mehrmaligen Anmeldungen an den Server funktioniert auch eine Beschränkung auf maximal eine Connection pro User nicht mehr. Dies ist in der TID 10013518 (lokal) beschrieben.
Wenn Sie sowohl bei Win9x als auch unter Win NT/2000 nicht den aktuellsten Client bzw. Clientpatch benutzen, kann es wegen eines Bugs allerdings vorkommen, dass Sie bei Verwendung von Broadcasts tatsächlich zwei Lizenzen belegen. Dieser Fehler ist mit den aktuellen Patches für die vorigen Clients und bei aktuellen Clients behoben.
Auch eine fehlerhafte NLS Version verursacht bei aktuellen NetWare 5.1 und 6.0 Versionen teilweise für doppelte Lizenzen. Hier gibt es einen Betapatch von Novell: Novell Patch nls603ft.exe, der auch Probleme mit akademischen Lizenzen behebt.
Novell AppNotes bzgl. Lizensierung: http://developer.novell.com/research/appnotes/1996/a9607.htm
Der Zugriff auf einen NetWare 5.x oder 6.x Server ist mit aktuellen DOS Client32 Versionen auch über Pure IP unproblematisch,
Die NET.CFG sollte die TCP/IP Adressen entweder exakt beinhalten:
Protocol TCPIP
IP_ADDRESS 192.168.51.113
IP_ROUTER 192.168.51.254
IP_NETMASK 255.255.255.0
PATH TCP_CFG C:\NOVELL\CLIENT32\TCP
BIND (Kartentreiber)
oder diese per DHCP auflösen lassen:
Protocol TCPIP
IP_CONFIGURATION = DHCP
Der Pfad, der mit "PATH TCP_CFG" definiert ist, sollte auf das Verzeichnis zeigen, das die Dateien HOSTS und RESOLV.CFG beinhaltet. Lesen sie dazu auch TID 2926517 (lokal), TID 2922760 (lokal), TID 2918772 (lokal)
Sollte Ihr Rechner übrigens über 512 MB RAM oder mehr
verfügen, kann er beim Aufruf der NIOS.EXE einen Reset verursachen.
TID 2929510 (lokal), TID 10026862 (lokal)
Um den Novell Client32 für Win9x komplett zu deinstallieren, starten Sie das Programm UNC32.EXE aus dem Verzeichnis ADMIN, das beim Entpacken des jeweiligen Clients erstellt wird oder Sie verwenden bei einem älteren Client das UNC32.EXE aus dem Novell Patch adm32_22.exe.
Beim Client32 für NT / Win2000 / XP reicht es normalerweise, diesen aus der Systemsteuerung zu entfernen. Ansonsten hilft ein Blick in die TID 10013922 (lokal).
Bei den NT 4.0 und Windows 2000 Clients muß der Login Name zweimal eingetragen werden, wenn dieser bei der nächsten Anmeldung wechselt.
Wer z.B. als Admin zu einem NT Rechner geht, sich dort anmeldet, muss damit rechnen, dass der normale Benutzer beim nächsten Anmelden Probleme bekommt. Er muss nämlich auch im Register "Windows NT" wieder seinen Namen eintragen und das ist manchen schon zuviel.
Eine mögliche Lösung ist das automatische Anmelden des lokalen NT Rechners als Admin und das Aufrufen des Novell Login Programms über AUTOSTART. Genaueres zum AutoLogon steht in der TID 10052847 (lokal): "The Ultimate AutoAdminLogon Document for Novell Clients for Windows NT/2000"
Eleganter ist aber sicherlich der folgende Registry Eintrag:
[HKEY_L_M\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "DontDisplayLastUserName"="1" "DefaultUserName" ="" (*)
bzw. bei Windows 2000:
[HKEY_L_M\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system] "dontdisplaylastusername"=dword:00000001
Danach sind die Felder im NDS-Reiter und NT-Reiter immer leer. Der NT-Reiter wird bei der Eingabe des Usernamen aber mit ausgefüllt.
Evtl. muss man vorher beim Client "Save Settings on exit" auf "no" stellen und beim Client 4.7 muss wohl auch der Eintrag DefaultUserName (siehe (*)) leer sein.
Falls das ganze nicht klappt: Installieren Sie das ZENworks StarterPack und richten ein Policy-Package für WinNT ein, das den Login-Service regelt ( Dynamic Local User, DLU). Damit findet beim Login automatisch ein Abgleich mit NT statt.
Wer unter Win9x den Novell Client32 installiert hat, diesen aber nicht automatisch starten lassen will, stellt in der Systemsteuerung im Untermenue Netzwerk die "Windows Anmeldung" als Primäre Netzwerkanmeldung ein.
Trotzdem taucht in manchen Fällen der Novell Client auf und erwartet die Anmeldung ins Netware Netz.
Für die 2.x Versionen des Client32 ändern Sie die Registry wie folgt: (TID 2907849 (lokal))
[HKEY_LM\SOFTWARE\Microsoft\Windows\CurrentVersion\Network\Real Mode Net] "AutoLogon"=hex:00
Bei den 3.x Versionen des Client32 löschen Sie in der Registry folgenden Eintrag:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\NetworkProvider\Order\ "NOVELLNP" = ...
Falls das System nun instabil werden sollte, deaktivieren Sie probehalber das Taskleisten-Symbol ("rotes N").
Bei einigen Novell Client Versionen für NT gibt es weiterhin ein
Sicherheitsproblem.
Man kann das Passwort des vorhergehenden Benutzers, also auch eines
Administrators, aus dem NT-Pagefile auslesen. Mit Hilfe des NTFSDOS Treibers
ist das auch problemlos von DOS aus möglich.
Allerdings handelt es sich hier um ein generelles Windows NT Problem.
Auch memory.dmp und user.dmp sollten dieses Problem aufwerfen
können, wie in http://www.microsoft.com/technet/winnt/storpass.asp#c zu lesen ist.
Microsoft bietet auch eine Lösung für das Problem an:
http://support.microsoft.com/support/kb/articles/q182/0/86.asp
Aktuelle Novell Clients unterstützen den MS-Terminalserver.
Problemlos funktionieren die Clients 4.8x z.B. mit Citrix Metaframe 1.8 und Metframe XP, wobei noch ein Metframe Patch benötigt wird.
http://www.citrix.com: dort nach "Novell Client and Citrix
Metaframe" suchen.
http://www.thinclient.net/technology/novell/Metaframe_XP_FR1_and_NDS.pdf: Voraussetzungen und Einschränkungen sowie
die Installation von Citrix unter NetWare
Es gibt auch einen Webring zu Terminal Servern: http://www.webring.org/cgi-bin/webring?ring=thin;list
Und eine Linkliste: http://www.xs4all.nl/~soundtcr/#acs
Wenn Sie auf einem NT oder Windows 2000 Rechner einen aktuellen Novell-Client installieren und danach einen sehr langsamen Zugriff auf den Server haben, kann das an folgenden Punkten liegen:
Wenn Win2000 Rechner Performanceprobleme beim Browsen durch die Directorys mit dem Explorer haben, was unter NT 4.0 nicht auftritt, liegt das am Task-Scheduler des IE, der nach geplanten Vorgängen auf anderen Computern im Netzwerk sucht, so auch auf NetWare Servern, wo es diese gar nicht gibt.
Durch Löschen des folgendes Registry-Eintrags führt er diese Suche nicht mehr durch:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion \Explorer\RemoteComputer\NameSpace\{D6277990-4C6A-11CF-8D87- 00AA0060F5BF}]
Die Änderungen treten ohne Neustart in Kraft. Konsequenterweise sehen Sie danach auch den Ordner "Geplante Tasks" in der Netzwerkumgebung nicht mehr.
siehe auch
http://www.ithowto.com/novell/clientspeed.htm: weitere wichtige TippsWenn Sie verhindern möchten, dass der Anwender eines Win9x Arbeitsplatzes mit Novell Client sich an der Anmeldemaske "durchmogelt" und diese mit "Abbrechen" überspringen kann, können Sie folgenden Registry-Eintrag ändern:
[HKEY_LOCAL_MACHINE\Network\Logon] "MustBeValidated"=hex:01 [HKEY_L_M\Network\Novell\System Config\Network Provider\Initial Login] "Cancel Desktop Login"="YES" [HKEY_L_M\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Network] "DisablePwdCaching"=dword:00000001
Ersteres erzwingt eine Netwareanmeldung, zweiteres unterdrückt die Windows Passwortabfrage und letzteres verhindert das Zwischenspeichern des Passworts.
TID 2915606 (lokal) und TID 10026624 (lokal)
Novell selbst unterstützte den Mac lange Zeit nicht mehr direkt, der letzte Client von Novell war die Version 5.11 Novell Patch clt511.bin, für die auch Patches erhältlich sind. Novell Patch mclupd6a.bin Dieser unterstützt aber wohl nur die NDS und keine Bindery Server.
Einen neueren Mac Client 5.14 gibt es von der Firma Prosoft, die diesen -
entgegen meiner früheren Aussage - wohl doch noch weiterentwickelt.
Infos bei http://www.prosofteng.com/.
Wer unbedingt sofort Zugriff von Macs auf NW5 Server braucht, hat die Möglichkeit, den oben genannten alten Novell Client 5.11 zu verwenden. Damit greift der MAC über IPX auf den Server zu.
Die Installation läuft wie folgt ab:
Client clt511.bin und patch mclupd6a.bin z.B. per FTP auf den Mac bringen und ausführen.
Client und Patch nach beiliegenden Readme's installieren.
Auf den betreffenden NetWare-Volumes den Mac-Namespace installieren.
Vom Mac aus am NetWare-Server anmelden und Serverteil des Client5.11- Installationsverzeichnisses auf den Server kopieren.
Serverteil installieren (install oder nwconfig).
macfile.nlm starten und fertig.
Alternativ können Sie auch aus dem Novell Patch macfil.exe den AFP installieren, um per Appletalk auf den Server zugreifen.
Ansonsten bietet erst wieder der kostenpflichtige NFA Pack für die NetWare 5.1 oder die Netware 6 direkten Support von Appletalk, indem der Server einen AppleTalk-Server emuliert.
Mac OS X kann noch AppleTalk. Aber alles andere ist eine Frage der Versionsnummer von MacOS X und des gewünschten AFP-Levels (Apple Filing Protocol).
Die beste Version war Mac OS X 10.2.8. Seit Mac OS X 10.3 wurden alte AFP-Level gestrichen. Einen Panther-Rechner wird man damit nicht mehr an einen Netware 3.x-AFP-Server binden können.
Wenn ein NetWare Server nicht von allen Workstations als Default Server benutzt werden soll, kann man sein Antwortverhalten den Arbeitsstationen gegenüber einschränken, wenn man ihn auf Anfragen einfach nicht antworten läßt:
SET REPLY TO GET NEAREST SERVER = OFF
An denjenigen Arbeitsplätzen, die dann doch primär daran gehen sollen, können Sie (unter DOS in der NET.CFG, ansonsten bei den Client32 Einstellungen) ein
PREFERRED SERVER = <ServerName>
setzen.
Wenn Sie einzelne User bzw. Usergruppen die Trustees zeitgesteuert setzen möchten, so z.B. für den Zugriff auf "SYS:SPIELE" nur von 12.00 bis 13.00 h, richten Sie dazu einfach einen User SPIELE an mit Time Restrictions von 12-13h an, mit unlimited Connections und Rechte auf SYS:SPIELE. Die User müssen sich dann nur um 12h neu anmelden und werden automatisch gegen 13h rausgeworfen.
Supervisor und SV-äquivalente User können zumindest unter NetWare 3.x damit allerdings nicht rausgeworfen werden. Dort gelten beim Supervisor keinerlei Account Beschränkungen und Station Restrictions.
Sie sollten auch beachten, dass diese Zeiten als UTC (GMT) gespeichert werden und zumindest ab NetWare 4.x bei Wechsel zwischen Sommer- und Winterzeit um eine Stunde verschoben werden. Auch bei weltweit vernetzten Servern wird die Zeit immer nach UTC und nicht nach der jeweils lokalen Zeit bestimmt.
Mit folgender Lösung kann man feststellen, wo jemand im Netzwerk angemeldet ist.
Man kann bei NW 3.x mit USERLIST /A bzw. ab NW 4.x NLIST user /A /B feststellen, ob der Benutzer angemeldet ist. Zusätzlich erhalten Sie gleich noch die Netzwerkadresse. Dies kann man jetzt mit dem DOS Programmen FIND und einer Batchdatei kombinieren.
Ich habe alle Nodeadressen in einer Textdatei abgespeichert.
NODE.DAT Arbeitsplatz ABC 00005A12BE7F Arbeitsplatz DEF 00005A121234 .
Jetzt noch eine Batchdatei NODE.BAT
@echo off find "%1" NODE.DAT /i
Und schon bekommt man durch Eintippen von
NODE 5A12BE7F
den entsprechenden Arbeitsplatz angezeigt.
Die automatische Zeitsynchronisation der DOS-Arbeitsplätze mit dem File Server kann man durch einen Eintrag in der NET.CFG ausschalten:
SET STATION TIME = OFF
Außerdem muß im Login Script ein SET_TIME OFF stehen, sonst wird die Uhrzeit beim Einloggen wieder auf die Serverzeit gesetzt! Das geht allerdings erst mit der LOGIN.EXE Version 3.70, d.h. eine NW 3.1x muss erst gepatcht werden.
Beim Novell Client32 muß man unter in den Erweiterten Einstellungen (bzw. Advanced Settings) den Wert SetStationTime ausschalten.
Bei dem Original Microsoft Client gibt es scheinbar keine Einstellungsmöglichkeit.
Unter NetWare wird bei jeder Datei und jedem Directory der Owner, d.h. der Benutzer, der die Datei oder das Directory angelegt hat, mit abgespeichert. Wenn der Benutzer gelöscht wird, dann hat die Datei oder das Directory keinen Owner mehr. Im Regelfall gibt es keine Probleme, es gibt aber verschiedene Programme, vor allem Datenbanken, die dann nicht mehr (korrekt) funktionieren.
Die Owner-Informationen kann man manuell mit FILER ansehen und setzen. Mit diversen Tools (siehe Netware-Server.de unter Tools) kann man Dateien ohne Owner auch suchen und den Owner neu setzen lassen.
Booten per Bootrom, d.h. Remote Boot funktioniert mit den ODI Treibern und NETX bzw. den VLMs problemlos, mit Einschränkungen und Tricks auch mit der Client32 Version für DOS, nicht dagegen zusammen mit Windows 95 oder NT.
Vorgehensweise:
Diese Vorgehensweise funktioniert nur bei identischen Rechnern, d.h. diese Imagedatei wird von allen Rechnern mit Bootprom gelesen.
Wer unterschiedliche Rechnerkonfigurationen laufen lassen will, sollte sich im Novell Handbuch CONCEPTS das Konzept der BOOTCONF.SYS anschauen.
Eintrag im (System) Login Script:
if member of "OBSERVE" then #send "Achtung! User %LOGIN_NAME loggt sich gerade ein!" to xy end
Dazu braucht man nur noch die entsprechenden User in eine (speziell dafür erstellte) Gruppe OBSERVE einzutragen.
Bei einem einzelnen User reicht auch:
if login_name = "dau" then ....
Ab NetWare 5.0 gibt es übrigens kein SEND mehr, aber die
Version aus NW 4.x funktioniert auch hier, wenn das IPX Protokoll benutzt
wird.
Mit folgendem Befehl lassen sich alle Dateien eines Besitzers auf einem Volume anzeigen:
ndir /fo /ow eq benutzername
Ndir ist der "Dir"-Befehl von Novell, der nur Dateien [/fo] des Benutzers benutzername [/ow eq (equals) benutzername] auflistet.
Evtl. empfiehlt sich noch " |more oder /c > Dateiname.txt" oder einer folgender Schalter:
| /sort up | sortiert nach geändertem Datum |
| /sub | alle Unterverzeichnisse |
| /ac bef 1-1-95 | alle Dateien, welche seit dem 01.01.95 nicht mehr aufgerufen wurden |
| /si gr 100000 ac bef 01-05-95 sort ow | sortiert die Ausgabe nach Benutzern, welche Dateien größer 100K besitzen, die sie aber seit dem 01.05.95 nicht mehr aufgerufen haben. |
Damit Broadcast Messages (per Send oder Client32 verschickt) nicht mehr am eigenen Rechner empfangen werden, gibt es folgende Möglichkeiten:
Bei Benutzung des MS-Clients muss unter Win9x zum Empfang von Messages WINPOPUP.EXE (aus dem Windows-Verzeichnis) gestartet werden, am besten über den Autostart-Ordner.
Man kann in NetWare 3.x ein "Ablaufdatum" für einen einzelnen User eingeben:
Dadurch wird der Account ab diesem Datum gesperrt.
Will man den Account sofort (evtl. für eine bestimmte Zeit) sperren, kann man statt dessen auch folgendes einstellen:
5a. Account disabled: YES
Beides funktioniert natürlich bei NDS Netzen auch mit dem NW Admin. Dort finden Sie beide Einstellungen beim User Objekt im Register "Login Restrictions".
Mit MAP INS Sxx: kann man Such-Laufwerke mappen. (Dies funktioniert allerdings nicht beim OS/2 Requester). Die Option "Sxx:" (xx für eine Zahl von 1 bis 16 in der Reihenfolge, in der dieses Verzeichnis im Pfad stehen soll) bedeutet dabei, daß NetWare automatisch das nächste freie Netzlaufwerk (von Z: aufsteigend in Richtung A:) sucht und dieses für das Laufwerk-Mapping verwendet.
Dieser Buchstabe wird dann z.B. als "X:.;" an der Stelle "xx" in den Suchpfad der Arbeitsstation eingetragen.
Das optionale "INS" bedeutet, daß Pfade, die bereits an der Stelle "xx" stehen, nicht überschrieben werden, sondern um eine Stelle nach hinten geschoben werden. Wenn man normale Netzlaufwerke mappen will, benutzt man
MAP lw:= oder MAP ROOT lw:=
wobei lw ein beliebiges (möglichst noch nicht benutztes) Laufwerk ist.
Diese Laufwerke werden nicht in den Pfad der Workstation aufgenommen.
Der folgende Default Login Script der Netware 3.1x (fest codiert in der LOGIN.EXE) wird abgearbeitet, wenn kein System- (bzw. ab NW 4.x Container-) und User Login Script vorhanden ist:
WRITE "Good %GREETING_TIME, %LOGIN_NAME." MAP DISPLAY OFF MAP ERRORS OFF MAP *1:=SYS:; *1:=SYS:%LOGIN_NAME IF "%1"="SUPERVISOR" THEN MAP *1:=SYS:SYSTEM MAP INS S1:=SYS:PUBLIC; INS S2:=SYS:PUBLIC/%MACHINE/%OS/%OS_VERSION MAP DISPLAY ON MAP
Soll nur das Abarbeiten des Default Login Scripts vermieden werden (unter weiterer Beachtung vorhandener User Login Scripts), reicht ein NO_DEFAULT im System Login Script.
Ansonsten kann man alle Login Script Varianten mit EXIT ["programm"] beenden.
Seit Netware 4.0 gibt es keinen System Login Script mehr, sondern Container Login Scripte, die für alle Benutzer in diesem Container gültig sind und Profile, deren Login Script einzelnen Benutzern zugeordnet werden können.
Mit der Zeile INCLUDE SYS:MAIL\%USER_ID\LOGIN kann man unter Nw 3.x User Login Scripts aus dem System Login Script heraus ausführen. INCLUDE ... funktioniert auch mit jeder beliebigen ASCII-Datei, auf die aber Leserechte bestehen müssen. Seit NW 4.0 kann man auch ein INCLUDE .orgunit.org machen, wobei der Login Script des angegebenen Containers ab der aktuellen Stelle aufgerufen wird.
Der System Login Script der NW 3.x steht übrigens schreibgeschützt als ganz normale ASCII-Datei in SYS:PUBLIC/NET$LOG.DAT, die jeweiligen User Login Scripts in SYS:MAIL/%USER_ID/LOGIN.
Batchdateien und Programme lassen sich aus einem Login Script heraus mit dem # starten:
| #BEFEHL | für externe Kommandos |
| #COMMAND.COM /C DEL C:\TEST.BAT | für interne Befehle und Batchdateien |
Man darf aber nie ein TSR in einem LOGIN Script starten, weil LOGIN.EXE noch läuft und den Script abarbeitet. Ein TSR legt sich darüber, der später freiwerdende Speicherplatz kann bis zum nächsten Booten nicht mehr belegt werden.
Ausnahme:
Mit #CAPTURE kann man ohne weiteres Druckumleitungen machen, weil CAPTURE nicht resident geladen wird, sondern lediglich bestimmte Flags in dem (bereits geladenen) Client ändert. Die Client32 Versionen erlauben sogar den Aufruf ohne #, weil dort CAPTURE ein interner Befehl ist und somit schneller ist und auch kein zusätzliches DOS-Fenster aufgeht.
Wenn Sie verhindern möchten, dass beim Einloggen eines Users die Laufwerkmappings angezeigt werden, setzen Sie ein MAP DISPLAY OFF in den Login Script.
Die Anzeige von MAP-Fehlern wird übrigens mit einem zusätzlichen MAP ERROR OFF ausgeschaltet.
DOS-Umgebungsvariablen im Login Script definieren
Man kann folgendes Konstrukt (besonders aufwendig bei vielen Benutzern) stark vereinfachen:
IF P_STATION == "000024061371"
SET ID = "24061371"
END
usw....
Das läßt sich mit einer einzigen Zeile für alle Stationen im Netz realisieren:
DOS SET ID=P_STATION << 4
und funktioniert übrigens auch umgekehrt:
DOS SET ID=P_STATION >> 6
ergibt ID=000024, macht aber hier keinen Sinn, da es damit zu gleichen Ziffern kommen kann. Aber diese beiden Optionen funktionieren bei allen DOS SET xx= Zuordnungen.
Vorgabe: Ein DOS-Rechner soll sich automatisch ins Netzwerk anmelden, muß aber ein Paßwort haben.
Eine Möglichkeit ist
echo dein_passwort|login dein_user
Der Rechner muß dazu aber ein temporäres Verzeichnis haben, in das geschrieben werden darf (SET TEMP=...). Der Pipebefehl | macht dies notwendig.
Ein andere Möglichkeit ist die automatische "Eingabe" des Paßwortes aus einer Datei heraus:
login dein_user<datei
In datei steht das Paßwort inkl. Return, sonst bleibt der Rechner hängen.
In beiden Fällen steht aber das Paßwort im Klartext in ASCII-Dateien!
Vorschlag: Das Paßwort so lang und unsinnig machen, daß ein Betrachter es sich nicht einfach merken kann: gj981X1I1IlI2$&jkIl387dF3. Das Kopieren der Dateien muß dann natürlich auch unterbunden werden.
Alternativ kann man auch Batchkompiler einsetzen und die Batchdatei so etwas "verschlüsseln".
Darüber hinaus kann man auch durch Station Restrictions und andere Accountbeschränkungen das System etwas sicherer machen.
Ein Auto-Login für Win9x Rechner steht im Tip "Automatisches Anmelden bei Win9x"
Bei NetWare-Volumes, die größer als 2,1 GB sind, zeigt DOS nur max. diese 2,1 GB als frei an, Anwendungen wie dBase 2.0 (DOS) bringen sogar Speicher-Voll- Fehler beim Neuerstellen von Indexen.
Das Problem hat eigentlich nichts mit NetWare zu tun, sondern liegt in der Verwaltung von DOS, das in diesem Fall mit LongInts arbeitet und diese nur max. 2,1474.... GB (2^10 Byte) aufnehmen können. Der freie Platz ist natürlich trotzdem vorhanden.
Sollten Anwendungsprogramme trotzdem Probleme damit haben, bieten sich folgende Lösungsansätze an:
Beim Arbeiten mit der Server Console von RCONSOLE aus unterscheidet sich die Tastaturbelegung vom Zugriff direkt über die Server Console.
Zusammen mit XCONSOLE und einem Telnet Client mit VT100-Emulation sollte man auf jeden Fall die Tastenkombination STRG-w kennen, die die Tastenbelegungen anzeigt. STRG-z zeigt (ähnlich wie STRG-ESC) alle laufenden Tasks an, mit STRG-f wechselt man zum nächsten Programm und STRG-x beendet die Session.
TID 10019716 (lokal), Tipp "Remote Console von AdRem"
NetWare entfernt die Dateien, die von den Clients gelöscht wurden, nicht sofort, sondern läßt sie in dem Verzeichnis, in dem sie gelöscht wurden, für die Clients unsichtbar stehen.
Die Datei wird trotzdem gelöscht, wenn
Ansonsten kann man diese Dateien mit SALVAGE unter NW 3.x bzw. mit FILER ab NetWare 4.x komplett wieder zurückholen. Beim Einsatz des Client32 gibt es die Optionen Salvage und Purge auch über das Rote N im System Tray unter den "NetWare Utilities".
Zusammen mit der Angabe, wer sie wann gelöscht hat, ist es auch möglich, mehrere Versionen der gleichen Datei zurückzuholen. Falls die angegebene Datei im gleichen Verzeichnis schon vorhanden ist, kann man die Datei unter einem anderen Namen zurückschreiben. Der Benutzer braucht Create Rechte in diesem Verzeichnis.
Sollte das gesamte Verzeichnis mit gelöscht worden sein, stehen die gelöschten Dateien (ohne Angabe des ursprünglichen Verzeichnisses) in dem Hidden Verzeichnis \DELETED.SAV dieses Volumes. Nur der Supervisor bzw. Administrator hat normalerweise Zugriff auf dieses Verzeichnis.
Purge entfernt diese gelöschten Files auf dem Fileserver
unwiderruflich. Ohne Parameter wird nur das aktuelle Verzeichnis gepurged,
mit dem Parameter /ALL auch alle Unterzeichnisse des aktuellen Verzeichnis.
Purge entfernt nur bereits gelöschte Dateien der Anwender!
Problemlösung:
Wenn auf einem beliebigen Volume die Meldung kommt, daß keine Rechte vorliegen, um Dateien aus gelöschten Verzeichnissen zurückzuholen, obwohl man mit ausreichenden Rechten angemeldet ist, dann gibt es auf diesem Volume kein Verzeichnis \DELETED.SAV mehr.
Wenn man dieses Verzeichnis neu anlegt und auf System und Hidden setzt, kann die NetWare mit den oben beschriebenen Tools in Zukunft auch wieder Dateien aus gelöschten Verzeichnissen zurückholen.
Wer Programme einsetzt, die in einem Unterverzeichnis sehr viele (meist kleine) Dateien erzeugen, bekommt ab einer Größenordnung von 10.000 - 20.000 Dateien enorme Performanceprobleme. Es wurden bei Novell bereits Verzeichnisse mit bis zu 70.000 Dateien gemeldet. Der Zugriff auf diese Dateien dauert dann zwei Minuten und mehr.
Die optimale Lösung ist natürlich das Löschen nicht mehr benötigter Dateien. Auch ein Splitten von Daten in verschiedene Unterverzeichnisse ist optimal, wenn es vom Programm möglich ist. Abhilfe bringt zum Teil auch das regelmäßige Purgen des Verzeichnisses.
Eine perfekte Lösung gibt es laut TID 10021744 (lokal) nicht, aber es gibt einige Ansätze, um die Reaktionszeit etwas zu verkürzen:
| Directory Cache Allocation Wait Time: | möglichst klein setzen (0.1 sec), damit der Server schneller neue Directory Cache Buffers belegen kann. |
| Directory Cache Buffer NonReferenced Delay: | möglichst hoch setzen (30 oder 60 Minuten), damit die Daten nicht schon nach 5,5 Sekunden (standard) wieder aus dem Directory Cache Buffer geworfen werden |
| Maximum Directory Cache Buffers: | möglichst hoch setzen. |
| Minimum Directory Cache Buffers: | Startwert der Directory Cache Buffers bei einem Neustart des Server. Diesen sollte man auf den Wert setzen, auf den sich der Server sich nach gewisser Zeit von selbst einpendelt. |
Der Grund für diesen lahmen Zugriff auf die Dateien liegt nicht bei der NetWare, sondern bei DOS und dessen Zugriff auf Verzeichnisse. DOS sucht per "Wild-Card" jedesmal alle Dateien durch, auch wenn die gewünschte Datei bereits nach dem ersten Vergleich gefunden wurde oder der Name exakt beschrieben wurde.
Auch das NSS File System bei NetWare 5.x und 6.x hat dieses
Problem.
Bei Verzögerungen beim Starten und Arbeiten mit Clientprogrammen sollte man folgende Punkte beachten:
Wer mit Win95 und dem MS Client für NW Netzwerke arbeitet, muß Groß- und Kleinschreibung beibehalten auf NEIN stellen.
Dann kann man mit Umlauten problemlos arbeiten.
Wenn es nicht klappen sollte, Dateien mit Umlauten zu löschen, kann man es mit einem "?" statt dem Umlaut versuchen, das heißt statt DEL HÄUSER.TXT einfach mal DEL H?USER.TXT probieren.
Außerdem sollte man versuchen, die Dateien mit unterschiedlichen Clients anzusprechen: DOS mit NETX, VLMs oder Client32, OS/2 Requester oder die diversen Windows Clients haben unterschiedliche Möglichkeiten und Tools.
Es macht auch einen Unterschied, ob Sie eine Datei aus dem DOS-Fenster eines Windows-Rechners zu löschen versuchen oder direkt von DOS aus.
Tools zum Löschen sind FILER oder Konsolenprogramme wie das FILER.NLM (siehe Netware-Server.de unter Tools)
Wer auf einem NT oder Windows 2000 Arbeitsplatz einen Novell Client32 über einen MS-Client spielt, kann sich unter Umständen massiven Ärger einhandeln, weil der MS-Client manchmal nicht komplett entfernt wird. Das sehen Sie vor allem am CSNW-Symbol in der Systemsteuerung, das nach der Client32 Installation als "Hinterlassenschaft" des MS-Clients dort eigentlich nicht (mehr) vorhanden sein darf.
Um das Problem von vornherein zu vermeiden, sollte der CSNW am besten niemals installiert werden bzw. folgende Vorgehensweise (unter Umständen mehrmals) durchgeführt werden:
Einem Win9x Rechner mit aktuellem Novell Client 3.3x kann man mit Tweak UI (von Microsoft) auf der Registerkarte Network die notwendigen Parameter mitgeben, damit er sich automatisch anmeldet.
Für alle Novell Client Versionen (auch für die 4.x Versionen) gibt es zudem das Freeware Tool Autolog, das die notwendigen und je nach Version unterschiedlichen Registry Einstellungen automatisch vornimmt.
http://Netware-Server.de unter Tools in der Rubrik Login/Logout
Mit dem Microsoft Client für Netware Netze klappt es folgendermassen:
Wenn sich an den Arbeitsplätzen immer andere Benutzer anmelden, wäre es praktisch, wenn der Loginname leer bleiben würde. Standard ist nämlich immer der letzte Benutzer, der sich erfolgreich angemeldet hatte.
Um diese zu erreichen, gehen Sie wie folgt vor:
In den Client-Eigenschaften (z.B. über das rote N im Systemtray)
Standortprofile -> Default -> Eigenschaften -> Eigenschaften
Und dort dann den Haken "Save Profile after succesful Login" rausnehmen und das Feld für den Usernamen leeren.
Das klappt sowohl mit den aktuellen 3.x als auch den 4.x Clients.
Um in Linux (oder jeder anderen Unixversion) die NetWare-Volumes zu mounten, benötigt man auf Novellseite NetWare NFS und für die andere Richtung den NFS Gateway. Beides gibt es für Netware 3.x im Bundle, ist aber relativ teuer und auch nicht sonderlich stabil.
Für Netware 4.x und 5 sind NFS Funktionalitäten auch verfügbar, allerdings auch nur gegen Aufpreis.
Für Linux gibt es jedoch seit dem Kernel 2.0 den freien Client
ncpfs, der Ihnen die Möglichkeit bietet, NetWare Volumes direkt zu
mounten. Sogar der Zugriff über die NDS und auch per TCP/IP ist
möglich, dieser wird allerdings etwas anders gehandhabt als bei den DOS-
und Windows Clients von Novell.
Download unter ftp://platan.vc.cvut.cz/pub/linux/ncpfs/
ncpfs ist derzeit nicht in der Lage, bei Pure IP den Novell-Namen und die IP-Adresse aufzulösen, daher muss man sowohl die IP-Adresse (Parameter -A) als auch den Servernamen ( Parameter -S) desjenigen Servers, der eine Replika enthält, angeben.
Mit folgenden Parametern ist es auch möglich, Dateien mit Umlaute unter Linux korrekt anzuzeigen.
Um auch Dateinamen mit Umlauten korrekt unter Linux anzuzeigen, müssen die Dateinamen je nach den unter NetWare und Linux verwendeten Zeichensätzen umcodiert werden.
Der Parameter "-p" gibt die Codepage an, die zur Umsetzung von NetWare-Dateinamen mit Umlauten zu Unicode-Namen verwendet wird. Gebräuchlich ist "-p cp431".
Wenn das verwendete Linux-System bereits mit Unicode-Dateinamen (UTF-8) arbeitet, sollte der Parameter "-p" ausreichen. Wenn das verwendete Linux-System keine Unicode-Dateinamen verwendet, muß mit Hilfe eines weiteren Parameters "-y" eine weitere Umsetzung dieser Unicode-Namen auf den Zeichensatz des Linux-Systems vorgenommen werden. Gebräuchlich sind die Parameter "-y iso8859-15" oder "-y iso8859-1", je nach Zeichensatz des Linux-Systems.
Unter SuSE Linux 9.1 und neuer wird standardmäßig bereits UTF-8 verwendet, jedoch kann durch Konfiguration auch ein anderer Zeichensatz verwendet werden.
UTF-8 wird unterstützt, wenn unter Linux in der Ausgabe des Befehls
set|grep LANG
die Bezeichnung "UTF-8" enthalten ist, z.B.:
LANG=de_DE.UTF-8
(getestet mit NetWare 5.0 SP6a und als Client SuSE 9.0 (ohne UTF-8) sowie SuSE 9.2 (mit UTF-8))
Erst der aktuelle Client 4.9 hebt das bisherige Limit von 4 GB pro Datei auf.
Dazu muss allerdings auch ein NetWare Server ab NetWare 6.0 mit aktuellen Support Packs eingesetzt werden.
Genauere Infos (vorerst in Englisch):
Diese Punkte führen uns zu folgenden Möglichkeiten:
NetWare Versionen können mit Bordmitteln nicht zwischen "guten" und "schlechten" Passwörtern unterscheiden. Sie können zwar festlegen, dass Passwörter mit bestimmten Mindestlängen benutzt werden müssen und diese - falls gewünscht - nach vordefinierter Zeit vom Benutzer wieder gewechselt werden müssen, aber weitergehende Prüfungen sind nicht möglich.
Marcus Williamson von Connectotel hat das Password Policy Management Tool entwickelt, das sich sowohl als Snap-In für NWAdmin und ConsoleOne als auch clientseitig einklinkt und die Passwörter prüft.
http://www.connectotel.com/ppm/
Ab Netware 6.0 kann man auch NMAS Enterprise Edition benutzen.
Dieses Attribut dient nicht dazu, Dateien im allgemeinen mehreren Benutzern zugleich zugänglish zu machen, wie oft gedacht wird.
Im Gegenteil werden damit alle Schutzmechanismen, die eigentlich den unkontrollierten Zugriff mehrerer Clients auf eine Datei zugleich verhindern sollen, ausgehebelt, damit nicht-netzwerktaugliche Programme trotzdem im Netz laufen können.
Bei Datenbankapplikationen wie MS-Access, die darauf ausgerichtet sind, Dateien im Netz zu teilen, ist das Sharable Attribut absolut tabu, da es die Wirkung von file und rekord locks beeinträchtigt und zur Korruption der Datei füren kann.
Bei Einsatz des SP2 für Windows XP sollte man den Client32 4.90 mit dem SP2 einsetzen.
Der Client 4.83 läuft nur mit SP3 und dem zusätzlichen
A-Update. (siehe http://support.novell.com/filefinder/14232/
Wenn Sie sich mit einem Windows NT, 2000 oder XP zu schnell nach dem Neustart an einem NetWare Server anmelden möchten, kann es vorkommen, dass dieser nicht gefunden wird. Diese Windows Versionen zeigen bereits in einem Stadium die Anmeldemaske, in dem noch nicht alle Dienste geladen sind. Warten Sie einfach 15-45 Sekunden und die erforderlichen Dienste (u.a. SLP) sind verfügbar und die Anmeldung klappt problemlos.
Die TID 10086186 (lokal) beschreibt, wie man die Abhängigkeiten beim Client 4.9 durch Registry-Änderungen so steuern kann, dass der Client erst startet, wenn die benötigten Dienste bereits geladen sind.
Erwin Veermans hat unter http://www.veder.com/ zwei Tools entwickelt:
NwDsk ist eine voll automatisierte NetWare Boot Disk:
http://www.veder.com/nwdsk/
Es ist das Top-Tool bei den Novell Cool Solutions, sowohl bei den Downloads als auch bei den Bewertungen.
NwDskPe ist ein NetWare Client Manager für WinPE bzw.
BartPE, der jeden beliebigen Novell client in jeder Sprache installieren und
einrichten kann. http://www.veder.com/nwdskpe/
auf der NwDskPe Seite gibt es auch Plugins für WinPE für ConsoleOne und RconIP (+ OpenSSL) die eine WinPE-CD für einen Netware Admin noch wervoller machen.
http://www.microsoft.com/licensing/programs/sa/support/winpe.asp http://www.nu2.nu/pebuilder/
Sollten Sie einen Unix oder Linux Rechner haben, der sich per NFS an einen NetWare Server 6.x connecten will und beim Mounten (und nur dort) ewig braucht (zwischen 2 und 15 Minuten), liegt das wahrscheinlich an diversen Versuchen, das Locking beider Systeme auszuhandeln.
Verwenden Sie in diesem Fall die Option nolock beim mount Befehl bzw. in der Datei /etc/fstab.
Bisher ist noch kein Vista Client von Novell als Releaseversion verfügbar, eine Open Beta ist allerdings nach der Technology Preview vom Januar 2007 mittlerweile verfügbar:
http://www.novell.com/beta/auth/beta.jsp?id=2306&type=1
Die Novell Client Projektseite spricht von Mitte 2007 für die Releaseversion.
http://www.novell.com/products/clients
Der Vista Client ist aufgrund anderer Zugriffstechnologien von Seiten Microsofts (es gibt z.B. keine Gina mehr) komplett neu geschrieben worden und enthält diverse Altlasten nicht mehr: IPX/SPX oder Queues werden nicht mehr unterstützt. Es werden 32bit und 64bit Rechner unterstützt und DLU ist direkt im Client integriert.
Alternativ kann man auf einen aktuell gepatchten NetWare 6.5 / OES Server auch mit CIFS (Windows-Emulation) zugreifen, ohne, dass ein spezieller Novell Client notwendig ist. Auf der Vistaseite muss hier aber die Authentifikation geändert werden.